Re: MC Frontalot sings about encryption
On Sep 14, 2007, at 8:36 PM, Perry E. Metzger wrote: Secrets From The Future, MC Frontalot's song about crypto Lyrics: http://frontalot.com/index.php/?page=lyricslyricid=41 -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
iPods using cryptographic hash so they only work with iTunes?
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 -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
Leichter, Jerry wrote: First off, it depends on how the thing is implemented. Since the entire drive is apparently encrypted, and you have to enter a password just to boot from it, some of the support is in an extended BIOS or some very early boot code, which is below any OS you might actually have on the disk. If I had to guess, I would suggest they were using the ATA secure hd password api, and really providing security rather than the firmware-lock usually associated with such passwords. That would allow you to retrofit it to a lot of laptops which already use that functionality, in a plug-and-play manner. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: using SRAM state as a source of randomness
Aloha! Udhay Shankar N skrev: 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 IMHO a very interesting paper. But I have a few questions about practical aspects of this (and the paper). First off I don't see any info in the paper about the time between power cycling and reading the memory. Shouldn't the RNG generated by the memory be affected by remanence problems if the power cycle is to short? I.e if the power off state is to short, the bit pattern from one read operation will contain more of the bit pattern from previous power on states. (2) How would one go about extracting the fingerprint/ID? As I see it you would either have to do numerous read operations (with power cycling in between) and then extract the fixed bits on a host. That is, the host reads the whole memory (just like in the paper) and from that extract the ID. This means that the RFID-unit will not know it's own ID. The other way to do it (as I see it), is to do the multiple reads during manufacturing (post production test/configuration), extract the fixed bits and then stor the index to these bits within the RFID chip. This would allow the RFID to assemble the bits and know it's own ID, but then the idea (as presented in the paper) to not have to do post manufacturing work to set the ID is gone. (3) in the opposite situation to (2), how should the RFID unit avoid the fixed bits when generating a key based on the random bits? Would it be ok to simply run the power on memory state through a cryptographic hash function, ignoring the fixed bits? -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. Kryptoblog - IT-säkerhet på svenska http://www.strombergson.com/kryptoblog - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]