# Tag Info

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

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

6

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

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

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

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

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

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

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

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

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 ... 2 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 ... 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 ... 1 This is more a legal question than a cryptographic one. Therefore I would like to note that I can not provide any legal advice and that you should ask a lawyer about the details of your individual case. But, to share my point of view which I base on my personal experience: If a company owns a patent (on an encryption technology, or anything else), they ... 1 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 ... 1 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 ... 1 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 ...

1

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