<div dir="ltr"><div><div><div>Sure that makes sense. Historically there were no such service in the System.<br>I wanted to remind that crypto has to care that randomness comes from sufficiently random source, not just a random random source.<br>
</div>If the contract is explicit enough (Smalltalk cryptoLevelRandom?), then it can move to the System.<br></div>But would it serve other purpose than crypto?<br></div>I would rather implement a CryptoRandom class part of Crypto package, either via plugin or FFI to wrap over /dev/random or equivalent...<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/19 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<div class="HOEnZb"><div class="h5"><<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, they<br>
> are considered too easy to crack.<br>
> I guess that sound input was seen as a universal way to get some hardware<br>
> 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 other<br>
>> 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 _plugs<br>
>> that in_, but the direct reference is suboptimal.<br>
>><br>
>> frank<br>
>><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>