# Tag Info

## Hot answers tagged standards

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

14

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

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

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 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 ... 7 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 ... 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 ... 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 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 ... 6 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 ... 6 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 ... 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 ... 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 ... 5 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 to2^{64}$blocks with the same key, so you should change the key long before ... 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 here.... 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 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$e⋅d≡1\pmod{\operatorname{lcm}_{i=1}^u(r_i-...

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

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

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

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

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

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

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