Tag Info

Hot answers tagged

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


9

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


7

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

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


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


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

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

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


5

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


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


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

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


3

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.


3

I wonder why anyone would choose to rely on a source of true random numbers fraught with questions that will ultimately have no provable - or perhaps even satisfactory - answer. There are at least a couple of companies that sell generators that provide high quality true random numbers. Having a generator on-site and available real-time allows the necessary ...


3

This page gives details of a successful extraction of a 3DES key from an IBM 4758 (FIPS 140-1 Level 4): http://www.cl.cam.ac.uk/~rnc1/descrack/. In summary, it required 20 mins of access to the device, 2 days of (offline) cracking time, and about $1000 in equipment. Not sure if this quite answers the question you were asking in that it relies on ...


3

FIPS 140-2 Security Level 2 does not require any form of security measure to prevent extraction of secrets. It simply requires tamper evidence, that is, it should be possible to notice that such attack took place by looking (for instance) at some seal on the device or at a log file. To answer your question, extracting a secret may therefore take 0 seconds ...


3

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


3

Since you do not describe why TLS Handshake and IKE are appropriate in your situation, and as long as you don't describe your situation, it's hard to really help you. Also, you haven't stated if it's only IKE that's not appropriate, or if that also includes IKEv2 (which improved the IKE protocol). Therefore, I'll simply assume you meant both. As an ...


3

Your description of how RFC 5959 works isn't quite right. It is not quite correct to state that RFC 5959 encrypts using AES in ECB mode. A correct statement is: if the plaintext is exactly 128 bits, then use ECB mode, otherwise use a non-trivial mode of operation found in RFC 3394. In the former case, ECB mode is fine, since it's just a single block of ...


3

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


2

I cannot see it having a negative effect, only a positive effect. Let's look at the Reddit AMA of Glenn Greenwald and the relevant comment: There are hundreds of encryption standards compromised by the program the Guardian, NYT and PP all reported on. I have never seen any list of those standards and don't have it. If I did have it, I would publish it ...


2

This closure could have an unintended effect on security. If a researcher was attempting to use a NIST resource, he or she might turn to a third party due to the unavailability of the NIST site. This may spur awareness, interest, or growth in other international standards bodies, such as ISO, or even to form an ECRYPT-III effort. If that third party turns ...


2

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


2

I agree that Gilles' interpretation in the comments is the only one that makes sense; the RFC clearly contains an editorial error, and should read either (emphasis indicates corrections): "If the value calculated by the authentication server matches the value calculated by the client, then the HOTP value is validated." or: "If the value received by ...


2

I went with PKCS#8 and Bouncy Castle specific PBEWithSHA256And256BitAES-CBC-BC encryption. Unfortunately BC nor Java doesn't support regular PBE with SHA1 and AES. Exact implementation is at stackoverflow.com question.



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