(Whew, busy day today!)
As for status of the Crypto team. Not too much going on at the moment. I’m still the team leader but the group has been very quiet for some time. I haven’t had time to spend on it lately. At some point we started working on a better random generator that takes in multiple sources of input; Fortuna based on Schneier’s book. Never got around to finishing it. I think Chris’s Secure Random was also based on the same model and he did a version of Fortuna but never did the proper entropy gathering. It’s been a while so if I’m wrong please feel free to correct me.
Back in 2005-2006, I spent, like, 11 months working through that entire book [1] and creating a package (KryptOn) that implemented the most important chapters from that book as strictly as I could.
Fortuna, of course, was one of the starting points. I don't know if I used "proper" entropy gathering, but I'm satisified that it is reasonably _enough_ entropy for seeding Fortuna. Here's the method I use to generate an entropic string to seed a new Fortuna random generator:
unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time _ Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Good luck guessing each and every one of those correctly! Each time aBlock is valued with one of the slightly unguessable strings, it is progressively hashed after being bixXor'd against the *prior* hashed value before being appended as a ByteArray to a stream of bytes, until, finally, the total ByteArray is then hashed via SHA256. That hash value is finally used as the seed for the new Fortuna instance. The gory details below [2].
There just ain't no way any hacker could/would try to guess that seed. And I didn't even need to use Sound input. But, as you can see, it depends on quite a few other things..
So, it takes a long time to run (~ 500 ms) which is why the global #picker is initialized just once and can be used indefinitely for that image session.
[1] -- http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/re...
[2] -- generateKey | unguessableBytes prior | prior _ UUID new shuffled asInteger. unguessableBytes _ ByteArray streamContents: [ : stream | self unpredictableStringsDo: [ : each | | current | current _ each size < 30 ifTrue: [ "Some of the inputs are pretty short, expand them a little, and take opportunity to inject some extra craziness." (each asByteArray asInteger raisedTo: 64 modulo: 6773186437430423149 "prime") asByteArray ] ifFalse: [ each ]. "make each value dependent on the prior values, so the adversary is required to get every single string exactly right AND guess every the randomizations correctly." current _ SHA1 new hashMessage: (current bitXor: prior). stream nextPutAll: current asByteArray. prior _ current ] ]. ^ SHA256 new hashMessage: unguessableBytes
There is a plugin implementation available on the croquet plugin. See gatherEntropy: which was done by Andreas. It uses platform specific implementations so it’s a pretty good choice.
We really should finish this work since any real attack on security starts with bad random number generators. (Well actually an attack at the endpoint is more likely but that’s a different email).
All the best,
Ron Teitelbaum
Head Of Engineering
3d Immersive Collaboration Consulting
ron@3dicc.com
Follow Me On Twitter: @RonTeitelbaum
www.3dicc.com
3d ICC on G+
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nicolas Cellier Sent: Tuesday, November 19, 2013 4:43 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Crypto support?
Sure that makes sense. Historically there were no such service in the System. I wanted to remind that crypto has to care that randomness comes from sufficiently random source, not just a random random source.
If the contract is explicit enough (Smalltalk cryptoLevelRandom?), then it can move to the System.
But would it serve other purpose than crypto?
I would rather implement a CryptoRandom class part of Crypto package, either via plugin or FFI to wrap over /dev/random or equivalent...
2013/11/19 Frank Shearar frank.shearar@gmail.com
That's why I used the phrase "better encapsulated" :) I don't care particularly _where_ the randomness comes from (and on a Unix machine, /dev/random or /dev/urandom (I can't remember which) is the proper place). I just really, really don't want a Crypto package depending on a Sound package. So if System supplied a hook that declared "get your randomness here", and the base image _happened_ to connect that to one's mic, that would be OK. But the direct dependency is bonkers.
frank
On 19 November 2013 21:27, Nicolas Cellier
nicolas.cellier.aka.nice@gmail.com wrote:
It's because crypto must not rely on pseudo random generated numbers, they are considered too easy to crack. I guess that sound input was seen as a universal way to get some hardware noise... Nowadays, shouldn't it be something like /dev/random?
2013/11/19 Frank Shearar frank.shearar@gmail.com
Does anyone know the current state of play of the crypto team?
We have a DSA implementation in "System-Digital Signatures" that should belong in a package called "Crypto-Something", but if the other stuff was better I'd rather delete this and use the proper stuff.
Also, we need a better encapsulated source of randomness than "SoundService default randomBitsFromSoundInput: 512" because crypto shouldn't depend on a sound package. I don't care if something _plugs that in_, but the direct reference is suboptimal.
frank
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography