Re: [cryptography] NIST Randomness Beacon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! d...@geer.org wrote: After all that discussion of the randomness beacon, it belatedly occurs to me to ask if anyone has ever applied, even for fun, any of the various tests for randomness to the transmissions from the various shortwave numbers stations. http://en.wikipedia.org/wiki/Numbers_station Or the NIST Randomness Beacon. Anybody tested it with Dieharder yet - or is it too much of a dead duck anyway to not waste time on it. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlK1l30ACgkQZoPr8HT30QHoOgCeLPtEPpbaPivTR/MPRHx2Mne9 PhkAoNyJenWGKkY69c4QjA9iWGPYCJSe =5iXZ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Mixing RdRand with other CPU-based entropy sources?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Here is a question: If we (barely) trust RdRand enough to use it as an entropy source in combination with another source to feed our RNG - would it be wise to use another CPU-based entropy source such ad Haveged [1], DakaRand [2], Jytter [3] or the CPU Jitter Random Number Generator [3] by Stephan Müller? Or should the second one alway be a CPU-external source? A tengential question - is running these entropy sources ([1]..[2]) in parallel a good idea? [1] http://www.issihosts.com/haveged/ [2] http://dankaminsky.com/2012/08/15/dakarand/ [3] http://jytter.blogspot.se/ [4] http://www.chronox.de/ - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKyq/cACgkQZoPr8HT30QGALACeJhV2LbPEpMHQQl0GteZEVNmq kVYAn3YGrGKTgUgzUSlB8exFvbCMJDI3 =qTBy -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] State of the art in block ciphers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! (Added the list as recipient since I assume not replying to list was a mistake - if not I apologize to SandyH.) Sandy Harris wrote: Joachim Strömbergson joac...@strombergson.com wrote: The question is then - what is state of the art in block cipher design? What would be the candidates to complement AES in SSL/TLS? The other finalist from the AES competition -- Twofish, MARS, RC6 and Serpent would be obvious possibilities. All except RC6 have open licenses, I think. Various conutries also have newer standards for ciphers that can replace AES. Camellia in Japan, Aria in Korea, mybe others? So, the state of the art 2013 for block ciphers are the other AES finalists and some older national ciphers such as Camellia, SEED? Is that really the case? I'm not saying they aren't interesting or good - but wonder if there really hasn't been any progress. The good thing with older algorithms is that they have been around and hopefully been tested more. Some of them such as Camellia has been through evaluations such as CRYPTREC. And both Canellia and SEED are in OpenSSL and/or has been accepted as ciphers in SSL/TLS. But are they used - outside their national relation? Camellia is not as fast as AES, and like AES contain S-boxes which I assume would today be harder to motivate to use due to possible side channel effects. SEED is probably slower for similar length key than AES too. And has S-boxes. I would assume that since the end of the AES competition and NIST standardizing the algorithm we would have learned a lot of how to construct, good, really fast block ciphers. eSTREAM and SHA-3 competitions shows that we today can develop algorithms that are really fast and can provide protection against attacks we (imho) didn't know as much about when AES was designed. Things like ARX-constructions, HAIFA and sponges that move away from Feistel like constructions. For something to successfully complement AES as block cipher in SSL/TLS I believe it needs to provide at least the same performance (able to utilize things like AES-NI on modern CPUs), protect against side channel attacks and be a pretty good drop in substitute. (Possibly working on larger block size though...) Flame on! - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKdrtoACgkQZoPr8HT30QHv/ACfehs+RxsvX/esPCePthntjZBE K5YAn1Wnd3wvtWVdGHD6rtyA2yD6834D =WH2x -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Stephan Mueller wrote: I am doing a lot of research in this area these days. If you imply that main storage means RAM outside the caches, I think your statement is not entirely correct. Yes, main store is RAM. From the first rounds of testing, I think I see the following: [...] What CPU is this? From your description it sounds to me like a x86, modern high performance CPU with instructions that has different cycle times and multiple levels of caches. On these types of CPUs, yes you don't need to hit main memory to get execution time variance. What I was trying to say is that Havege running on MCUs (AVR, AVR32, PIC, PIC32, ARM Cortex M0 etc) where instructions in general takes the same number of cycles to execute and where caches are few (few levels), have simple or even no replacement policy (it is done by SW control), the assumptions in Havege is not really present. And that this change in physical setup _should_ affect the variance measured. But again, I haven't tested it yet. - disabling the caches completely introduces massive variations That is interesting. For a sequence of the same type of instructions? == My current hunch is that the differences in the clock speeds that drive the CPU versus the clock speed driving the memory locations that you access (either for instruction or data fetches) are the key driver of variations. It's more of a clock descynchronization effect? I do not concur here, because even IF the VM host does some RDTSC emulation, the emulation code is subject to the fundamental jitter problem outlined above. Hence, I do not think that the jitter can be eliminated by virtualization. I would say that Intel, Wind River would have a different opinion. It is in fact one of the things you can control. You can lock the RDTSC to provide all kinds of sequences in related to the CPU or clock or otherwise. This is actually what is being used to protect against timing side channel attacks between VMs, processes. [1] http://www.chronox.de Very cool. How does [1] compare functionally to jytter? http://jytter.blogspot.se/ Side note, on [1] you state that it is a non-physical true random number generator. I would say that it is a physical RNG. It measures physical events. But it does not measure events _outside_ the CPU. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKYauUACgkQZoPr8HT30QFPwgCg3g4d/e/yUponwmstNu4v9Uor WtUAnRfKTjmorkvfwSsvvX+o/CO9apNq =HkI7 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Stephan Mueller wrote: The problem is that dieharder Co only show the statistical quality. Based on my real-world attempts to the CPU jitter issue used as a noise source for /dev/random, the questions around the entropy of the data still remains -- see the email threat on LKML. (I feel I need to read up on the LKLM discussion). Yes, but when having access to an entropy source - what other ways besides statistical tool such as Dieharder do we have to measure the quality of the entropy? The problem as I have understood it is that we don't have direct access to the entropy source in Bull Mountain. And that we have to trust Intel on telling us the truth, that there actually is a nice entropy source, not simply a CSPRNG with a seed known by certain organizations. The lack of openness, transparency and control of the entropy source is what is missing. Or am I missing something? That is why my current patch set only uses the jitter noise source as last resort, i.e. when /dev/random is about to block. As long as the other noise sources produce entropy, my jitter noise source is not even asked. With that approach, however, /dev/random will never block any more on any system. That is actually pretty neat. What bitrate do you get from your RNG? BTW: Just downloaded your PDF and OMG it is really big. I think I have my weekend reading identified. ;-) BTW2: You should probably reference jytter in your paper, it would be very interesting to see the comparison between them. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKYbRUACgkQZoPr8HT30QE/uQCgv7vMQpp7c0JH7hEY7dUnjaPz aBcAoL/bMoWcdcogp1tCBCfnVjUXvUGq =1Om6 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] State of the art in block ciphers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Just realized that AES is more than 10 years, and has been an amazing success. But at the same time, looking at SSL/TLS, the number of widely deployd symmetric ciphers is decreasing. RC4 will probably be deprecated in the near future leaving us with basically AES, 3DES. Getting a new stream cipher (like Salsa20, ChaCha) into SSL/TLS has been met with some resistance with arguments that we don't need it since we have good stream cipher modes like GCM that provides good performance as well as authentication after encryption. And yes, that is true. But the cipher agility is reduced. We might end up with only AES as the widely deployd cipher. I'm not convinced that is a good development. So, my thinking is that what can we do to as easily as possible complement (not replace) AES with that can be dropped in into similar suites such as TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (RFC2588)? A block cipher that provides at least as good performance and security but is based on different mechanisms to protect from possible future weaknesses easily affecting both AES and the other cipher. Sound good, bad, dumb? The question is then - what is state of the art in block cipher design? What would be the candidates to complement AES in SSL/TLS? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKYcTAACgkQZoPr8HT30QHMvgCeKdBzjlb91ndWvMf2tzTcSmNk VGYAoK8RjzTIpFZhG4oSPXf2qYguBPwg =aOw0 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! coderman wrote: On Tue, Nov 26, 2013 at 10:09 AM, Joachim Strömbergson joac...@strombergson.com wrote: ... I have concerns though on embedded SSL stacks that use Havege as entropy source on MCUs such as AVR32 and ARM. ... On an x86-based server you can use Havege, but use it to feed /dev/random, not as a RNG directly. The same goes for Jytter. good points! haveged should work fine on StrongArm, A8, A9, Xscale, anything with a high res timer like ARM Cycle Counter (in place of TSC). older ARM processors and x86 without high res TSC (pre-pentium?) will have trouble. Note that Havege is based on the assumption that instruction execution time varies and can be forced to vary as much as possible. On single-issue, RISC architectures with no or simple (such as SW controlled) cache memories you basically will have to hit main store in order to get a lot of variance. Then you also need a cycle timer, high res timer to be able to measure the variance. Another thing to note is that RDTSC is one of the instructions that VM-systems can (and will) simulate. This means that the source for Havege entropy will be synthetic and arbitrary from physical event. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKXBlIACgkQZoPr8HT30QEqcwCfS1Ux5rhm5QBHbnqr2gThKoTy x7AAoIw4AKhWBNLUMJSEDlD0KHsLjxC+ =Vm3Q -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Quality of HAVEGE algorithm for entropy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Stephan Mueller wrote: The only challenge that I see with Havege is that the algorithm is quite complex and that the description does not fully explain why and where the entropy comes from. Looking into the source code of oneiteration.h, the code is also not fully clear. Havege is (if I remember correctly) a magnificent example of Duff's Device: https://en.wikipedia.org/wiki/Duff's_device The code tries to force instruction cache misses at different points on the switch-loop thereby causing a lot of pipe flushes and instruction loads from lower level caches all the way to main store. A goof comparison to Havege is Jytter that basically (AFAIK) is trying to get entropy from the same source (measuring variance in instruction timing). But Havege tries to force the creation of variance and can thus generate higher rate of entropy. In my measurements I get kbps from Jytter byt Mbps from Havege. I have yet to compare the quality as measured using Dieharder, but from my memory Havege was really good. Considering the grilling I get with a similar RNG that I ask to be used as a seed source for /dev/random or other crypto libs (see thread http://lkml.org/lkml/2013/10/11/582), I would have concerns on the algorithm. As long as one does not rely on one source - and _always_ feed the entropy to the RNG-CSPRNG chain (not replace the chain and connect the source directly to /dev/random output like with Bull Mountain) I have a hard time to see where much controversy would emerge. As long as the source produces ok quality entropy. One issue I'm thinking of is if you have more than one source, but one of them dwafs the other sources in kapacity. Say having a microphone providing whitish noise at kbps rate and then having RdRand from your Haswell CPU generating data at Gbps speed, will the microphone entropy matter? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKXCPMACgkQZoPr8HT30QHYugCgrtEwLV33ZS20PSvb/kvR8Fuq RgEAn1obSaBl/7V/IUqFMBk49bSeU1I/ =VCJ1 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
Aloha! CodesInChaos wrote: My argument concerning performance is that for long messages SipHash isn't actually significantly faster than (possibly round reduced) MD5, Skein, Blake2 etc. Do you have any pointers to benchmarks that show this? The SipHash paper shows significant performance gains compared to MD5 for long messages. Besides that the fact that you _never_ shall use MD5 for new designs and unless forced to. A reduced round even less so. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] FreeBSD crypto and security meta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! coderman wrote: FreeBSD's CSPRNG also allowed for certain stochastic sources, deemed to be high-quality, to directly supply the random(4) device without going through Yarrow. With recent revelations over possible government surveillance and involvement in the selection of these high-quality sources, it is felt that they can no longer be trusted, and must therefore also be processed though Yarrow. This is imho a really good move. No entropy should go straight from collection to application, but always feed a good CSPRNG. But we also need to be able to (securely) sample the entropy source as well as (securely) inject test data into the CSPRNG. Both of these to be able to observe and test the combined entrpoy+CSPRNG chain. Future work is now going ahead with the implementation of the Fortuna algorithm by Ferguson and Schneier as an upgrade or alternative to Yarrow. Initially a choice will be presented, and decisions on the future of the CSPRNG processing algorithms in use will be made in the future as needs arise. Nice! FreeBSD ftw. ;-) - -- 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/ iEYEARECAAYFAlJmLQMACgkQZoPr8HT30QHTGwCdFlIDwh6he8QBKZB9RGLk8J6X 7ToAn3X2Mc+efSjHoaQPbxJBMIr1+m+T =5f0H -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Eugen Leitl wrote: The reason is purely for dedup and pretty much nothing else. As such, we only need a hash with a good pseudo-random output distribution and collision resistance. We don't specifically need it to be super-secure. The salted hashing support I added was simply to silence the endless stream of wild hypotheticals on security. If that is all you want, have you considered SipHash? It is much faster than the other algorithms, yet more secure than CityHash, Murmurhash and friends. And it provides an IV/salt to make it per instance unique. https://131002.net/siphash/ Designed by DJB and Aumasson, the latter the designer of BLAKE and BLAKE2 which you referred. (Sorry to butt in and if I might have suggested something you already know.) - -- 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/ iEYEARECAAYFAlJk1jsACgkQZoPr8HT30QG3CwCgzh4wjtVibnVTAsocqtGpkig/ yQsAoMtZujs8AH7v5SawXWl/06ahlfSb =2Ps4 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Sodium. (Was: Re: NaCl Documentation?)
Aloha! On 2013-03-11 12:22 , Jeffrey Walton wrote: Hi All, Is anyone aware of documentation for NaCl? There does not appears to be a README or INSTALL at the moment, and Google is not being very helpful: https://www.google.com/#q=nacl+library+documentation+site:nacl.cr.yp.to. There also does not appear to be a mailing list: https://www.google.com/#q=nacl+library+mailing+list+site:nacl.cr.yp.to. A newbie question (if you have experience with the library): how does one (1) specify a compiler; and (2) execute the self tests. Executing `$ CC=gcc; ./do` appears to have hung. (The `do` script has some `echo` statements, but I have not gotten any output). There is a new implementation of NaCl by Frand Denis called Sodium that tries to be more portable and user friendly. There are wrappers for Python and Ruby, several prepackaged versions for different systems etc. I had no problem building it with clang+llvm om OSX. (I do however have problems actually using the lib, but right now I attest that to problems behind the keyboard.) Sodium uses std configure style build process and comes with a comprehensive test system. See more here: http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/ https://github.com/jedisct1/libsodium -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
Aloha! On 2012-06-20 05:32 , James A. Donald wrote: 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. Good point. And even more so. What I think we would like to have is: (1) Read access to the raw output of the entropy source. (2) Possibly read access after whitening. (3) Write access to inputs of the PRNG This would allow us to probe that the whole chain works as intended with KATs for the PRNG part. This would still not prove that Intel, when MUXing in data from (1)/(2) into the PRNG actually does something completely different. -- 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] 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
