[Cryptech Tech] Draft Requirements

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Peter Gutmann wrote:
> Further nits: Missing use cases are email (PGP/SMIME), 1-2 private
> keys and many, many publics, and secure sessions (SSL/TLS/SSH), 1-2
> private keys and numerous publics.

Not sure they are part of our use cases for the alpha board. But if they
can be met by the requirements for the use cases we got then it should
be posible.

Would meeting these requirements differ a lot in terms of algorithms,
storage and performance?


> A more serious problem is the per-key storage requirements, which
> are, um, nowhere near reality.  For RSA you need storage for n, e, p,
> d, q, u, e1, and e2, and depending on how you implement it (whether
> you just expose a single "modexp" outside the FPGA or lower-level
> primitives that you have to compose yourself) for an n-bit key you
> need storage of 2n for most components, 4n for some, and about 45
> temporaries.

This is very interesting. I actually started adjusting the per key(pair)
storage requirements on Friday. For RSA the adjusted storage is based on:

secret key, public key, exponent and then ID etc.

Why do you need to keep p and q after generating the public and secret keys?

This storage requirements sets the size of the keys in an active set of
unwrapped keys in the FPGA. The size (i.e. number of keys in the set) is
not decided yet. It will be based in part on how much memory we can get
in the FPGA and what the requiremenents in terms of loading keys are.
Generally the CPU downloads a set of wrapped keys into the FPGA. The
FPGA unwrapps them and the keys can then be used for processing
internally in the FPGA.

Yes, the idea is to expose a single modexp primitive that can handle
keys up to at least 4096 bits, possibly 8192 bits. There will be
temporary values internally during processing. But we will only process
with one key at a time (as far as I see it) and it will not be a problem.


For ECC algorithms you need qx, qy, d, p, a,
> b, gx, gy, n, and h, and so many dynamically-allocated temporaties
> 80, 100, or more) that I've never bothered trying to track them all.

Lets see if I follow you here. I generated a EC key pair for P-256 and
looked at the keys. Since the actual curve parameters are specified, do
you really keep anything else besides the private and public key? For
P-256 that is 32 bytes private and 64 bytes public key (x and y).

Temporaries for actual process the keys will be handled in a similar way
as the RSA modexp. And is not part of the estimate. It is a single core
with not dynamically allocated buffers.


> For now I wouldn't even try and estimate this, just assume you need
> Some Memory and then wait until you've got the implementation sorted
> out to see what that is.

The amount of temporary storage is figured out during implementation of
the cores. But they are not part of the requirement estimates. Having an
estimate of how much space an unwrapped key of a certain type is good to
have since it gives feedback on things like working set, internal memory
requirements in the FPGA etc. Imho.

I really appreciate getting feedback on these estimates btw. Exactly
what the wiki page is there for - to sort these things out.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJU6jjHAAoJEF3cfFQkIuyNd6cP/1zRqPdlDD8f8824/15KFs8T
KNp7dH2j420akpnmZlgsXPoYMchH8FVq6S5w0pH6Jk6GuQUeoNUOA5+Vg+Ldu7zX
eD6My5vDsOnLp1EgiyR85NGRgl9frVdsRradDanXuaSoNrXu66JOVJxS/LvNVzEJ
AATMxWg8CGCcA6ok/sMdLh9z6HDa+8FI9M5wqyUBB9ZOP7wnLZH1l2UC3xQrzmE8
EX3cSaZ2uyj6xIjCNnd8mjmj0q3i/1zUOxLdNceFy0Uu39k2eprxqutdaMkd1JO2
Av17qbBwDoMdl8b+VZuqCbnrOxa+b1zI9sVIvv4wILHyNE7qMocIFtwrgg3S5ulD
nHs4X1E+xJFchgxIDOetSnRvTSWa95thWcMcM6ke3tmo26puInLtk3P5jAqPfn8c
fXqr2Tdujk5SDqE/ncgYKCJhRyNczQOlUC63qlGcKUg8LHUbZJHwmwqc4I9kaHdM
16UKv1TYcG/TB2iugvZ+zHU1XY4MuPrZF3I077uk0UT5uBI89s62vXlgGfgzgVYU
/TugRA8v+FpzaPPZne6i5N2GE4mNRGgDAfwJNU3w9SaOA5aI81YI8nR8+P68jOr0
2AhTUQiyLgfZdPbBqbE5LFqMHImrQqi18pIzeOQ6qUqewUllaiGi8L0Faeb/P/4r
UIKP9urGvQMTs2ntjhyf
=YFcv
-----END PGP SIGNATURE-----