RNG quality verification

Philipp Gühring pg at futureware.at
Fri Dec 23 09:47:53 EST 2005


Hi David,

> Go tell whoever wrote your requirements that they (to be frank) don't
> know what they're talking about.  

:-)

> What they're asking for doesn't make 
> any sense.  

At first I had the same answer. But then I started to think it through.
And it makes far more sense to me now.

> You should ask them what problem they're trying to solve. 

They are just trying to fulfill the legal requirements.

> Don't let them try to tell you how to solve it; you just need to know
> the goal, not the mechanism.

They just told me their requirements, and how it is normally solved. 
I am known for inventing my own mechanisms to solve requirements.

Actually, I already developed one mechanism, that solves that problem as a 
side-effect.
http://wiki.cacert.org/wiki/QualifiedCertificateRequest
But it´s dedicated for hardware implementations, and I need mechanism for  
software implementations (mostly for the browsers) now.

> The standard solution is to just not worry about this at all, and say
> that it is the user's responsibility to choose good random numbers.

Yes. That´s what I am planning to do.

But what do I do, if the users ask "And how do I do that?"

It´s easy to say that it´s their responsibility.
But how should they do it?

At the moment, I wouldn´t even know how to do it myself, if someone asked me 
to care for it.

Ok, let´s forget the CA and the users. How do I do it myself?
How do I make sure myself, that the browser is generating good random numbers, 
and actually using them properly for the certificate requests?
I will be personally liable for it, it that random thing breaks.

Well, I could get a lot of paper, a good hex editor, and start calculating my 
own RSA keys with pencil and paper, read through the ASN.1 specifications, 
and manufacture my certificate request myself.
(Has anyone actually does that yet, and can give some time-estimations?)

> If the user fails to do so, they're the one who bears the costs of their
> failure, so why should you care?

Perhaps because I am working for a CA that actually does care.

Do you know any browser vendor that guarantees the correct generation of 
secure random numbers and their correct usage, that offer to take liability, 
if it goes wrong?

> If the goal is to hold the hands of your users, then you might want to
> think carefully about whether you want to be in that business, 

I am already in that business. And yes, it´s great fun, and I like it.

> what are 
> the most likely failure modes, and what is the best way to deal with it.
> (Trying to check whether their numbers are random probably isn't the best
> answer.)  

Well, I have to start somewhere. And the best way to start that I could find 
is by fulfilling the requirements that are already given. So yes, I start 
here now. And I´ll try not to stop, before I haven´t found good answers to 
all the open questions.

> Most CA's have gravitated towards the opinion that that's not 
> something they can control, nor do they want to, nor should they -- 

I don´t want to control it, I want to audit it. I want the users to have it 
under their control. At the moment, nobody gave them much control over the 
random number quality of the keys they are using.

> and 
> that sounds reasonable to me.  

Yes, it´s reasonable, if you aren´t paranoid enough. I thought exactly the 
same way, before I started to think more about this specific topic more 
detailled. Now I think it´s a bit negligent to ignore the topic completely.
But perhaps there are bigger problems, yes. (Sometimes little problems are 
easier to solve than bigger problems ...)

> But if you want to be in the hand-holding 
> business, you're going to have to do an awful lot more than just check
> the random numbers.

Yes. Do you have a TODO list for me?

Thanks for your input,
Philipp Gühring


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list