Re: [cryptography] Is KeyWrap (RFC 3394) vulnerable to CCAs?

The NIST Key Wrap is unauthored, which in practice means it's an NSA construction. That doesn't mean it's insecure. In fact if anything it's over-engineered. It's designed to achieve CCA2 security (or an equivalent deterministic definition) for high-entropy messages. It probably does that,

Re: [cryptography] 100 Gbps line rate encryption

The use of RC4 should be avoided even with the drop-N due to biases that occur later in the key stream. You should also be extremely careful about mixing IVs with the key. At a minimum you ought to use a modern cryptographic hash function -- there's no evidence that repeating key setup is

Re: [cryptography] DeCryptocat

On Jul 5, 2013, at 12:01 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: On 2013-07-05, at 3:15 AM, Jacob Appelbaum ja...@appelbaum.net wrote: Nadim Kobeissi: Hello everyone, I urge you to read our response at the Cryptocat Development Blog, which strongly clarifies

[cryptography] libzerocoin

Hi everyone, We've released the source to libzerocoin, a library that implements the core cryptographic routines for the Zerocoin protocol. https://github.com/Zerocoin/libzerocoin This is still development code and we'd appreciate any code review people can offer. Please tear it apart.

Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel

I assume you're talking about confidentiality and authenticity. If all you care about is authenticity then you can proceed under the assumption that the channel /may/ be authentic and then later perform the authentication to retrospectively authenticate it. This is obviously duh, but it's also

Re: [cryptography] Regarding Zerocoin and alternative cryptographic accumulators

Hi Adam, Jane, I'm not as familiar with Lipmaa's construction as I am with the RSA-based and bilinear accumulators. However, I note that Lipmaa's proposals rely on strong (or at least, new) hardness assumptions in class groups of imaginary quadratic order. Lipmaa points out the need for

Re: [cryptography] Just how bad is OpenSSL ?

So: 1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch? 2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary? 3. It's 2012 -- why the

Re: [cryptography] Compression Attack on SSL

Or if you want a more formal analysis (from 2002), see this paper by Kelsey. Particularly sections 5 6: http://www.iacr.org/cryptodb/data/paper.php?pubkey=3091 The real question is: how many sites actually support TLS compression? How much practical impact does CRIME really have? Matt On

Re: [cryptography] cryptanalysis of 923-bit ECC?

I don't understand the last few posts here. In the paper linked to by Samuel Neves: http://eprint.iacr.org/2012/042 Table 3, towards the top. (I read that as 2^53 steps.) So to me, the recent result is we verified computationally that our analysis is correct. Maybe my brain is too

Re: [cryptography] cryptanalysis of 923-bit ECC?

I'm definitely /not/ an ECC expert, but this is a pairing-friendly curve, which means it's vulnerable to a type of attack where EC group elements can be mapped into a field (using a bilinear map), then attacked using an efficient field-based solver. (Coppersmith's). NIST curves don't have this

Re: [cryptography] cryptanalysis of 923-bit ECC?

I've been told (by somebody much more diligent than I, who actually did the math) that the number of compute-cycles works out to around 2^64. The theoretical number of steps required is 2^53. Of course, each step is /not/ 1 cycle, so if we assume that they're around 2048 cycles each it's right

Re: [cryptography] cryptanalysis of 923-bit ECC?

: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 20, 2012, at 8:35 AM, Matthew Green wrote: I'm definitely /not/ an ECC expert, but this is a pairing-friendly curve, which means it's vulnerable to a type of attack where EC group elements can be mapped into a field (using

Re: [cryptography] Intel RNG

i'll concede the point that you'd only want raw bits to validate CRI and Intel assurances, and they've done due diligence. this is something i like to verify myself; no fault with the Intel design or CRI analysis implied. If you assume that every manufactured device will meet the standards

Re: [cryptography] Intel RNG

The fact that something occurs routinely doesn't actually make it a good idea. I've seen stuff in FIPS 140 evaluations that makes my skin crawl. This is CRI, so I'm fairly confident nobody is cutting corners. But that doesn't mean the practice is a good one. On Jun 18, 2012, at 5:52 AM,

Re: [cryptography] Intel RNG

On Jun 18, 2012, at 4:21 PM, Jon Callas wrote: Reviewers don't want a review published that shows they gave a pass on a crap system. Producing a crap product hurts business more than any thing in the world. Reviews are products. If a professional organization gives a pass on something that