[147971] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Alan Braggins)
Sun Nov 3 18:07:06 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAMm+Lwi8EZN7vSgpuX9otNuKWtO-QO-MKmB-Uxw4qjAm2YjPOw@mail.gmail.com>
Date: Sun, 3 Nov 2013 22:27:01 +0000
From: Alan Braggins <alan.braggins@gmail.com>
To: Cryptography <cryptography@metzdowd.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 24 October 2013 16:16, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> I think the more worrying case is a freshly imaged rack mount server,
>> immediately generating keys or outputting random numbers to the network or
>> in response to network queries.
>
> +1
>
> And I have not seen any proposal that is really going to solve this
> particular problem in the thread since.
>
> If I was asked three months ago my position would be 'generate the keys on
> the device that is going to use them and they never leave unless it is a
> really constrained device like a credit card.'
>
> I have completely changed my mind on this. I now think public keys should be
> generated in device adapted for that purpose and migrated out using some
> form of secure protocol that ensures only the intended device can use them.
Given that we're assuming the device can't reliably generate a secure key pair,
and assuming that it doesn't already have a secret specific to the device, what
protocols would be suitable for doing that?
(And if we can ask a device to generate keys and securely migrate them to us,
we can ask it to generate some random seed material that isn't visible to an
attacker, which solves the problem of local generation.)
--
alan.braggins@gmail.com
http://www.chiark.greenend.org.uk/~armb/
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
