Hi Frank,
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.
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
mailto:ron@3dicc.com ron@3dicc.com
Follow Me On Twitter: https://twitter.com/RonTeitelbaum @RonTeitelbaum
http://www.3dicc.com/ www.3dicc.com
https://plus.google.com/u/0/b/108936249366287171125/108936249366287171125/p osts 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
(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
Hi Chris,
I thought I remembered you doing something like that. Did you post that code to Cryptography or just to KryptOn? Didn't you do the version on Cryptography? Sure looks to me like the current version is using the sound system.
Thanks!
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Chris Muller Sent: Friday, November 22, 2013 4:04 PM To: Cryptography Team Development List Cc: The general-purpose Squeak developers list Subject: Re: [Cryptography Team] RE: [squeak-dev] Crypto support?
(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/ref=sr_1_1?ie=UTF8&qid=1385152889&sr=8- 1&keywords=schneier+practical+cryptography
[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/cryptograph y
I don't know. The state of Cryptography never really recovered from when the team went through a kind of self-destruct sequence. Do you remember? At first we had just one package, "Cryptography" and we were advancing. Then there was this big push from a few members in the team to "packagify" it into a bunch of tiny little packages (I don't remember why).
Unfortunately the dependencies didn't match the semantic boundaries and we had endless discussions about what class should belong in what package, renaming packages to accomodate their different scope, etc.
Meanwhile, "customers" of Cryptography were having trouble understanding the latest "state" of it and also loading it of course, until, after several months, the team back-tracked and went back to the single package, even though there was still some disagreement, I think, and the "team" sort of fizzled out.
I don't remember it too clearly -- It's all in the archives.
The end result was I sort of threw up my hands and used my own version of Cryptography. I would like to get back to one good, quality version, though.
On Fri, Nov 22, 2013 at 9:10 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi Chris,
I thought I remembered you doing something like that. Did you post that code to Cryptography or just to KryptOn? Didn't you do the version on Cryptography? Sure looks to me like the current version is using the sound system.
Thanks!
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Chris Muller Sent: Friday, November 22, 2013 4:04 PM To: Cryptography Team Development List Cc: The general-purpose Squeak developers list Subject: Re: [Cryptography Team] RE: [squeak-dev] Crypto support?
(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 asByteArrayGood 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/ref=sr_1_1?ie=UTF8&qid=1385152889&sr=8- 1&keywords=schneier+practical+cryptography
[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/cryptograph y
Hi Chris,
Yeah I kind of remember that. The concern was that there was some pieces of cryptography that were not necessary if someone, for example,e just wanted a hash or ssl or something of that sort. Not sure that the current state of packages is all that bad. Suggestions?
Ron
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Chris Muller Sent: Saturday, November 23, 2013 2:28 PM To: Ron Teitelbaum Cc: Cryptography Team Development List; The general-purpose Squeak developers list Subject: Re: [Cryptography Team] RE: [squeak-dev] Crypto support?
I don't know. The state of Cryptography never really recovered from when the team went through a kind of self-destruct sequence. Do you remember? At first we had just one package, "Cryptography" and we were advancing. Then there was this big push from a few members in the team to "packagify" it into a bunch of tiny little packages (I don't remember why).
Unfortunately the dependencies didn't match the semantic boundaries and we had endless discussions about what class should belong in what package, renaming packages to accomodate their different scope, etc.
Meanwhile, "customers" of Cryptography were having trouble understanding the latest "state" of it and also loading it of course, until, after several months, the team back-tracked and went back to the single package, even though there was still some disagreement, I think, and the "team" sort of fizzled out.
I don't remember it too clearly -- It's all in the archives.
The end result was I sort of threw up my hands and used my own version of Cryptography. I would like to get back to one good, quality version, though.
On Fri, Nov 22, 2013 at 9:10 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi Chris,
I thought I remembered you doing something like that. Did you post that code to Cryptography or just to KryptOn? Didn't you do the version on Cryptography? Sure looks to me like the current version is using the sound system.
Thanks!
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Chris Muller Sent: Friday, November 22, 2013 4:04 PM To: Cryptography Team Development List Cc: The general-purpose Squeak developers list Subject: Re: [Cryptography Team] RE: [squeak-dev] Crypto support?
(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 asByteArrayGood 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/ref=sr_1_1?ie=UTF8&qid=1385152889&sr=8- 1&keywords=schneier+practical+cryptography
[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/cryptograph y
cryptography@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Ron Teitelbaum