Re: [Cryptography] P=NP on TV
On 10/6/2013 12:17 PM, Salz, Rich wrote: Last week, the American TV show Elementary (a TV who-done-it) was about the murder of two mathematicians who were working on proof of P=NP. The implications to crypto, and being able to crack into servers was covered. It was mostly accurate, up until the deux ex machine of the of the NSA hiding all the loose ends at the last minute. J Fun and available at http://www.cbs.com/shows/elementary/video/ That gets to the heart of why I think P != NP. We are led to believe that if it is shown that P = NP, we suddenly have a break for all sorts of algorithms. So if P really does = NP, we can just assume P = NP and the breaks will make themselves evident. They do not. Hence P != NP. Wheres my Field's Medal? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
On 10/1/2013 2:34 AM, Ray Dillinger wrote: What I don't understand here is why the process of selecting a standard algorithm for cryptographic primitives is so highly focused on speed. ~ What makes you think Keccak is faster than the alternatives that were not selected? My implementations suggest otherwise. I thought the main motivation for selecting Keccak was Sponge good. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG
On 9/8/2013 4:27 AM, Eugen Leitl wrote: - Forwarded message from James A. Donald jam...@echeque.com - Date: Sun, 08 Sep 2013 08:34:53 +1000 From: James A. Donald jam...@echeque.com To: cryptogra...@randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jam...@echeque.com On 2013-09-08 3:48 AM, David Johnston wrote: Claiming the NSA colluded with intel to backdoor RdRand is also to accuse me personally of having colluded with the NSA in producing a subverted design. I did not. Well, since you personally did this, would you care to explain the very strange design decision to whiten the numbers on chip, and not provide direct access to the raw unwhitened output. #1 So that that state remains secret from things trying to discern that state for purposes of predicting past or future outputs of the DRBG. #2 So that one thread cannot undermine a second thread by putting the DRNG into a broken mode. There is only one DRNG, not one per core or one per thread. Having one DRNG per thread would be one of the many preconditions necessary before this could be contemplated. #3 Any method of access is going have to be documented and supported and maintained as a constant interface across many generations of chip. We don't throw that sort of thing into the PC architecture without a good reason. #4 Obviously there are debug modes to access raw entropy source output. The privilege required to access those modes is the same debug access necessary to undermine the security of the system. This only happens in very controlled circumstances. A decision that even assuming the utmost virtue on the part of the designers, leaves open the possibility of malfunctions going undetected. That's what BIST is for. It's a FIPS and SP800-90 requirement. That is a question a great many people have asked, and we have not received any answers. Yes they have. I've answered this same question multiple times. Access to the raw output would have made it possible to determine that the random numbers were in fact generated by the physical process described, since it is hard and would cost a lot of silicon to simulate the various subtle offwhite characteristics of a well described actual physical process. Access to the raw output would have been a massive can of worms. The statistical properties of the entropy source are easy to model and easy to test online in hardware. They are described in the CRI paper if you want to read them. That's a necessary part of a good entropy source. If you can't build an effective online test in hardware then the entropy source is not fit for purpose. DJ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Can you keep a secret? This encrypted drive can...
Leichter, Jerry wrote: | Jon Callas wrote: | | | Moreover, AES-256 is 20-ish percent slower than AES-128. | Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much | data. AES-256 has a 256-bit key but exactly the same 128-bit block as AES-128 (and AES-192, for that matter). | So when implemented in hardware, AES-256 is substantially faster. | | AES-256 - 18.26 bits per round | AES-128 - 12.8 bits per round | | I imagine that this would matter when the implementation is in a hard disk or | disk interface. It would, if it were true. -- Jerry I stand corrected.. The source of my error was reading the rijndael spec, not the nist spec. DJ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Jon Callas wrote: Moreover, AES-256 is 20-ish percent slower than AES-128. Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much data. So when implemented in hardware, AES-256 is substantially faster. AES-256 - 18.26 bits per round AES-128 - 12.8 bits per round I imagine that this would matter when the implementation is in a hard disk or disk interface. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISO rejects WAPI (for now)
Joachim Strombergson wrote: Aloha! I don't know if you have seen this, but ISO rejected the WAPI standard proposal, opting instead for 802.11i/WPA2. http://eet.com/news/design/business/showArticle.jhtml?articleID=181502994 How terrible, AES instead of the secret sauce-cipher. ,-) WAPI is no longer secret sausce. It has been published in Chinese, including the formerly unpublished SMS4 block cipher. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]