# Tag Info

6

I'm no FIPS expert but I strongly suspect the answer is no. FIPS is incredibly restrictive and laughably behind the times. To evaluate those algorithms that don't appear in FIPS, first make sure their component parts are secure (maybe even built with FIPS algorithms as subroutines). Then, if there are known answer tests anywhere, maybe from the authors of ...

5

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 ...

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

The SNI extension is plain text in the ClientHello. This means that it is possible to passively snoop the value and redirect the traffic. This is already used in practice, i.e. haproxy has this feature for several years.

5

The question mentions FIPS 140-2 Level 3 compliant. I answer this as if the question had said the intent is to validate the product as FIPS 140-2 Level 3. This may sound like hairsplitting, but there are many modules claiming to be FIPS 140-2 compliant, which factually could not be validated without large changes to functionality. FIPS 140-2 really intends ...

4

rfc5246 7.4.9 defines verify_data as PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; Note the second line; this effectively truncates the PRF output to verify_data_length octets. It goes on to say that verify_data size depends on the cipher suite. Any cipher suite which does not ...

4

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 ...

4

Standards for Efficient Cryptography Group has published SEC1: Elliptic Curve Cryptography (pdf) about elliptic curve algorithms. If it does not explain the mathematics well enough for your purposes, there is also Fundamental Elliptic Curve Cryptography Algorithms (RFC 6090, from IETF) you could look at. There are a lot of issues you can run into, so ...

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

I know of no standard like that and also doubt it exists. It would have similar disadvantages as random padding at the end, which is no longer in use: subliminal channel, consumption of randomness which may be expensive. Additionally, it would require knowing the message length in advance, which is a practical limitation.

2

In May 2015, header files were uploaded to the OASIS PKCS 11 TC document repository by Dina Kurktchi-Nimeh that were versioned v2.40. However, they were uploaded to the "Working Drafts" folder. The meeting minutes from 2015-04-15 state that v2.40 is complete, but there is an action item for Dina to publish header files for v2.40 with errata (what would ...

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