Re: [Cryptography] [cryptography] RSA equivalent key length/strength
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Lucky Green wrote: Moti Young and others wrote a book back in the 90's (or perhaps) 80's, that detailed the strength of various RSA key lengths over time. I am too lazy to look up the reference or locate the book on my bookshelf. Moti: help me out here? :-) Can't help out with that. But I think that the ECRYPY Yearly Reports on keylengths and algorithms are a great source for these kinds of questions. The latest (from 2012) can be found here: http://www.ecrypt.eu.org/documents/D.SPA.20.pdf Unfortunately ECRYPY II has come to an end and I'm not certain the report will be updated anymore. Would be a loss since having updated estimates on keys and what algorithms to use is really helpful (IMHO). - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlI6onIACgkQZoPr8HT30QGuSgCgq31OzxzE5u931sIpY/XMs5Ry dwAAniAkW7jGfLnakNqGnjhhm37vfELm =Iqvv -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] real random numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! John Denker wrote: On 09/15/2013 03:49 AM, Kent Borg wrote: When Bruce Schneier last put his hand to designing an RNG he concluded that estimating entropy is doomed. I don't think he would object to some coarse order-of-magnitude confirmation that there is entropy coming in, but I think trying to meter entropy-in against entropy-out will either leave you starved or fooled. That's just completely backwards. In the world I live in, people get fooled because they /didn't/ do the analysis, not because they did. I very much doubt that Bruce concluded that accounting is doomed. If he did, it would mark a dramatic step backwards from his work on the commendable and influential Yarrow PRNG: J. Kelsey, B. Schneier, and N. Ferguson (1999) http://www.schneier.com/paper-yarrow.pdf What Kent is probably referring to is the Fortuna RNG which is a successor to Yarrow. One difference between Yarrow and Fortuna is the lack of the estimator in Fortuna. As Bruce and Ferguson states in chapter 10.3 of Practical Cryptography (where Fortuna is described in good detail) [1]: Fortuna solves the problem of having to define entropy estimators by getting rid of them. [1] https://www.schneier.com/book-practical.html - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlI29rMACgkQZoPr8HT30QEqRwCfb4+6/K6AtK04cvtFU4KCVGwB VA8AoKWhC8lOsru/xIkac71My0jIzjI9 =fx8M -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Seed values for NIST curves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Tony Arcieri wrote: The question is... suitable for what? djb argues it could be used to find a particularly weak curve, depending on what your goals are: http://i.imgur.com/o6Y19uL.png So, the question is then - how do we fix this? I (naively) see two approaches: 1. We as a community create a list of curves that we agree on are good. The list is placed in a document, for example an RFC that clearly states what criteria has been used, what the sources for the curves are and how they has been generated. This allows any user to check the validity and the provenance. 2. Create tools to easily create randomly generated curves including some tool to assess the goodness/quality. Either method should (I believe) be possisble to be integrated into TLS as part of the parameter exchange and negotiation. If I understand DJB correctly EC as such is sound and provides clear benefits compared to RSA. We just need curves that have completely open, traceable and varifiable specifications. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIu9iIACgkQZoPr8HT30QHziQCeLg8PgNPa2Iz0eB+ZJdgF6caB h1MAoJB/WTs+KrFsG3QjO84PipmyXlY0 =SdNy -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers (was Re: FIPS, NIST and ITAR questions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Stephan Neuhaus wrote: On 2013-09-04 16:37, Perry E. Metzger wrote: Phil Karn described a construction for turning any hash function into the core of a Feistel cipher in 1991. So far as I can tell, such ciphers are actually quite secure, though impractically slow. Pointers to his original sci.crypt posting would be appreciated, I wasn't able to find it with a quick search. I remember having reviewed a construction by Peter Gutmann, called a Message Digest Cipher, at around that time, which also turned a hash function into a cipher. I do remember that at that time I thought it was quite secure, but I was just a little puppy then. Schneier reviews this construction in Applied Cryptography and can't find fault with it, but doesn't like it on principle (using the hash function for something for which it is not intended). Isn't this whole discussion basically the gist of DJB vs USA? https://en.wikipedia.org/wiki/Snuffle And today we have Salsa20 as a PRNG/stream cipher in eSTREAM. The Salsa family of functions including ChaCha are compression functions in counter mode to generate a keystream. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIoUmoACgkQZoPr8HT30QF6BwCgrbIFVv/ETFWjGGUxi27h6bWb 7usAoKNYs9PO1ENGD8jeSje3i6Hm+xml =8rT0 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Jerry Leichter wrote: On Sep 1, 2013, at 2:11 PM, Perry E. Metzger wrote: On Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter leich...@lrw.com wrote: Meanwhile, just what evidence do we really have that AES is secure? The fact that the USG likes using it, too. We know they *say in public* that it's acceptable. But do we know what they *actually use*? That's also evidence for eliptic curve techniques btw. Same problem. (Slightly tangential but on topic I hope) Am I the only surprised that the NSA designed block ciphers SIMON and SPECK is vulnerable to differential attacks? http://eprint.iacr.org/2013/543 If I understand the history correctly NSA supported the development of DES as well as SHA-0/SHA-1 and their contributions shows knowledge about differential attacks at least as far back as 1977. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIoTj4ACgkQZoPr8HT30QH91gCg4aRb6tf1d6a5mOnBrF0/GP6c NwIAnRuB99lNpz04/WG0trIQU9ZKnW9A =4r0M -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Attempts at finding a new TCP sequence generator for uIP
Aloha! uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.) Unfortunately, the TCP sequence number generator in uIP is a bit simplistic - basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator. What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices). We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list. As we see it, the two main problems to solve are: (1) Find a secure PRNG algorithm that have as low implementation complexity as possible. (2) Add as little system/application requirements on entropy source and persistent storage as possible. Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective? But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG. The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate? A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased. The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?) The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No? This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP. Any thoughts, comments, suggestions and pointers would be very greatly appreciated. Thank you! Joachim Str�mbergson References -- [1] A. Dunkels. uIP TCP/IP stack. http://www.sics.se/~adam/uip/index.php/Main_Page [1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf [3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random Number Generator for Wireless Sensors Network Nodes http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf [4] R. M. Needham, D. J. Wheeler. Tea extensions. http://www.cix.co.uk/~klockstone/xtea.pdf [5] Wikipedia. Fortuna PRNG. http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29 -- 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 majord...@metzdowd.com
Re: SHA-3 Round 1: Buffer Overflows
Aloha! Ian G wrote: However I think it is not really efficient at this stage to insist on secure programming for submission implementations. For the simple reason that there are 42 submissions, and 41 of those will be thrown away, more or less. There isn't much point in making the 41 secure; better off to save the energy until the one is found. Then concentrate the energy, no? I would like to humbly disagree. In case of MD6 the fix meant that a bugger had to be doubled in size (according to the Fortify blog). This means that the memory footprint and thus its applicability for embedded platforms was (somewhat) effected. That is, secure implementations might have different requirements than what mighty have been stated, and we want to select an algorithm based on the requirements for a secure implementation, right? -- 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 majord...@metzdowd.com
Re: CPRNGs are still an issue.
Aloha! Damien Miller wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. That is a very good observation. I would bet loads of GM stocks that very few people realise that moving from 0ld sk00l HDD to SSD would affect their entropy sources. Does anybode have any idea if this has been discussed among OS Dev groups? One could probably do a similar comparison to the increasingly popular idea of building virtual LANs to connect your virtualized server running on the same physical host. Ethernet frame reception time variance as well as other real physical events should take a hit when moving into the virtualization domain. After all, replacing physical stuff with SW is the whole point of virtualization. Does anybody know what VMware, Parallels etc do to support entropy for sources like this, or is it basically a forgotten/skipped/ignored feature? -- 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 majord...@metzdowd.com
Re: 307 digit number factored
Aloha! Nate Lawson skrev: Some EC primitives in the latest OpenSSL. Because various standard forms of EC were never covered by patents. This has been rehashed many times, for example: http://www.xml-dev.com/pipermail/fde/2007-July/000450.html IANAL but IMHO this is only partially true. Try doing an efficient implementation in HW of ECC and not stepping on Certicom patent toes. SW implementations are probably ok though. -- 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]
Re: using SRAM state as a source of randomness
Aloha! Leichter, Jerry skrev: So presumably the model is: Put each manufactured chip into a testing device that repeatedly power cycles it and reads all of memory. By simply comparing values on multiple cycles, it assigns locations to Class 1 or 2 (or 3, if you like). Once you've done this enough to have reasonable confidence in your assignments, you pick a bunch of Class 1 locations and use them for the id; and a bunch of Class 2 locations and call them the entropy source. You burn the chosen locations into ROM on the chip. At power up, the chip checks the ROM, and constructs an ID from the list of Class 1 locations and a random value from the list of Class 2 locations. (Obviously, you want to be a bit more clever - e.g., if all your Class 1 locations hold the same value on every power up, something is wrong with your assumptions and you reject the chip rather than using an ID of all 0's or all 1's. The paper is asserting that this won't happen often enough to matter.) Yes, that is one way to do it - but its not the way they do it in the paper. Doing it your way, that is writing the bit locations for the ID and RNG sources into an index mem on chip, goes against the purpose of the presented scheme. As they write in the paper: quote The non-volatile approach involves programming an identity into a tag at the time of manufacture using EPROM, EEPROM, flash, fuse, or more exotic strategies. While non-volatile identities are static and fully reliable, they have drawbacks in terms of the process cost and the area cost of supporting circuitry. Even if only a small amount of non-volatile storage is used, the process cost must be paid across the entire chip area. /quote One could also argue that if you add the functionality (the non volatile storage) and take the post-production time (and cost) to write down the locations, you could just as well write down a normal ID. (You have the same conclusion futher down in your mail.) If you do it the way they do it in the paper - communicate the SRAM mem state to an extrnal source to have your ID extracted for you - doesn't that change the ID and authentication protocol? This is only done during manufacturing. Presumably it would be integrated into the testing process, which you're doing anyway. Nope, again the paper is (pretty) clear that the external reader receives the mem dump and then extracts the ID fingerprint using hamming distance to match the mem dump with a DB of known IDs. This also means that your Class 2 bits (the RNG sources) will be communicated, something that I see as a security problem. Finally. I have been in contact with the authors regarding their view on rememanence problemns and they simply wait long enough to allow remanence effects to be nullified. But as I see it the device have no way of knowing that long enough time have passed. And if it hasn't, communicating the SRAM state might lead to appication information leakage. Correct? The unique ID stuff is clever, but it's not clear how much it gains you: Since you need to do some final per-device programming anyway to identify the locations to be used for the ID, why not just burn in a unique ID? Exactly. The random generator is clever, but the question is whether produces an unpredictable result is really a stable characteristic of memory. As Peter Gutmann stated earlier in this thread: RAM state is entropy chicken soup, you may as well use it because it can't make things any worse, but I wouldn't trust it as the sole source of entropy. Device aging, changes is the manufacturing process, electrical and environmental changes (accidental or deliberately) will all affect the RNG, and there is no easy way for the (low cost) device to know how good or bad quality of the RNG is. -- 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]
Re: using SRAM state as a source of randomness
Aloha! Peter Gutmann skrev: So RAM state is entropy chicken soup, you may as well use it because it can't make things any worse, but I wouldn't trust it as the sole source of entropy. Ok, apart from the problems with reliable entropy generation. I'm I right when I get a bad feeling when I think about the implications of how the device ID is established. As I understand it, the device itself doesn't know it's ID. Instead you repeatedly send over mem dumps to the reader which then extracts what it (to some estimated degree) consider to be the correct ID. Wouldn't a simple thing like a challenge response and become much more complicated - and insecure? Basically the device goes from saying: I'm ID XYZ and to prove it by providing the following response to your challange, to I'm an amnesiac device and here are my mem dump, please calculate my ID (please remember to power-cycle me x times) and then I'll send a response. Also, wouldn't the ID-scheme presented in the paper take a very long time. Transferring 256 Bytes * x times + hamming calc (by the host) vs reading 64 bits (or similar ID length)? I give the paper plus marks for novelty, but can't see how to use this in a secure, practical and cost efficient way. -- 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]
Re: using SRAM state as a source of randomness
Aloha! Peter Gutmann skrev: The worst case is a change in the environment or manufacturing process, which typically occurs without the end user even knowing about it. You simply can't guarantee anything about RAM state as an RNG source, you'd have to prove a negative (no change in manufacturing technology or the environment will affect the quality of the source) in order to succeed. It's like the thread-timing- based RNGs, you can never prove that some current variation of or future change to the scheduler won't result in totally predictable random numbers. One could add test functionality that checks the randomness of the initial SRAM state after power on. But somehow I don't think a good test suite and extremely low cost devices (for example RFID chips) are very compatible concepts. -- 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]
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]
AMDs new instructions for parallelism and support för side-channel attacks?
Aloha! I just saw om EE Times that AMD will start to extend their x86 CPUs with instructions to support/help developers take advantage of the increasing (potential) parallelism in their processors. First out are two instructions that allows the developer to get info about instruction completion as well as cache misses. Considering the article by . about analysis of protection mechanism against cache based timing attacks for AES [1] one could assume that these instructions should be useful for writing side-channel resistant implementations But, do you think that the opppsite is also possible, that these instructions might be a possible source for information leackage and vector for side-channel attacks, at least local, inter process attacks? I get a weird goodie-badie feeling when reading about these instructions... [1] Johannes Blömer and Volker Krummel. Analysis of countermeasures against access driven cache attacks on AES http://eprint.iacr.org/2007/282.pdf -- 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]
Re: DESCHALL Classic Client Source Code Released
Aloha! Matt Curtin skrev: Hello everyone. It was at the RSA Conference ten years ago that the Secret Key Challenges were issued, including the original DES Challenge. Rocke Verser's DESCHALL project, of course, went on to win that contest. Source code for the project was covered by a ten-year non-disclosure agreement. Rocke has granted me permission to release the source code for the classic fast DES key search clients and I have done so. Additional server-side code, including the UDP-HTTP proxies (both sides) and the code for running the client distribution center, is also available. All of the goodies are at http://www.interhack.net/projects/deschall/. Very cool, but the webserver seems to be down. -- 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]
