On 02/16/2012 02:20 PM, Phillip Hallam-Baker wrote:
On Thu, Feb 16, 2012 at 9:13 AM, Stephen Farrell
<[email protected]> wrote:
On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote:
My first thought was that this should be done by the CA.
In the cited material, they also cover PGP and SSH keys and
not every CA will have a collection beyond its own end
entities so I don't think this is a CA function since its
not checking one public key, but one public key against
a population of keys and is independent of X.509, PGP, SSH
etc.
Then it turns
out that these are all (apparently) embedded systems generated keys
and only some of those are CA certified. So maybe there is a need for
this protocol.
That too.
Problem being that it is probably easier to implement a RNG right than
to implement any additional protocol for checking. Or at least the
only people who are likely to implement your protocol are people who
(1) would do the RNG right or (2) are required to for an audit
requirement.
A fair point. But one we don't seem to be able to get right
and there are to also be fair some subtleties.
Apparently some of the problem is also not the PRNG algorithm,
but rather when you call it.
For example, the 1st prime generation might happen just after
1st boot when there're few sources of randomness on the device.
So while the 2nd prime may be much more random the probability
of the 1st one being the same as someone else's is high enough
to be a problem. (Apparently. He repeated:-)
So there might be reasons to call this even if you're
confident of your key generation code, in case someone fed the
PRNG a crap seed.
S
It would be really nice if there was some way to audit RNGs algorithmically...
As I have mentioned before though, public key is problematic in
embedded systems. Most of the systems don't have the resources to do
the job right and this will only get worse as time goes on because as
a $1 processor gets more powerful a chip with a 6502 core gets cheaper
and more are made. More 6502 type chips were made last year than in
any previous year.
So my view is that we have to get away from the idea that the endpoint
has to do public key crypto.
Well, that's one position but not necessarily the only one
with merit.
Well certainly it is better that they do have a PKI stack but only if
they do it right and that puts us way above what a PIC controller
class chip with only a few Kb can be expected to do.
Hence we need to have two tracks. Rather than telling people that they
must do PKI on 16 bit chips, maybe have a different approach there.
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
