Re: [cryptography] Intel RNG
On Jun 18, 2012, at 9:03 PM, Matthew Green wrote: 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 turned out to be bad, it can (and has) destroyed the organization. I would really love to hear some examples from the security world. I'm not being skeptical: I really would like to know if any professional security evaluation firm has suffered meaningful, lasting harm as a result of having approved a product that was later broken. I can think of several /counterexamples/, a few in particular from the satellite TV world. But not the reverse. Anyone? The canonical example I was thinking of was Arthur Anderson, which doesn't meet your definition, I'm sure. But we'll never get to requiring security reviews if we don't start off seeing them as desirable. Jon PGP.sig Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 18, 2012, at 4:12 PM, Marsh Ray wrote: 150 clocks (Intel's figure) implies 18.75 clocks per byte. That's not bad at all. It's in the neighborhood of what I remember my DRBG running at with AES-NI. Faster, but not by a lot. However, I will getting the full 16 bytes out of the AES operation and RDRAND is doing 64 bits at a time, right? Note that Skein 512 in pure software costs only about 6.25 clocks per byte. Three times faster! If RDRAND were entered in the SHA-3 contest, it would rank in the bottom third of the remaining contestants. http://bench.cr.yp.to/results-sha3.html As much as it warms my heart to hear you say that, it's not a fair comparison. A DRBG has to do a lot of other stuff, too. The DRBG is an interesting beast and a subject of a whole different conversation. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: windows-1252 wj8DBQFP4B3lsTedWZOD3gYRAkegAJ0Z491IAfNVXX3hKOdOghPczZmWMACgztIG Ym7qE1e/es0m0o+macE+Iv0= =GJXv -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am reminded of an article my dear old friend, Martin Minow, did in Cryptologia ages ago. He wrote the article I think for the April 1984 issue. It might not have been 1984, but it was definitely April. In it, he described a cryptosystem in which you set the key to be the same as the plaintext and then XOR them together. There is a two-fold beauty to this. First that you have full information-theoretic security on the scheme. It is every bit as secure as a one-time pad without the restrictions of a one-time pad as to randomness of the keys and so on. The second wonderful property is that the ciphertext is compressible. Usually cipher text is not compressible, but in this case it is. Moreover, it is *maximally* compressible. The ciphertext can be compressed to a single bit and the ciphertext length recovered after key distribution. I think that non-decryptable encryption really needs to cite Minow's pioneering work. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFP4CW6sTedWZOD3gYRAgW8AKCpdVUpa1CpDpn5F6ZB4hezweGa9gCgz/62 m2eb/GnTagRxb6O0ct0a2oQ= =Gwp3 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 19, 2012, at 12:09 AM, Jon Callas wrote: * PGP Signed: 06/19/2012 at 12:09:46 AM I am reminded of an article my dear old friend, Martin Minow, did in Cryptologia ages ago. He wrote the article I think for the April 1984 issue. It might not have been 1984, but it was definitely April. 1986. Cryptologia, Volume 10, Issue 2, 1986. The article is entitled NO TITLE. The first page is available here: http://www.tandfonline.com/doi/abs/10.1080/0161-118691860912 but sadly the rest of it is behind a paywall that wants $43 for the issue (or the whole volume for $58, such a bargain). Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFP4CoEsTedWZOD3gYRAouxAKDSMxRISY7BgZ7aLZ8TxCbm2uX+9gCg8T8E J/rdgBl2nIaHES8X2nWp0QY= =LZvI -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
And, to get back on topic after having gone dangerously off topic: The market for cryptography is the market for silver bullets: Those actually paying money cannot tell the difference between real experts and salesmen, thus the incentive to actually be any good at this is not high. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote: ... Right, 500 MB/s of random numbers out to be enough for anybody. these rates often are not useful. even busy secure web or VPN servers use orders of magnitude less. initialization of full disk crypto across an SSD RAID could consume it, but that's the only practical use case i've encountered so far :) that said, a typical host entropy gathering daemon is often insufficient, and even off-die serial bus and other old skewl sources were providing entropy in kbit/sec rates, not MByte/sec. My main point in running the perf numbers was to figure out the justification for this RNG not being vulnerable to entropy depletion attacks in shared hosting environments. some (many?) HWRNG designs use bit accumulators that feed a register that is read by a userspace instruction. consider the following configuration: - this register is collecting single bits from two high speed oscillators that is sub-sampling single bits at a quarter clock. - only whitened / non-run bits collected, as set in a configuration write / initialization. in short: providing slow, non-deterministic output rates to this entropy instruction. if the instruction is configured to not-block, you could starve the available pool in one thread, in one process, by using it aggressively. if the instruction is configured to block, you could introduce significantly processing delays (unexpectedly so?) to other consumers in other threads of execution, or other processes. Intel did an end run around this problem with the DRBG, which is similar to urandom, in the sense that it does not provide a 1:1 correlation of entropy in the system to entropy bits returned out, as you may get in /dev/random linux behavior, which blocks once the kernel entropy pool is exhausted. (that's another rant/tangent. let's not go there :) Still, 150 clocks is a crazy long time for an instruction that doesn't involve a cache miss or a TLB flush or the like. ... So something is causing AES-NI to take 300 clocks/block to run this DRBG. Again, more than 3x slower than the benchmarks I see for the hardware primitive. My interpretation is that either RdRand is blocking due to entropy depletion, there's some internal data pipe bottleneck, or maybe some of both. it is also seeding from the physical noise sources, running sanity checks of some type, and then handing over to DRBG. so there is clearly more involved than just a call to AES-NI. 3x as expensive doesn't sound unreasonable if the seeding and validation overhead is significant. If in reality there's no way RDRAND can ever fail to return 64 bits of random data, then Intel could document that fact and we could save the world from yet another untested exceptional code path that only had a moderate chance of working the first time it's really needed anyway. that's a great idea, and my reading of it is that they have said as much. perhaps they should more clearly state it so for the usual case. my understanding is that you will never fail unless the hardware itself starts up? with a broken physical source returning clearly invalid bits. E.g. In the rare event that the DRNG fails during runtime, it would cease to issue random numbers rather than issue poor quality random numbers. as for stating that it should never run dry, or fail to not return bits as long as the instruction is working, no matter how frequently it is invoked, see: With respect to the RNG taxonomy discussed above, the DRNG follows the cascade construction RNG model, using a processor resident entropy source to repeatedly seed a hardware-implemented CSPRNG. Unlike software approaches, it includes a high-quality entropy source implementation that can be sampled quickly to repeatedly seed the CSPRNG with high-quality entropy. Furthermore, it represents a self-contained hardware module that is isolated from software attacks on its internal state. The result is a solution that achieves RNG objectives with considerable robustness: statistical quality (independence, uniform distribution), highly unpredictable random number sequences, high performance, and protection against attack. Protecting online services against RNG attacks [read: high entropy consumption servers] ... Throughput ceiling is insensitive to the number of contending parallel threads take with a gran of salt; this is all from their documentation: http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
coderman coder...@gmail.com writes: On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote: ... Right, 500 MB/s of random numbers out to be enough for anybody. these rates often are not useful. even busy secure web or VPN servers use orders of magnitude less. initialization of full disk crypto across an SSD RAID could consume it, but that's the only practical use case i've encountered so far :) Not even that, you'd just use it to seed AES-CTR and use that for the initialisation. Generator bit-rates seem to be like Javascript engine speeds, a mostly pointless [0] figure that's provided so you can show that you've managed to crank your numbers higher than everyone else's, like Benzino Napaloni and Adenoid Hynkel cranking up their barber chairs. Peter. [0] I'm hedging my bets here with mostly, in practice I think it's closer to entirely pointless. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
What I think people react on is that it's really pointless to use decimals and having to keep track of when they repeat. A simple RNG with normal numbers could be used instead, and probably *should* be used unless your crypto really *needs* numbers consisting of primes divided by primes. So essentially, they hang up on repeating decimals since they expect there to be a reason for why they are needed which they can't find, but there are none AFAIK. - Sent from my tablet Den 19 jun 2012 12:03 skrev Givonne Cirkin givo...@37.com: of course this would fail at the first repeat. briefly stated in the article in fact. the point made is, that until the first repeat you get a sequence of non-repeating digits. and, we can generate such a sequence, a repeating decimal--by equation. so, why not choose the right length repeating decimal for a message of a given length. i don't understand why is it clear to some they get it right away. why do others not see it? i thought i was clear to use the sequence up until the first repeat. --- jam...@echeque.com wrote: From: James A. Donald jam...@echeque.com To: cryptography@randombit.net Subject: Re: [cryptography] non-decryptable encryption Date: Tue, 19 Jun 2012 17:02:27 +1000 On 2012-06-18 8:56 PM, Givonne Cirkin wrote: Hi, My name is Givon Zirkind. I am a computer scientist. I developed a method of encryption that is not decryptable by method. You can read my paper at: http://bit.ly/Kov1DE My colleagues agree with me. But, I have not been able to get pass peer review and publish this paper. In my opinion, the refutations are ridiculous and just attacks -- clear misunderstandings of the methods. They do not explain my methods and say why they do not work. I have a 2nd paper: http://bit.ly/LjrM61 This paper also couldn't get published. This too I was told doesn't follow the norm and is not non-decryptable. Which I find odd, because it is merely the tweaking of an already known method of using prime numbers. This fails at the first repeat, and has no relationship to the already known method of using prime numbers. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography _ You @ 37.com - The world's easiest free Email address ! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
I think your problems are these: You don't understand what makes XOR (one time pad crypto) uncrackable (and *that* is the term you want, not undecryptable). You can't explain the advantage of your system well. It would be vulnerable to timing attacks if implemented (the time it takes reveals data). Those infinite varations are possible with other algorithms as well, just add random padding in the messages. You don't explain HOW the reciever will know how to decrypt. Compare with encryption modes for AES: CBC, XTS, counter mode, ECB... You must tell the recipient what you are using. This can't be encrypted, or else the method of encrypting *that* info might as well be uses for encrypting the whole thing. - Sent from my tablet Den 19 jun 2012 12:39 skrev Givonne Cirkin givo...@37.com: preferring one method to another, is a personal choice i understand. but, to be just off, i don't get. if no one understands, i need to stop rethink make a better presentation. if some get it some don't, depending how many, again i have to reassess my presentation. there's one in every crowd. more than one or two though... i also understand that this method would fail with brute force if the message were too small. but, in between all the primes we can find non-repeating sequences of any given length. but, how secure do u need? pgp is secure but decryptable. but, good enough for most ppl. I stand by phil zimmerman's point. most ppl use envelopes. easily opened. but a good deterent. --- natanae...@gmail.com wrote: From: Natanael natanae...@gmail.com To: givo...@37.com Cc: cryptography@randombit.net, jam...@echeque.com Subject: Re: [cryptography] non-decryptable encryption Date: Tue, 19 Jun 2012 12:07:26 +0200 What I think people react on is that it's really pointless to use decimals and having to keep track of when they repeat. A simple RNG with normal numbers could be used instead, and probably *should* be used unless your crypto really *needs* numbers consisting of primes divided by primes. So essentially, they hang up on repeating decimals since they expect there to be a reason for why they are needed which they can't find, but there are none AFAIK. - Sent from my tablet Den 19 jun 2012 12:03 skrev Givonne Cirkin givo...@37.com: of course this would fail at the first repeat. briefly stated in the article in fact. the point made is, that until the first repeat you get a sequence of non-repeating digits. and, we can generate such a sequence, a repeating decimal--by equation. so, why not choose the right length repeating decimal for a message of a given length. i don't understand why is it clear to some they get it right away. why do others not see it? i thought i was clear to use the sequence up until the first repeat. --- jam...@echeque.com wrote: From: James A. Donald jam...@echeque.com To: cryptography@randombit.net Subject: Re: [cryptography] non-decryptable encryption Date: Tue, 19 Jun 2012 17:02:27 +1000 On 2012-06-18 8:56 PM, Givonne Cirkin wrote: Hi, My name is Givon Zirkind. I am a computer scientist. I developed a method of encryption that is not decryptable by method. You can read my paper at: http://bit.ly/Kov1DE My colleagues agree with me. But, I have not been able to get pass peer review and publish this paper. In my opinion, the refutations are ridiculous and just attacks -- clear misunderstandings of the methods. They do not explain my methods and say why they do not work. I have a 2nd paper: http://bit.ly/LjrM61 This paper also couldn't get published. This too I was told doesn't follow the norm and is not non-decryptable. Which I find odd, because it is merely the tweaking of an already known method of using prime numbers. This fails at the first repeat, and has no relationship to the already known method of using prime numbers. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography _ You @ 37.com - The world's easiest free Email address ! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- You @ 37.com - The world's easiest free Email address ! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
Aloha! On 2012-06-19 11:30 , coderman wrote: On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote: So something is causing AES-NI to take 300 clocks/block to run this DRBG. Again, more than 3x slower than the benchmarks I see for the hardware primitive. My interpretation is that either RdRand is blocking due to entropy depletion, there's some internal data pipe bottleneck, or maybe some of both. it is also seeding from the physical noise sources, running sanity checks of some type, and then handing over to DRBG. so there is clearly more involved than just a call to AES-NI. 3x as expensive doesn't sound unreasonable if the seeding and validation overhead is significant. I might be missing something. But is it clear that Bull Mountain is actually using AES-NI? I assumed that one would like to use a separate HW-engine. Reading from the CRI paper seems (to me) to suggest that this is actually the case: Entropy conditioning is done via two independent AES-CBC-MAC chains, one for the generator’s key and one for its counter. AES-CBC-MAC should be suitable as an entropy extractor, and allows reuse of the module’s AES hardware. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
The digit sequence 0.1234567891011121314151617181920212223... (or its equivalent in binary, hex, or your other favorite base) never repeats, but provides no security whatsoever. One-time pads need nonrepeating sequences *which the adversary can't predict*. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cryptography Digest, Vol 28, Issue 23
Yes, it can be compressed to zero bits, and the decompression process will generate two alternative outputs. On Jun 19, 2012, at 8:06 AM, cryptography-requ...@randombit.net wrote: From: Ben Laurie b...@links.org To: Jon Callas j...@callas.org Cc: Crypto List cryptography@randombit.net Subject: Re: [cryptography] non-decryptable encryption The second wonderful property is that the ciphertext is compressible. Usually cipher text is not compressible, but in this case it is. Moreover, it is *maximally* compressible. The ciphertext can be compressed to a single bit and the ciphertext length recovered after key distribution. Surely it can be compress to no bits at all? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Mon, Jun 18, 2012 at 09:58:59PM -0700, coderman wrote: this is very useful to have in some configurations (not just testing). for example: a user space entropy daemon consuming raw, biased, un-whitened, full throughput bits of lower entropy density which is run through sanity checks, entropy estimates, and other vetting before mixing/obscuring state, and feeding into host or application entropy pools. Sanity checks, entropy estimates, and other vetting *which the output of a DRBG keyed in a known way by your adversary will pass without a hint of trouble*. It seems to me the only reason you'd benefit from access to the raw source would be if you believed Intel might have goofed the sanity checks. For my part, I am happy to rely on CRI's assurance that Intel's sanity checks are good. The only defense against a deliberately compromised hardware RNG is to mix it with something else. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Intel RNG, questions raised by the report
Hi! The interesting discussion induced me to look again to the actual report [1]. When I initially did, I came up with the impression that the RNG design is sound to the extent that a) any system based on sampling an unpredictable physical phenomenon has some intrinsic limitations, and b) you accept the NIST SP800-90 architecture. Furthermore, one has to read between the lines and make its own opinion. Here are the main questions that I had in my first (and again in my subsequent) quick reading : Q1. Do you like a system where the deterministic algorithms (conditioning, DBRG) are exposed only at the pseudocode level? Q2. If you want to build a production system with it, how do you define fail-safe? Stated otherwise, if the RNG signals its malfunction to the software, as a system integrator, how are you going to handle the negative customer perception that the the best commercially available RNG simply turns off the customer production system? Q3. Do you agree with the report authors when they write (end of section 3.2.1) Also, while such failures can cause the design to behave briefly as a cryptographically-strong deterministic RNG, this should not result in any loss of security. ? Q4. How do you get confidence that production parts are as good as the parts used in the report review? None of these are specific to the Intel RNG being reviewed; any serious RNG arrangement based on sampling an unpredictable phenomenon might trigger the same set of questions. Regards, [1] ANALYSIS OF INTEL’S IVY BRIDGE DIGITAL RANDOM NUMBER GENERATOR, prepared for intel by Mike Hamburg Paul Kocher Mark E. Marson Cryptography Research, Inc., March 12, 2012 http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/ -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
Aloha! On 2012-06-19 11:30 , coderman wrote: On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote: So something is causing AES-NI to take 300 clocks/block to run this DRBG. Again, more than 3x slower than the benchmarks I see for the hardware primitive. My interpretation is that either RdRand is blocking due to entropy depletion, there's some internal data pipe bottleneck, or maybe some of both. it is also seeding from the physical noise sources, running sanity checks of some type, and then handing over to DRBG. so there is clearly more involved than just a call to AES-NI. 3x as expensive doesn't sound unreasonable if the seeding and validation overhead is significant. I might be missing something. But is it clear that Bull Mountain is actually using AES-NI? I assumed that one would like to use a separate HW-engine. Reading from the CRI paper seems (to me) to suggest that this is actually the case: It is not using AES-NI. It is a self contained unit on chip with a built in HW AES encrypt block cipher. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Last call: DIAC: Directions in Authenticated Ciphers
For people interested in the future of secret-key cryptography, the list of talks for next month's ECRYPT DIAC workshop has now been posted: http://hyperelliptic.org/DIAC Registration is still open today: http://hyperelliptic.org/DIAC/registration.html Here's the list of invited speakers and refereed papers: * Invited: Joan Daemen, STMicroelectronics * Invited: David McGrew, Cisco * Invited: Phillip Rogaway, University of California at Davis * Invited: Palash Sarkar, ISI Kolkata * Refereed papers: - A Do-It-All-Cipher for RFID: design requirements (extended abstract) (Saarinen, Engels) - AEGIS: a fast authenticated encryption algorithm (Wu, Preneel) - An improved hardware implementation of the Grain-128a stream cipher (Mansouri, Dubrova) - Authenticated encryption in civilian space missions: context and requirements (Sanchez, Fischer) - Cryptanalysis of EAXprime (Minematsu, Lucks, Morita, Iwata) - Hash-CFB (Forler, McGrew, Lucks, Wenzel) - Heavy Quark for secure AEAD (Aumasson, Knellwolf, Meier) - How fast can a two-pass mode go? A parallel deterministic authenticated encryption mode for AES-NI (Aoki, Iwata, Yasuda) - Lightweight AES-based authenticated encryption (Bogdanov, Mendel, Regazzoni, Rijmen) - Permutation-based encryption, authentication and authenticated encryption (Bertoni, Daemen, Peeters, Van Assche) - SipHash: a fast short-input PRF (Aumasson, Bernstein) - Stronger security guarantees for authenticated encryption (Boldyreva, Paterson, Stam) - Suggestions for hardware evaluation of cryptographic algorithms (Gurkaynak) See you in Stockholm! ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 9:02 AM, d...@deadhat.com wrote: ... It is not using AES-NI. It is a self contained unit on chip with a built in HW AES encrypt block cipher. thanks for the clarification; is this documented somewhere? i am curious if the die space consumed for two implementations of AES in negligable on these very large cores, or if there is another reason to intentionally keep them separate. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 06/19/2012 01:59 PM, coderman wrote: thanks for the clarification; is this documented somewhere? i am curious if the die space consumed for two implementations of AES in negligable on these very large cores, or if there is another reason to intentionally keep them separate. It sounds to me like the AES CTR DRBG is shared between multiple cores. So keeping it independent of any one core sounds like a good reason to separate it. But then design decisions for these chips have mystified me in the past. (HT, SMM, etc. :-) - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 6:17 AM, Thor Lancelot Simon t...@panix.com wrote: ... Sanity checks, entropy estimates, and other vetting *which the output of a DRBG keyed in a known way by your adversary will pass without a hint of trouble*. absolutely; after it has gone through DRBG you have zero visibility into state of generation. even von neumann whitening and string filters obscure to some extent. It seems to me the only reason you'd benefit from access to the raw source would be if you believed Intel might have goofed the sanity checks. For my part, I am happy to rely on CRI's assurance that Intel's sanity checks are good. the sanity checks, being on die, are limited. you can't run DIEHARD against this in a useful manner because the DRBG obscures anything useful. 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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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 of Intel's test units, then you can live with the CRI/Intel review. If you're /not/ confident in that assumption, the ability to access raw ES output would be useful...___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
I would really love to hear some examples from the security world. The canonical example I was thinking of was Arthur Anderson, which doesn't meet your definition, I'm sure. I would not wait for such clarity; the bond rating agencies still live while the sovereigns they rated are busily defaulting. --dan It is criminal to steal a purse, daring to steal a fortune, a mark of greatness to steal a crown. The blame diminishes as the guilt increases. -- Friedrich Schiller ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 06/19/2012 02:11 PM, coderman wrote: the sanity checks, being on die, are limited. you can't run DIEHARD against this in a useful manner because the DRBG obscures anything useful. I don't think there's anything useful diehard (specifically) is going to tell you. The raw entropy source output would not be expected to pass diehard. The CR report shows visible artifacts in that FFT graph. The entropy estimation function one would apply to that source would likely be much simpler than the diehard suite. Just a sanity check that the output is actually changing once in a while would go a long way towards eliminating the most common failure modes. On the other hand, the AES CTR DRBG output will always pass diehard, whether it contains any entropy or not. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 2012-06-19 4:51 AM, Matthew Green wrote: 1. Private evaluation report (budgeted to, say, 200 hours) probabilistically identifies N serious vulnerabilities. We all know that another 200 hours could turn up N more. In fact, the code may be riddled with errors. Original N vulnerabilities are patched. What should the public report say? Technically the vulnerabilities are all 'fixed'. If the public report says what it should say, lots of people will be unhappy. So, what happens if the public report sounds like it saying that the product is fine, but in fact the product is crap, and disaster ensues? Answer: Absolutely nothing. Example Wifi security, which somehow always uses fine methods in unusual ways. The same people who brought you yesterday's failed Wifi security, bring you today's. To summarize: Our mechanisms for social verification of truth are broken, and are getting more broken. Social verification tends to scale badly. They have never worked well, and are now working worse than ever. Nullius in verba: Take nobody's word for it This is the general problem with audits of all kinds, not just security audits. It is often not only impossible to punish the irresponsible, but even to identify them. Thus security source code simply has to be available, and that security hardware is what it claims to be has to be verifiable - which is why Intel should have made it possible to read the raw unwhitened output of its true randomness generator. And now I am once again going somewhat off topic on how our social verification mechanisms are completely broken - indeed it is very hard to make social verification work. For example the challenger inquiry found that some people had signed off both on reports that the space shuttle was going to explode, and also reports that it was good to go. But the culture was blamed, not any specific identifiable people. For example, try identifying who made, and who received, the dud loans that are at the root of the current financial crisis, and who commanded them to be made. It is mysteriously difficult to do so. For example the crisis at MF Global is everywhere described as a liquidity crisis. It was in fact a solvency crisis. Jon Corzine pissed away MF Global's assets on politically correct financial investments, and then kept the place operating for some time in a state of insolvency by borrowing from customer funds, but everyone continues to pretend that MF Global was solvent until it was not, because according to Sarbannes Oxley accounting standards, it was solvent until it was not, presaging an outcome in which no one gets punished. For example JPM realized it was receiving stolen funds from MF Global. There is a large audit trail of incriminating documents as the people at JPM wrestle with their consciences. After generating a large pile of highly incriminating paper, they win and their consciences lose. This will probably result in a civil lawsuit against JPM, for acting as a fence, but no criminal penalties, nor personal loss of jobs. Even though the trail of documents reveal that an ever increasing number of people connected to MF Global knew that MF Global was acting in a criminal manner, making them accessories after the fact, it still looks as though few, possibly no one, is going to see jail time. And of course, there are the Climategate files, but to go into any details on that can of worms would really take us right off topic. Since the widespread introduction of peer review in the 1940s, instead of the experimenter telling the scientific community what he observes, the scientific community tells the experimenter what he observes. The data cookery revealed by Climategate files is, arguably, business as usual. The defense was everyone is doing it, that is the way Official Science is actually done, which defense is, alas, entirely true. Peer Review was the abandonment of the principle of Nullius in Verba. Instead of taking no one's word for it, we take the word of a secretive and anonymous panel of referees, resulting in an ever escalating pile of bogus science. To make social verification work, people have to be punished for being untruthful, dishonest, and failing in their duty, or at least abruptly and irrevocably thrown out of social verification network for the slightest infraction. Which is not nice. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
absolutely true. i mentioned (in my article) that after explaining the masking. --- jth...@astro.indiana.edu wrote: From: Jonathan Thornburg jth...@astro.indiana.edu To: jam...@echeque.com, cryptography@randombit.net Subject: Re: [cryptography] non-decryptable encryption Date: Tue, 19 Jun 2012 08:30:59 -0400 (EDT) The digit sequence 0.1234567891011121314151617181920212223... (or its equivalent in binary, hex, or your other favorite base) never repeats, but provides no security whatsoever. One-time pads need nonrepeating sequences *which the adversary can't predict*. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography _ You @ 37.com - The world's easiest free Email address ! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] non-decryptable encryption
On 2012-06-19 8:03 PM, Givonne Cirkin wrote: i don't understand why is it clear to some they get it right away. why do others not see it? i thought i was clear to use the sequence up until the first repeat. This is just one time pad. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 06/19/2012 02:11 PM, coderman wrote: the sanity checks, being on die, are limited. you can't run DIEHARD against this in a useful manner because the DRBG obscures anything useful. I don't think there's anything useful diehard (specifically) is going to tell you. The raw entropy source output would not be expected to pass diehard. The CR report shows visible artifacts in that FFT graph. The entropy estimation function one would apply to that source would likely be much simpler than the diehard suite. Just a sanity check that the output is actually changing once in a while would go a long way towards eliminating the most common failure modes. On the other hand, the AES CTR DRBG output will always pass diehard, whether it contains any entropy or not. Yup. Actually having a perfect source is a problem. It's much easier to test for a source with known defects that meet a well defined statistical model. With that you can build a test that the circuit is built correctly. You can also show it catches all SPOF and DPOF cases. You use other techniques to prove that if built right, the circuit will have a well defined min entropy in the output. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 07:35:03PM -0700, coderman wrote: is there any literature on the typical failure modes of TRNG/entropy sources in deployed systems? my understanding is that they tend to fail catastrophically, in a way easily detected by FIPS sanity checks. E.g. clearly broken. I know of one case in which a design mistake may have caused related bits to be output. I think the FIPS statistical tests might have turned it up, but the continuous-output test might well not have. This was a design by Hifn where they reused an existing RNG block but changed the output LFSR and thus had to rework the interface to register exposed to the PCI bus in which they reported results. They left out a latch, so you could accidentally get the same bits from the LFSR twice or get an intermediate state where some bits were from the previous state and some were fresh. The COT would have caught the former, but given the clocks involved the former case would have been very, very unlikely. It would not have caught the latter. I never got a clear answer from Hifn whether they actually left the latch out of the silicon or just out of the documentation. However, I tried very hard to give them opportunities to tell me it was just the docs that were wrong, and they didn't. The workaround was to simply read the register repeatedly, discarding results, until one knew all the bits had to be fresh given the other clocks involved; inefficient, but it got the job done. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 2012-06-19 7:02 AM, Jack Lloyd wrote: You're not saying that CRI would hide things, you're just saying that accepting payment sets the incentives all the wrong way and that all companies would put out shoddy work so long as they got paid, especially if giving a bad review would make the customer mad. Again, observe what has been happening in our current financial crisis. What reason do we have to believe that CRI is more virtuous than JP Morgan? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 2012-06-19 9:07 AM, d...@deadhat.com wrote: It does tell you that if it is your chip and you don't let someone else pull the lid off, scrape off the passivation and apply a pico probe to it, it will certainly provide you with good random numbers regardless of the FIPS mode. I don't know that. Intel might have screwed up deliberately or unintentionally, or my particular chip might fail in a way that produces numbers that are non random, but, due to whitening, are non random in a way that only some people know how to detect If intel told me how it worked, and provided low level access to raw unwhitened output, I could find pretty good evidence that the low level randomness generator was working as described, and perfect evidence that the whitener was working as described. Certification does not tell me anything much. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 20/06/12 13:25 PM, James A. Donald wrote: On 2012-06-19 7:02 AM, Jack Lloyd wrote: You're not saying that CRI would hide things, you're just saying that accepting payment sets the incentives all the wrong way and that all companies would put out shoddy work so long as they got paid, especially if giving a bad review would make the customer mad. Again, observe what has been happening in our current financial crisis. What reason do we have to believe that CRI is more virtuous than JP Morgan? People. Some of you might know the guys at CRI and have some view as to how they would handle it. Do you have a view as to how audit people handle things? I remember sitting down with a big-N auditor in 1998 or so, and him telling me that the systems audit for major tech firm was a complete farce - the partners wrote all the bad bits out. Time. 100 years ago, JP Morgan was a byword for trust. Fast forward to now ... CRI is only 15 years old. Add a decade and will it still see the same interests? I'm sure it won't. The big question is not whether but when... iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 6/19/2012 7:35 PM, coderman wrote: On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray ma...@extendedsubset.com wrote: ... Just a sanity check that the output is actually changing once in a while would go a long way towards eliminating the most common failure modes. On Tue, Jun 19, 2012 at 6:58 PM, d...@deadhat.com wrote: ... Actually having a perfect source is a problem. It's much easier to test for a source with known defects that meet a well defined statistical model. is there any literature on the typical failure modes of TRNG/entropy sources in deployed systems? my understanding is that they tend to fail catastrophically, in a way easily detected by FIPS sanity checks. E.g. clearly broken. is it exceedingly rare for subtle / increasing bias to occur due to hardware failure or misuse in most designs? are there designs which fail hard rather than fail silent when error is encountered? If an entropy source in a closed system is producing an apparently non repeating, unbiased sequence and its output is deterministic (or low entropy) then there must be internal memory in the entropy source that is enabling the non repeating behavior. The more memory, the longer you have to watch before you can identify repeating behavior. So make your entropy source have a very small amount of memory and be sufficiently simple that you can model it mathematically. Then you can show all the SPOF and DPOF failure modes and show that your health check circuitry catches them. You can also show your health check circuitry catches all repeating patterns up and beyond some size that is determined by the internal memory of the ES. So the answer is yes.. Minimal memory (E.G. fewer registers) = Fails hard. Lots of memory (E.G. lots of registers, like an LFSR) = opportunity to fail soft. I can't point to literature. I think it's obvious. Without memory, non repeating behavior has to come from non determinism. Perhaps I should write a paper :) Mistrust an ES with many flops. I don't approve of FIPS sanity checks. These are algorithms you can't specify independent of the generation process. Or in other words, you can't test for randomness, you can only test for functionality. You need to use other arguments to show that what you have is random. FIPS sanity checks are a chore to implement after you've implemented a real health test algorithm matched to the failure modes of the source. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On Tue, Jun 19, 2012 at 2:30 AM, coderman coder...@gmail.com wrote: ... as for stating that it should never run dry, or fail to not return bits as long as the instruction is working... i was incorrect; developers should expect this instruction to infrequently encounter transitory failures requiring retry: The RDRAND instruction returns with the carry flag set (CF = 1) to indicate valid data is returned. It is recommended that software using the RDRAND instruction to get random numbers retry for a limited number of iterations while RDRAND returns CF=0 and complete when valid data is returned... This will deal with transitory underflows. A retry limit should be employed to prevent a hard failure in the RNG (expected to be extremely rare) leading to a busy loop in software. in Intel Advanced Vector Extensions Programming Reference at http://software.intel.com/file/36945 i would be very curious to know what the distribution of these single or consecutive failures (CF=0) look like on a busy system or long run benchmark, and particularly if/how environmental factors* affect failure rates. *CPU temperature, voltage regulation, what else? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
