Hi:

Interesting discussion, I was away also....only doing limited stuff porting
somethings to Cuis.

The Blowfish from Paul (I need to adjust somethings yet, as Paul commented
in a private mail, thanks Paul!) and also System Hashing, but nothing more.

Other person of Cuis community ported Crypto Salt but I agree that we
should have an unified and consistent cryptography package for Squeak, Cuis
and Pharo.

What was the motivation of put all the stuff in SmalltalkHub (I was not
aware of the discussion when happened)?

Thanks.



2013/11/23 Ron Teitelbaum <ron at usmedrec.com>

> 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
> > >
> >
>
>
>
>
>
>


-- 
Saludos / Regards,
Germán Arduino
www.arduinosoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131124/3dfcf66a/attachment.htm