Which TLS cipher suites are secure without a strong entropy source on the client?
Not the ephemeral DH/ECDH suites, as the client's ephemeral key will be weak. Am I right in thinking that with the older non-forward-secret RSA suites, the client generates a session key and sends it to the server encrypted with the server's public key? If so, those suites are out too as the season key will be weak.
Cheers,
Michael
coderman <coderman@???> wrote:
>On Sun, Aug 3, 2014 at 12:35 PM, David Goulet <dgoulet@???> wrote:
>> ...
>> I asked a friend of mine working for Canonical asking him how they do
>> things with Ubuntu images.
>>
>> He told me that they can't use haveged since it's only good to
>> *increase* your entropy pool and rngd is useless without an hardware
>> RNG. Their big issue is the Ubuntu Cloud Image for which they rely on
>> https://launchpad.net/pollinate,
>
>yes; the common "worst case scenario" along with embedded devices. i
>didn't mention dakarand, but it is in the same class as havaged.
>
>
>
>> TL;DR; it fetches random bytes over
>> HTTPS to seed /dev/random. (They do pin the certificate in the client
>> which is less crazy :).
>
>they have plenty of central trust, so seeding over HTTPS perfectly
>sane and a clear improvement for this situation.
>
>
>
>> To be honest, I don't have a good way of fixing this issue. Feeding the
>> urandom-seed with the date might be better than nothing but again I
>> think that if a NTP correction occurs before seeding it, an attacker
>> could end up knowing the seed if the NTP server or the link is
>> malicious.
>
>this is a valid concern and not resolved unless rngd with a good true
>source is present. unfortunately, as you indicate, no good
>alternatives...
>
>
>
>> Is it crazy to think that Tails could provide a "seeding server" and use
>> pollinate?
>
>ideally a per image seed would be mixed before kernel calls init, like
>device entropy mixing, along with a consensus runtime seed, before
>calling init, but in a way that is all of mallory resistant, datagram
>based, under fragmentation threshold, many transport distributed like
>a Tor consensus over arbitrary IPv4, IPv6, DVB-T, clandestine
>shortwave, and any other convenient local broadcast horizon. left as
>exercise for reader. ;)
>
>
>tls-tor-random to torproject, bridges, or onions as first step would
>be quite convenient, in seriousness, for a better fix to poor entropy
>situation at start. i have no idea how long just that part would be
>to develop, what partitioning attacks it may expose its users to, nor
>how much use it would receive in the wild, among other mysteries.
>
>
>best regards,
>_______________________________________________
>Tails-dev mailing list
>Tails-dev@???
>https://mailman.boum.org/listinfo/tails-dev
>To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
