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