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(a)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(a)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(a)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(a)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(a)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
>>
>
>
>
>
