Re: Intel to also add RNG
On Tue, Jul 13, 2010 at 05:46:36PM +1200, Peter Gutmann wrote: Paul Wouters p...@xelerance.com writes: Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. Do you have any more details on this? Was it a hardware problem, software problem, ...? How was it caught? I couldn't say, as regards AMD's chipset RNG. Intel's, however, was on an optional component of one of their motherboard chipsets. Many motherboard vendors chose to buy that component from other sources, who implemented something register-compatible to the Intel part but with the RNG register not actually connected to a random number source. Worse, when Intel increased chipset integration and pulled the optional chip into one of the host bridge chips, they did the exact same thing. The basic problem was that the register indicating presence-of-RNG was not on the same piece of silicon (originally) as the actual RNG. So the register really indicated only that this Intel chipset *was capable of interfacing to the chip with the RNG on it*; nothing more. Worse, a lot of people read noise -- but not really random noise -- from those notional RNG registers and persuaded themselves that since the output wasn't continuous, there must really be an RNG present. Oops. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Encryption and authentication modes
What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? Are there any traps I should be aware of when implementing CCM? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On 12 July 2010 18:13, Jack Lloyd ll...@randombit.net wrote: On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: BTW, let me note that if Intel wanted to gimmick their chips to make them untrustworthy, there is very little you could do about it. The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. Given that, I see little reason not to trust them on an RNG, and I wish they would make it a standard part of the architecture already. I think it's important to make the distinction between trusting Intel not to have made it actively malicious, and trusting them to have gotten it perfectly correct in such a way that it cannot fail. Fortunately, the second problem, that it is a well-intentioned but perhaps slightly flawed RNG [*], could be easily alleviated by feeding the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take your pick I guess). And the first could be solved by also feeding your CSPRNG with anything that you would have fed it with in the absense of the hardware RNG - in that case, you're at least no worse off than you were before. (Unless your PRNG's security can be negatively affected by non-random or maliciously chosen inputs, in which case you've got larger problems). Several years ago I reviewed a new design for FreeBSD's PRNG. It was vulnerable to sources that had high data rates but low entropy (they effectively drowned out lower data rate sources). This was fixed, but I wonder how common an error it is? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
On Jul 14, 2010, at 1:52 AM, Florian Weimer wrote: What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? If there is no room for or an integrity field, you can look at XTS-AES. http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf Are there any traps should be aware of when implementing CCM? CCM is a counter mode cipher, so don't reuse the count (with any reasonable probability). Jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? Are there any traps I should be aware of when implementing CCM? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com CCM is widely implemented. It's a matter of where you look. Down at the MAC layer, AES-CCM has proved popular in wireless packet communication because it is well adapted for separating the treatment of the header as plaintext AAD from the packet body as ciphertext. Also it is relatively efficient to implement in hardware since it relies only on a single AES encrypt block cipher and the birthday resistance of the ciphertext MAC reduces on-air per packet overhead. This is the why for example that you see AES-CCM in wireles USB, 802.11, 802.16 and WiMAX management protocols. A couple of years after 802 went for AES-CCM, AES-GCM became the 802.3/ethernet choice since it is more parallelizable and so can be implemented for 10Gbps+ links where CCM becomes trickier. The per packet overhead is higher, but bandwidth on wires is cheap. I don't think you can really implement CCM except in the context of a more detailed specification for a protocol. CCM is a flexible specification and protocols that use it must nail down a number of parameters and field sizes in order to be interoperable. It's not so easy to just plug it in which makes is less convenient for the more pluggable software based protocols higher up the stack. Some technically good candidates for standards adoption, E.G. OCB met resistance due to licensing issues. DJ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
new tech report on easy-to-use IPsec
Folks on this list may be interested in a new tech report: Shreyas Srivatsan, Maritza Johnson, and Steven M. Bellovin. Simple-VPN: Simple IPsec configuration. Technical Report CUCS-020-10, Department of Computer Science, Columbia University, July 2010. http://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 The IPsec protocol promised easy, ubiquitous encryption. That has never happened. For the most part, IPsec usage is confined to VPNs for road warriors, largely due to needless configuration complexity and incompatible implementations. We have designed a simple VPN configuration language that hides the unwanted complexities. Virtually no options are necessary or possible. The administrator specifies the absolute minimum of information: the authorized hosts, their operating systems, and a little about the network topology; everything else, including certificate generation, is automatic. Our implementation includes a multitarget compiler, which generates implementation-specific configuration files for three different platforms; others are easy to add. We hope to have the code up on Sourceforge soon. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Fw: [IP] Two new rulings on Internet anonymity
Forwarded from Dave Farber's list: From: Paul Levy pl...@citizen.org Date: July 14, 2010 1:06:10 PM EDT To: d...@farber.net Subject: Two new rulings on Internet anonymity Within a few hours of each other, two significant decisions have come down on the issue of how to decide whether to compel the identification of anonymous Internet speakers. I discuss them at http://pubcit.typepad.com/clpblog/2010/07/two-new-cases-on-internet-anonymity.html Paul Alan Levy Public Citizen Litigation Group 1600 - 20th Street, N.W. Washington, D.C. 20009 (202) 588-1000 http://www.citizen.org/litigation - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
