# Tag Info

7

The real question isn't "Why doesn't Suite B use P-521?" It is, "Why doesn't Suite B use AES-192?" NSA were only interested in 192-bit security for Suite B, but they chose to use AES-256 because AES-192 wasn't widely supported. "In fact we had wanted to use AES -128 and AES-192, but a quick survey of AES implementations (hardware centric, I believe) ...

5

The most likely rationale to change the AES design is political. It's a NIST standard, designed in Western Europe. It's a bad idea! How much scrutiny has it received? Almost none. How much will it receive? Almost none. Bad idea.

5

Please bear in mind that this information is all secondhand. I have not looked closely at the original drafts of Hash DRBG (although you might find a draft that's early enough if you peruse the FOIA results in [1]). However, during conversations with folks at NIST I was told that there were certain weaknesses in early drafts of Hash DRBG that were very ...

3

The PKCS#11 standard has transitioned from RSA to the OASIS group: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 I am not sure why RSA/EMC's site doesn't mention this. I believe that v2.30 was close to finalization, but was never formally released. I am not sure what happened but v2.40 is now the current release candidate. v2.20 is ...

3

I ("SEJPM" as of now) have contacted the authors asked them the same questions as in my question. I'm posting this as community wiki, as it's not my answer to this question but rather theirs. Now the responses follow: First off, the authors are working on a design rationale in english for their new cipher. As soon as it's published, it will be linked ...

3

No, not really. The problem is that these kind of parameters may themselves be chosen deliberately. In other words, NIST/NSA may have performed a pre-calculation to make sure that the key stretching outputs a value that opens the algorithm up to some kind of attack. Lets take an example, would you trust: SHA-256^2^40("Trust me, I'm an innocent string?"). Is ...

2

RFC 2313 specifies the RSAPrivateKey ASN1 structure as a SEQUENCE containing the INTEGERs $0$; $n$; $e$; $d$; $p$; $q$; $d\bmod(p-1)$; $d\bmod(q-1)$; $q^{-1}\bmod p$. The PEM format consists of such a structure encoded as Base64 and framed by the typical BEGIN/END RSA PRIVATE KEY header and footer lines. Thus, you can use any ASN1 library you like to ...

1

This is an error in RFC 2246 corrected at https://www.rfc-editor.org/errata_search.php?rfc=2246 and in the subsequent version TLS RFCs 4346 and 5246. It derives from SSLv3 on which TLSv1.0 was mostly based, now available as RFC 6101 if you want to compare them. You'll see SSLv3 had enum { client(0x434C4E54), server(0x53525652) } Sender; (which are the ...

1

Is there a standard or at least "commonly used" format to format the result? PKCS #7 (and CMS which is a further development) describes a standard format for encrypted data. While it's mainly meant for public key encrypted data, it also has options for symmetric keys. It's rather complex due to all the features it supports, however, so unless you can ...

1

they didn't include P-521, because they wanted a 192-bit security level and P-384 provides that. the reason they didn't use AES-192 probably has something to do with the fact that AES-192 isn't in TLS: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

Only top voted, non community-wiki answers of a minimum length are eligible