Announcement

Collapse
No announcement yet.

RSA Key BLOB Size

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RSA Key BLOB Size

    Without getting down in the weeds, I'm trying to determine if the size of an RSA public key BLOB will always be the same for a given key size. For instance, Windows CNG function BCryptExportKey seems to always generate a 283-byte BLOB for a 2048-bit key size. The BLOB size is the same every time a new key pair is generated with BCryptGenerateKeyPair. Can I count on the BLOB size being the same every time or do I need to test it ever time?

  • #2
    Yes, always determined by key size. Size will be a function of bitlen/8 and/or bitlen/16 plus other fixed size structures, depending on what sort of key BLOB it is

    https://docs.microsoft.com/en-us/win...ider-key-blobs

    e.g.:

    The public key modulus data is located directly after the RSAPUBKEY structure. The size of this data will vary, depending on the size of the public key. The number of bytes can be determined by dividing the value of the RSAPUBKEY bitlen field by eight.

    Comment


    • #3
      Thanks, Stuart.

      In my library, I'm calling BCryptExportKey with BLOB type BCRYPT_RSAPUBLIC_BLOB. After doing a bit more digging, this appears to generate a 24-byte BCRYPT_RSAKEY_BLOB struct which is immediately followed by the "key data." I'm able to read the struct data and, for a 2048-bit key, the key data size seems to be 259 bytes long (256-byte modulus + 3 bytes). I'm not sure what the format is for the key data, but it seems to always be 3 bytes longer than the modulus for other key sizes (e.g. 1024, 4096). For a 2048-bit keys, I'll assume that the key data (259 bytes) will always be the same length for the given key size/modulus (256 bytes).

      Comment


      • #4
        At one time the NIST used to recommend that passwords have a security strength of at least 80-bit, that is now 112-bit. The same strength should be employed with RSA. The snippet below gives the security strength of RSA keys using the latest formula used by the NIST.
        Code:
        #Break On
        #Compile exe
        #Dim All
        
        Function PBMain () AS Long
        Local SS As Double, BS As Long
        For BS = 1024 To 16384 Step 1024
          SS = ( 1.923*(BS*Log(2))^(1/3)*(Log(BS*Log(2)))^(2/3) - 4.69 )/Log(2)
          Print BS, SS
        Next
        Waitkey$
        End Function
        I get
        Code:
         1024          79.9999042866919
         2048          110.117606961723
         3072          131.970080779928
         4096          149.730758434014
         5120          164.954507180005
         6144          178.417656643354
         7168          190.571845079192
         8192          201.706306282319
         9216          212.019001389829
         10240         221.652216116284
         11264         230.712137264863
         12288         239.280410584783
         13312         247.4213540312
         14336         255.186665404805
         15360         262.61860998265
         16384         269.752246626119
        As you can see RSA 1024 used to be OK but that was broken last year, later than anticipated.

        The 'old' formula had RSA 2048 just exceeding 112-bit and why the NIST are currently recommending RSA 2048. That is OK for short shelf life keys but if you are writing code for others to use and you do not know what shelf life they require then I would recommend RSA 3072, pretty much in line with AES 128. That should hold you in good stead beyond 2030 by which time RSA may have been replaced by a quantum resistant method. In fact, my Encrypternet uses RSA 3072.

        Comment


        • #5
          For this application, the RSA key pair is changed very frequently - maybe as often as once every five minutes. RSA 1024 was never a consideration but a 2048-bit key pair can, typically, be generated in under one second on a server instance with only a couple of cores (pretty low overhead).

          This is a type of message switching server that uses raw public keys (similar to RFC 7250) for session registration (authentication and symmetric record key exchange). For now, it only uses rsa_pkcs1_sha256 with a 2048-bit key size to exchange record transport keys, which, for now, only use aes_256_cbc. RSA keys are NEVER stored on disk and are destroyed when replaced by a new key pair. The protocol is similar to DTLS 1.3 (draft). I'm hoping that RSA 2048 plus the frequent key changes will provide adequate security - at least for a couple of years.

          Comment


          • #6
            Originally posted by Jerry
            maybe as often as once every five minutes.
            Wow, RSA 2048 is more than adequate. I couldn't chance it with Encrypternet as I have no idea what users will be using it for and I did not want to rely on them to generate new key pairs now and then.

            Comment

            Working...
            X