[Cryptech Tech] [Cryptech-Commits] [user/sra/aes-keywrap] 01/01: Initial commit of AES Key Wrap implementation.

[Russ Housley]

According to PKCS #1, a RSA private key should be represented with the ASN.1 type RSAPrivateKey.  I do not care about the ASN.1 encoding inside the module, but this does provide the list of bignums.  That said, we probably need to put the private key in this format before wrapping it.

The last element is needed for multi-prime.  My guess is that we are not going to support that capability.  Is that right?

      RSAPrivateKey ::= SEQUENCE {
          version           Version,
          modulus           INTEGER,  -- n
          publicExponent    INTEGER,  -- e
          privateExponent   INTEGER,  -- d
          prime1            INTEGER,  -- p
          prime2            INTEGER,  -- q
          exponent1         INTEGER,  -- d mod (p-1)
          exponent2         INTEGER,  -- d mod (q-1)
          coefficient       INTEGER,  -- (inverse of q) mod p
          otherPrimeInfos   OtherPrimeInfos OPTIONAL
      }

         OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo

         OtherPrimeInfo ::= SEQUENCE {
             prime             INTEGER,  -- ri
             exponent          INTEGER,  -- di
             coefficient       INTEGER   -- ti
         }

Russ


On May 8, 2015, at 9:49 AM, Rob Austein wrote:

> At Fri, 08 May 2015 09:24:27 +0200, Joachim Strömbergson wrote:
>> 
>> Yes, I think it is hard to avoid the looping there. The
>> rotation/movement of words in R should be possible to replace by simple
>> index increment. But I don't see a way to avoid receiving the complete P
>> before processing. This means that we need to define a max size of P in
>> number of 64-bit words.
>> 
>> What would be the proper size? 4096 kbits, 8192, 16384?
> 
> Someone needs to do a bit of arithmetic to figure that one out.  It
> needs to be big enough to hold the largest private key we want to be
> able to handle, which presumably means RSA as EC keys are smaller.
> But it's the private key, so it's a bunch of components in some
> representation or another, basically a sequence of unsigned bignums.
> 
> Exactly which bignums you need depends on how you implement RSA, and
> how long they are is (obviously) related to the key size but it may
> take a few minutes thought to figure out the exact relationship.
> The list of potentially interesting components is in the PKCS #11
> spec, among other places, but you can also just look at Cryptlib's
> CRYPT_PKCSINFO_RSA typedef or the output of
> 
> $ openssl genpkey -algorithm rsa -text
> 
> One can do the basic operations with just the modulus and the public
> and private exponents, the rest are for optimizations and may or may
> not be relevant given how our Verilog code works -- or may become
> useful later if and when we change the Verilog code, etc.
> 
> So I'm pretty sure we can compute a numerical answer to your question,
> but I can't do it on the back of this envelope. :)
> 
>> The same memory would then be used as output buffer.
> 
> Right.  I'd be fine with requiring that the calling code know to
> offset one block when reading and writing the plaintext, if that makes
> things any easier for you.
> 
>> The interface would then look something like:
>> 
>> (1) Write n number of words to the keywrap buffer memory.
>> (2) Write n to the MESSAGE_SIZE register.
>> (3) Write 0x01 to the control register
>> (4) Wait for ready bit in status reg to be set.
>> (5) Read out the result from the buffer memory.
>> 
>> Looks ok?
> 
> Yep.
> 
> Need to figure out who does the error checks on decrypt, I would
> assume software but you tell me.
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech