Hot answers tagged

24

Is this number specified anywhere? It was formally specified in this RFC as the 1536 bit MODP group (although its use predates that RFC). However, from what I've seen, the 2048 bit MODP group from that same document is actually more popular. Why was this particular number picked? Well, it's a safe prime; in addition, the leading 64 bits and the ...


6

Much of what NIST publishes about cryptographic algorithms is in Special Publications. In this case it is SP 800-131 (pdf) where they describe transitioning away from old algorithms and key sizes. Pages 14-15 have the hash function specific information: SHA-1 for digital signature generation:      SHA-1 may only be used for ...


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


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


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.


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


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

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


3

To clarify scope: FIPS 140-2 itself doesn't say anything about DSS, though it has 186-2 as a reference. It was published in 2001, before 186-3 and -4, and has not been superseded. After 140-3 spent 8 years in draft they recently decided to consider using ISO/IEC 19790 instead! 140-2 Annex A (Approved functions) is updated frequently and does now reference ...


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

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.


1

This particular prime has been widely used in implementations of the Internet Key Exchange Protocol (IKE) and commonly referred to as Group 5. Group 5 has been in many devices for over a decade. Depending on your viewpoint this fact is either good or bad. It's good if you are implementing IKE and want to interoperate with other implementations of IKE. It ...


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



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