Re: CPRNGs are still an issue.

2008-12-18 Thread David G. Koontz
Charles Jackson wrote:

 
 I probably should not be commenting, not being a real device guy.  But,
 variations in temperature and time could be expected to change SSD timing.
 Temperature changes will probably change the power supply voltages and shift
 some of the thresholds in the devices.  Oscillators will drift with changes
 in temperature and voltage.  Battery voltages tend to go down over time and
 up with temperature.  In addition, in some systems the clock frequency is
 purposely swept over something like a 0.1% range in order to smooth out the
 RF emissions from the device.  (This can give a 20 or 30 dB reduction in
 peak emissions at a given frequency.  There is, of course, no change in
 total emissions.)
 
 Combine all of these factors, and one can envision the SSD cycles taking
 varying numbers of system clock ticks and consequently the low order bits of
 a counter driven by a system clock would be random.  However, one would
 have to test this kind of entropy source carefully and would have to keep
 track of any changes in the manufacturing processes for both the SSD and the
 processor chip. 
 
 Is there anyone out there who knows about device timing that can say more?  

As a chip wonk, without addressing SSD operational timing directly how much
a clock can change is dependent on the accuracy over a period of time
sufficient to be off by one or more clocks, implying long counter chain
timing - slow entropy accumulation at best.  Worse still, the error value
when compared to an outside clock source would tend to be at a fixed rate,
although you see minor variations based on temperature and voltage.  The
same things that make power analysis a valid attack also influence
temperature and voltage.  I'd expect you could  manipulate second order
effects by how the system is operated. Other than effects on frequency,
temperature and voltage affect switching thresholds which can cause
variability in delay in particular when crossing clock domains.  These
threshold delays can be strongly correlated.

Dithered clocks are intended to only fool spectrum analyzers measuring peak
power and are not based on entropy or second order effects.  A PLL feedback
pattern is typically masked by applying the output of a counter and look up
table or combinatoric circuit.  There is no disparity generated long term in
clock high and low bauds, the counter makes the dithering periodic.  Think
short PRNG cyclically applying clock edge offsets and hitting all the
positive and negative offsets equally.

The two don't strike me as sufficient to construct an adequate ergodic system.

Using a HDD as an 'entropy' source is based on operating an ergodic system
where the preceding state is not readily predictable.   The variability is
based in part on sectors and cylinders, angular velocity, disk position and
head position.  All that variability can collapse in an SSD.  Trying to rely
on remaining secondary effects for loss of predictability could be countered
by eliminating or reducing them.  We design systems to not be readily
influenced by secondary effects in the first place.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: CPRNGs are still an issue.

2008-12-18 Thread Nicolas Williams
On Wed, Dec 17, 2008 at 03:02:54PM -0500, Perry E. Metzger wrote:
 The longer I'm in this field, the more the phrase use with extreme
 caution seems to mean don't use to me. More and more, I think that
 if you don't have a really good way to test and get assurance about a
 component of your security architecture, you should leave that
 component out.

But do beware of becoming something of a luddite w.r.t. entropy sources.

If you can mix seeds into your entropy pool without destroying the
entropy of your pool (and we agree that you can) while adding some of
any entropy in your seeds (and we agree that you can), then why not?

Yes, I saw your other message.  Testing entropy pools and sources is
hard if you want real entropy.  One way to test the pool and its mixing
function is to add and use a hook for supplying test vectors instead of
real entropy for each source.  But to test the operational system, if it
has real entropy sources, is harder.  So you might as well add in a
fixed, manufacture-time seed + time/counter-based salting, as you
suggested.  And you'll still want to test the result, but you can only
apply statistical analysis to the outputs to decide if they're
random-*looking*.

Having no entropy sources is not a good option for systems where the
threat model requires good entropy sources (e.g., if you want PFS to
prevent compromise of an end-point from compromising pre-compromise
communications).  IMO it's not wise to trivially reject an all of the
above approach to entropy gathering.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: CPRNGs and assurance...

2008-12-18 Thread Jerry Leichter

On Dec 17, 2008, at 3:18 PM, Perry E. Metzger wrote:


I'd like to expand on a point I made a little while ago about the
just throw everything at it, and hope the good sources drown out the
bad ones entropy collection strategy.

The biggest problem in security systems isn't whether you're using 128
bit or 256 bit AES keys or similar trivia. The biggest problem is the
limited ability of the human mind to understand a design. This leads
to design bugs and implementation bugs. Design and implementation
flaws are the biggest failure mode for security systems, not whether
it will take all the energy in our galaxy vs. the entire visible
universe to brute force a key.

So, if you're designing any security system, the biggest thing on your
mind has to be how to validate that the system is secure. That
requires ways to know your design was correct, and ways to know you
actually implemented your design correctly

Excellent points.

For the particular case of random generators based on mixing multiple  
sources, I would suggest that there are some obvious - if, apparently,  
little-used - testing strategies that will eliminate the most common  
failure modes:


1.  Test the combiner.  The combiner is a deterministic function.  If  
you give it known inputs, the results will always be the same.  The  
result is supposed to depend sensitively on all the inputs, so if you  
change any input, you should get very outputs.  This kind of testing  
would have avoid the Debian fiasco.


Note that knowing you have to write such a test will also discourage  
throwing in all sorts of complexity you don't understand because it  
can't hurt.  It can, and has.


2.  There are many tests you can apply that will detect *non*- 
randomness.  Test the *inputs* to your combiner.  If an input  
consistently fails, think about whether it's adding adding enough  
value to be worth the complexity.  If your inputs normally succeed and  
start failing ... something is wrong.


Since it's cheap to do, you might as well apply the same test to the  
output of the combiner - but don't expect to learn anything:  With any  
decent combiner, even fixed inputs should produce random-looking  
output.  So any problem detected this way is very serious.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Why the poor uptake of encrypted email?

2008-12-18 Thread James A. Donald

Nicolas Williams wrote:
 Providing a suitable e-mail security solution for the
 masses strikes me as more important than providing
 anonymity to the few people who want or need it.  Not
 that you can't have both, unless you want everyone to
 use PGP or S/MIME as a way to hide anonymized traffic
 from non-anonymized traffic.

If email goes away - as I hope and expect it will - we
will need a new store and forward solution to support
anonymity.

A store and forward system is a system without end to
end real time round trips.  Obviously end to end real
time round trips prevent anonymity.

A system built on top of a best effort unreliable
messaging system requires some round tripping, which
does not make anonymity impossible, but does make it
tricky.  Email's architecture is very nice for
supporting anonymity.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Why the poor uptake of encrypted email?

2008-12-18 Thread James A. Donald

Peter Gutmann wrote:
 ... to a statistically irrelevant bunch of geeks.
 Watch Skype deploy a not- terribly-anonymous (to the
 people running the Skype servers) communications
 system.

Actually that is pretty anonymous.  Although I am sure
that Skype would play ball with any bunch of goons that
put forward a plausible justification, or threated to
rip their fingernails off, most government agencies find
it difficult to deal with anyone that they cannot
casually have thrown in jail - dealing with equals is
not part of their mindset.  So if your threat model does
not include the FBI and the CIA, chances are that  the
people who are threatening you will lack the
organization and mindset to get Skype's cooperation.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com