Re: using SRAM state as a source of randomness
Netsecurity wrote: > Back in the late 60's I was playing with audio and a > magazine I subscribed to had a circuit for creating > warble tones for standing wave and room resonance > testing. > > The relevance of this is that they were using a > "random" noise generating chip that they acknowledged > was not random enough for good measurements. The fix > suggested was to parallel a number, six as I recall, > to improve the randomness by mixing the signals to > achieve better randomness. I don't recall the math but > the approach improved the randomness by more than an > order of magnitude. If one such chip was so non random that the ear could hear the difference from white noise or pink noise, it is most unlikely that six together would be random enough for cryptographic purposes. As has often been stated on this list, the noise source must be understood, so that we have physical theory as to where the noise is coming from, and also tested to make sure it is functioning in accord with theory. No one really understands where zener diode noise is coming from. True entropy in equals true entropy out. You need to be able to determine the true entropy in from physical theory, and be able to test the hardware to check it is working in accordance with theory. To know that a true random number generator is cryptographically secure, you need knowledge of the underlying hardware, knowledge that shows it derives its randomness from the fundamental randomness of the universe, either thermal entropy, (Johnson noise) or quantum indeterminacy (shot noise), knowledge that enables us to determine the good functioning of the underlying noise amplification circuits from the character of the output. A good circuit would simply directly amplify the underlying noise source, so that the entropy of the output would be somewhat less than one entropy bit per signal bit, thus ensuring that any malfunction of the underlying circuit would be obvious, and then pass that output into a hash generator, which emits hash that outputs less bits than the true entropy. Using SRAM as a source of either randomness or unique device ID is fragile. It might well work, but one cannot know with any great confidence that it is going to work. It might work fine for every device for a year, and then next batch arrives, and it completely fails. Worse still, it might work fine on the test batch, and then on the production run fail in ways that are subtle and not immediately obvious. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
On Mon, 17 Sep 2007 11:20:32 -0700 Netsecurity <[EMAIL PROTECTED]> wrote: > Back in the late 60's I was playing with audio and a magazine I > subscribed to had a circut for creating warble tones for standing > wave and room resonance testing. > > The relevance of this is that they were using a "random" noise > generating chip that they acknowledged was not random enough for good > measurements. The fix suggested was to parallel a number, six as I > recall, to improve the randomness by mixing the signals to achieve > better randomness. I don't recall the math but the approach improved > the randomness by more than an order of magnitude. > > I have also seen the same effect on reverse biased zener diodes used > as random noise generators and that seemed - no real hard > measurements that I can recall - to work quite well. Mind you these > were not zeners all fabricated on a single chip, but rather > individuals soldered together so the charateristics of each were more > random because of the semi-randomness of the manufacturing process. > This is an old technique. We could even go back to von Neumann's scheme: look at two successive bits. If they're equal, discard them. Otherwise, map <0,1> to 0 and <1,0> to 1. See the section on "Software whitening" in http://en.wikipedia.org/wiki/Hardware_random_number_generator (which was correct as of when I looked at it, a few minutes before the timestamp on this email; check the Wiki history to be sure). --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
Back in the late 60's I was playing with audio and a magazine I subscribed
to had a circut for creating warble tones for standing wave and room
resonance testing.
The relevance of this is that they were using a "random" noise generating
chip that they acknowledged was not random enough for good measurements. The
fix suggested was to parallel a number, six as I recall, to improve the
randomness by mixing the signals to achieve better randomness. I don't
recall the math but the approach improved the randomness by more than an
order of magnitude.
I have also seen the same effect on reverse biased zener diodes used as
random noise generators and that seemed - no real hard measurements that I
can recall - to work quite well. Mind you these were not zeners all
fabricated on a single chip, but rather individuals soldered together so the
charateristics of each were more random because of the semi-randomness of
the manufacturing process.
Perhaps a similar approach could be used here.
Best,
Allen
- Original Message
From: Udhay Shankar N <[EMAIL PROTECTED]>
To: cryptography@metzdowd.com
Subject: using SRAM state as a source of randomness
Date: 09/12/07 11:03
>
> Sounds like an interesting idea - using SRAM state as a source of
> randomness. Any of the folks here willing to comment on this?
>
> Udhay
>
> http://prisms.cs.umass.edu/~kevinfu/papers/holcomb-FERNS-RFIDSec07.pdf
>
> Initial SRAM State as a Fingerprint and Source
> of True Random Numbers for RFID Tags
>
> Daniel E. Holcomb, Wayne P. Burleson, and Kevin Fu
> University of Massachusetts, Amherst MA 01002, USA,
> {dholcomb, [EMAIL PROTECTED], [EMAIL PROTECTED]
> http://www.rfid-cusp.org/
>
> Abstract.
>
> RFID applications create a need for low-cost security and
> privacy in potentially hostile environments. Our measurements show
> that initialization of SRAM produces a physical fingerprint. We propose
> a system of Fingerprint Extraction and Random Numbers in SRAM
> (FERNS) that harvests static identity and randomness from existing
> volatileCMOSstorage.Theidentityresultsfrommanufacture-timephys-
> icallyrandomdevicethresholdmismatch,andtherandomnumbersresult
> from run-time physically random noise. We use experimental data from
> virtual tags, microcontroller memory, and the WISP UHF RFID tag to
> validate the principles behind FERNS. We show that a 256byte SRAM
> can be used to identify circuits among a population of 160 virtual tags,
> and can potentially produce 128bit random numbers capable of passing
> cryptographic statistical tests.
>
>
> --
> ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com))
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>
Message sent using UebiMiau 2.7.10
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: iPods using cryptographic hash so they only work with iTunes?
"Perry E. Metzger" <[EMAIL PROTECTED]> writes: > It appears that Apple may have altered the firmware of newer iPods so > that they require a proper cryptographic hash in the iTunesDB loaded > onto the units or they won't work. This effectively blocks people from > using third party software with an iPod, including the various > programs people use on Linux with iPods. > > http://ipodminusitunes.blogspot.com/2007/09/apple-cuts-us-off.html And, within a few days, the open source folks have reverse engineered it. The presence of "magic numbers" in the algorithm makes one assume that this was intended as more than a simple hash integrity check, but the brief time required to find them leads one to believe the mechanism was not a very effective protection (though it isn't even clear what it was intended to protect against.) http://ipodminusitunes.blogspot.com/2007/09/weve-won.html Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
open source digital cash packages
Are there any open source digital cash packages available? I need one as part of another research project. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
