Hot answers tagged

13

At the time of the competition (I can talk about it, I was there), there was a lot of discussion and various people showed arguments. However, there was never an official, publicly known "board of scores" with totals and definite rules, as the pictures you show seem to purport. It is possible that the NIST people did make something similar internally, but ...


11

I would characterize the service as similar to a trusted time-stamping service. Except they do not do the time-stamping, but just provide the "key". This allows a user to decide what do to with it, such as using it as a private key to sign something, or an HMAC key, proving the signature is "not older" than the timestamp. If the signature is published to a ...


10

This closure is a rather stupid thing, because the Web site is not closed: indeed, there still is a machine, somewhere, which responds to HTTP requests and returns the "we are closed" page. It would have cost zero effort, and zero extra money, to simply let the Web site run and keep on serving PDF files. For crypto development, this means that until the US ...


8

Bernstein and Lange says that there has been no progress for prime-field elliptic curves since about 1999, when the NIST curves were chosen. No large class of weak curves were known then, and no large class is known now. Some small classes are known, (as Neves says) the curves with small embedding degree and the anomalous curves (order $n$ equals the prime ...


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


7

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


7

PSS is harder to implement because it uses randomness -- randomness is hard on many embedded systems like smart cards. The most proclaimed advantage of PSS is that it has a "security proof" with, apparently, a rather tight reduction (see this page for some references). Security proofs are not an easy subject; the proof for OAEP (the encryption padding which ...


6

As far as I can tell, NIST has only one official document about entropy collection. SP-800-90B. The purpose of NIST Special Publication (SP) 800-90B is to specify the design and testing requirements for entropy sources that can be validated as approved entropy sources by NIST‘s CAVP and CMVP. It essentially defines a bunch of statistical tests to ...


6

This is all about the question of risk assessment. Are you willing to risk all devices together so that if one key is compromised, they all have to be returned? What is the cost of one return, 100 returns, or 100,000 returns? What is the expense of issuing a master key? Of issuing ten master keys? Of issuing a thousand? Do you have an estimate for how ...


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

It's merely an update to align the hashing algorithms. There are in fact no real "consequences" which might have any negative impact as the v2.1 schemes are still supported. The positive impact is the alignment with FIPS 180-4. To quote the revision history at page 59 of "PKCS #1 v2.2: RSA Cryptography Standard": Version 2.2 updates the list of allowed ...


5

I don't know, but block-cipher based modes of operation have seen a lot more scrutiny. AES in CTR mode has been vetted much more thoroughly than any of those stream ciphers you mention. Moreover, those stream ciphers do not offer compelling benefits over AES-CTR mode. Therefore, it seems to me it would be entirely reasonable to focus on block-cipher based ...


5

Under the assumption that $(K,\text{Msg})\to H_K(\text{Msg})$ is a secure MAC (be it HMAC or any other MAC), and $\text{Nonce}$ does not repeat and is of fixed size, both $H_K(\text{Msg}||\text{Nonce})$ and $H_K(\text{Nonce}||\text{Msg})$ are demonstrably secure, in the sense that an adversary not knowing $K$ can't distinguish either from random, even for ...


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

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

The cornerstone of the handshake security is that the Finished messages, sent under the protection of the newly exchanged key (for encryption and MAC), contain hash values computed over all the handshake messages exchanged so far, including the list of cipher suites and all other parameters. As long as client and server don't negotiate the use of a cipher ...


4

Q1: Why are these tests stroked out? These tests are stroked out on pages 57-58 of the current FIPS 140-2 because they are no longer part of the current FIPS 140-2 standard, since Change Notice 2 of 2002 December third, where these pages belong. My guess for the rationale of removing these tests is that It was realized that the very principle ...


4

$\pi$ is the transcendental number 3.1415926... It's there in the formula to show this specific number was not chosen with a specific cryptographical backdoor in mind; it seems unlikely that anyone was able to select the value of $\pi$ (unless Carl Sagan was correct, of course :-)


4

Yes. $\:$ "simply XORing" is obviously malleable, which may allow related-key attacks. "When storing a short key, e.g. a 256-bit ECC private key," the "good reason to use AES" is that "the XOR with a single PBKDF2 (or other KDF) output block" is not necessarily sufficient, since an adversary might also have changed the stored public key.


4

First up: Don't believe the hype! Especially if things can easily be proven wrong. What I mean is that your NIST have just launched a new service… is incorrect, as the NIST Randomness Beacon project is known to me (and others) since 2011. Furthermore, this project was awarded a multi-year grant from NIST's Innovations in Measurement Science (IMS) Program in ...


4

Since the rationale for the exclusion of P-521 and AES-192 is not explained, you can assume that either the curve is "too good" or that the cipher is "not good enough". The exclusion of SHA-512 implies a limit to 192-bit security for the standard, so AES-192 would be the logical choice. Its exclusion implies it is in someway not adequate for protecting TOP ...


4

Multi-prime RSA (also known as RSA-MP) is supported by PKCS#1v2. This standard supports a public key $(n,e)$ where the modulus $n$ is the product of $u≥2$ distinct odd primes: $n=\prod_{i=1}^u{r_i}$, with $1<e<n$ and $\gcd(r_i-1,e)=1$ (implying $e$ odd). The private exponent $d$ is such that $1<d<n$, and ...


4

There is no general way to compute the "cryptoperiod". Usually, the algorithm should specify how often you need to change keys, to achieve a desired level of security against cryptanalysis attacks. For instance, AES in CBC mode has some weaknesses once you encrypt anywhere close to $2^{64}$ blocks with the same key, so you should change the key long before ...


4

The answer is either "no" or "it depends". Generally speaking, RSA-PSS is more robust, in the sense that you don't have to take as many extra precautions in order to use it securely. RSA-PKCS#1-v1.5 is OTOH more widely supported by pre-exisiting software, but you sometimes have to patch the way it is used in order to prevent exploits. For instance, if you ...


4

RFC 5958 and RFC5959 seems to be the latest standard for storing encrypted private keys. It obsoletes RFC 5208, also known as PKCS#8. My understanding is that AES is one of the many encryption algorithms supported by RFC 5958. The GNU Keyring File Format is a another standard for a file format that stores private keys using AES-128. The Gnome Keyring ...


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


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



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