[squeak-dev] Crypto support?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Nov 19 21:42:48 UTC 2013


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
> >>
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/92c7ab38/attachment.htm


More information about the Squeak-dev mailing list