[Cryptography Team] RE: [squeak-dev] Crypto support?

Ron Teitelbaum ron at usmedrec.com
Sat Nov 23 20:55:44 UTC 2013


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 at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at 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 at 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 at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at 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 at 3dicc.com
> >
> > Follow Me On Twitter: @RonTeitelbaum
> >
> > www.3dicc.com
> >
> > 3d ICC on G+
> >
> >
> >
> >
> >
> > From: squeak-dev-bounces at lists.squeakfoundation.org
> > [mailto:squeak-dev-bounces at 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 at 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 at 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 at 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 at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > y
> >
>



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131123/f6f4a3c0/attachment.htm


More information about the Squeak-dev mailing list