Re: [Cryptography] Why is emailing me my password?

2013-10-01 Thread Kent Borg

On 10/01/2013 10:28 AM, Greg wrote:

This falls somewhere in the land of beyond-the-absurd.


I noticed the password would be mailed in the clear when I signed up, 
but even if I had not, I would not have been bothered to later discover 
it.  What is the harm?  The sensitivity of this password is extremely 
limited.  That is, unless you are someone who recycles one password in 
other places.  You wouldn't do that, though, would you?


-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal

2013-09-18 Thread Kent Borg

On 09/18/2013 01:31 PM, Walter van Holst wrote:
What makes me a tad bitter is that we apparantly live in a world with 
two classes: US citizens and the subhuman rest of it. NSA-style 
blanket surveillance violates the fundamental right to privacy and 
ultimately also the fundamental right to freedom of expression. These 
are not rights that are solely vested in the exceptional Americans. 


You foreigners actually have a really big vote here.  All those US 
internet companies want your business, and as you get no protections, in 
the current scheme, not even lip-service, you should look for 
alternatives.  As you do, this puts pressure on the US internet 
companies, and they have the economic clout to put pressure on Feinstein 
and Polosi and all the others.


Sad that economic clout matters so much, but voters in the US are 
astoundingly ignorant of reality (pick a topic--other than sports and 
celebrity gossip--and we are ignorant), and so many can't be bothered to 
vote.  We kind of get the government we deserve.  Do what you can to 
save us, please.


-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


[Cryptography] Broken RNG Generating Taiwanese Citizen Digital Certificates

2013-09-16 Thread Kent Borg
Broken RNG-time again: In looking 2.2 million certificates, researchers 
found reused primes in 103 of them.



News story: 
http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/


Original paper: http://smartfacts.cr.yp.to/smartfacts-20130916.pdf


-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] real random numbers

2013-09-15 Thread Kent Borg

On 09/15/2013 10:19 AM, John Kelsey wrote:
But those are pretty critical things, especially (a). You need to know 
whether it is yet safe to generate your high-value keypair. For that, 
you don't need super precise entropy estimates, but you do need at 
least a good first cut entropy estimate--does this input string have 
20 bits of entropy or 120 bits? 


Yes, the time I was part of designing a physical RNG product (for use in 
real gambling, for real money) we made sure to not only sweep up all the 
entropy sources we could, and not only mixed in fixed information such 
as MAC addresses to further make different machines different, our 
manufacturing procedures included pre-seeding the stored pool with data 
from Linux computer that had a mouse and keyboard and lots of human input.


We did not try to do entropy accounting, but did worry about having enough.

We also were going way overboard on security thinking, far exceeding 
regulatory requirements for any jurisdiction we looked at.  I don't know 
if it every shipped to a customer, but we got all the approvals 
necessary so it could have...


I do agree that, though a Linux box might make keys on its first boot, 
it should be used interactively first, and then generate keys.


Again Ubuntu (at least a desktop install) doesn't include sshd by 
default, you have to decide to install it, and at that point, if there 
is a human setting up things with a keyboard and mouse, there should be 
a lot of entropy.  Ubuntu server installations might be different, and 
I would be very worried about automatic provisioning of server machines 
in bulk.


-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] real random numbers

2013-09-15 Thread Kent Borg
John Kelsey wrote:
 I think the big problem with (b) is in quantifying the entropy you get.

Maybe don't.

When Bruce Schneier last put his hand to designing an RNG he concluded that 
estimating entropy is doomed. I don't think he would object to some coarse 
order-of-magnitude confirmation that there is entropy coming in, but I think 
trying to meter entropy-in against entropy-out will either leave you starved or 
fooled.

-kb
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] real random numbers

2013-09-14 Thread Kent Borg

On 09/14/2013 03:29 PM, John Denker wrote:
Things like clock skew are usually nothing but squish ... not reliably 
predictable, but also not reliably unpredictable. I'm not interested 
in squish, and I'm not interested in speculation about things that 
might be random. 


I see theoretical the enemy of the good here.

The term squish is entertaining, but be careful that once you paint 
away with your broad brush that you don't dismiss engineering realities 
that matter.


I can see there is an appeal to entropy sources that you can work back 
to some quantum origin, but even they will fail horribly if you don't 
build a larger system that is secure, and secure at some non-trivial 
radius.  (How much Tempest-hardening are you going to do?)


And once we have built such vaguely secure systems, why reject entropy 
sources within those systems, merely because they you think they look 
like squish?  If there is a random component, why toss it out?  You 
seem to respect using hashing to condition and stretch entropy--though 
why any existing hash shouldn't also fall to your squish 
generalization, I don't know.  It seems that you would reject using a 
coin toss as a source of entropy because coins are not perfectly fair 
and there are biases in their results.  So?  You respect hashing, why 
not clean the output with a good hash?


You dismiss things like clock skew, but when I start to imagine ways 
to defeat interrupt timing as an entropy source, your Johnson noise 
source also fails: by the time the adversary has enough information 
about what is going on inside the GHz-plus box to infer precise clock 
phase, precise interrupt timing, and how fast the CPU responds...they 
have also tapped into the code that is counting your Johnson.


There are a lot of installed machines that can get useful entropy from 
existing sources, and it seems you would have the man who is dying of 
thirst die, because the water isn't pure enough.


Certainly, if hardware manufacturers want to put dedicated entropy 
sources in machines, I approve, and I am even going to use rdrand as 
*part* of my random numbers, but in the mean time, give the poor servers 
a sip of entropy.  (And bravo to Linux distributions that overruled the 
purist Linux maintainer who thought no entropy was better than poorly 
audited entropy, we are a lot more secure because of them.)



-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


[Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/11/2013 07:18 PM, Perry E. Metzger wrote:
the world's routers, servers, etc. do not have good sources, 
especially at first boot time, and for customer NAT boxes and the like 
the price points are vicious. 


I agree that things like consumer NAT boxes have a tricky problem, and 
anything that needs high bandwidth random data, but otherwise routers 
and servers are not as bad off as people say.  At least in the case of 
modern servers that are running enough of an OS to include a good 
entropy-pool RGN (like Linux's urandom*).


These boxes have GHz-plus clocks, so fast that the box doesn't have 
that clock, it only exists on-chip.  It is multiplied up from a lower 
frequency external crystal oscillator by an analog PLL which is also 
on-chip.  This fastest clock is commonly used to drive an on-chip 
counter.  These chips also have interrupts from the outside world.  
There is real entropy in the interaction between the two.


What is that value of that counter when the interrupt is serviced? I 
assert there is entropy in the LSB of that value.  A GHz-plus clock is 
running just too fast for someone meters (or kilometers) away to know 
its exact value.  And every time the observer might get the LSB wrong, a 
bit of entropy got by: Use that data to stir an entropy pool.


How do we know it is hard to know the value of a GHz-plus counter? 
Because of the engineering problems suffered by people trying to build 
fast systems.  Clock distribution is difficult--there is a reason that 
high speed clock doesn't exist off-chip, the skew becomes great.  Even 
on-chip clock distribution is tricky and requires careful layout rules 
when designing the chip.  And even on this fast chip, the uses of the 
fastest clock are limited and any functions that will work on a slower 
clock will get a slower clock. Clock distribution is hard.  Hard within 
a large IC, hard on a circuit board, hard between circuit boards, hard 
between boxes, hard between equipment racks, hard between 
buildings...how far away is this nefarious observer, the one who you 
worry might be able to infer the LSB?  I think more than a few cm is too 
far away and if you don't have security at that radius, you don't have 
security.



[* Until Linux kernel 3.6 the person maintaining urandom was busily 
turning off interrupts as a source of entropy, I think because he didn't 
know how much entropy he was getting so better not to get it at all 
(huh?).  In 3.6 this was changed to use all interrupts as entropy 
sources, which is good.  This means earlier kernels aren't so 
good--though I notice that Ubuntu's kernel has the 3.6 improvement in 
their version of 3.2, so individual distributions will vary.]



-kb
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/12/2013 10:41 AM, Kent Borg wrote:
routers and servers are not as bad off as people say. 


Not that more sources is bad.  A new trustworthy HW entropy source would 
be good.  Even a suspect rdrand is worth XORing in (as Linux does on the 
machine I am using right now).


But if you thirst for more entropy keep looking in your current 
hardware, server boxes are particularly good hunting grounds for a few 
more dribs of entropy:


 - current RPM of all the fans (the proverbial entropy-starved server 
can have a lot of fans)

 - temperatures
 - voltages
 - disk (SMART) statistics (temperatures and error counts, multiplied 
by the number of disks)


These are all things that could wear out or go wrong, which means they 
need monitoring because...you can't otherwise know what they are.  Cool, 
that's a decent definition of entropy.  Sample them regularly and hash 
them into your entropy pool.  Not a lot of bandwidth there, but if your 
RNG does a good job of hiding its internal state, and you are mixing in 
a dozen more bits here and a dozen more bits there...pretty soon you 
have made the attacker's job a lot harder.


Maybe not as sexy as a lavalamp or radioactive gizmos, but more 
practical and available now.


-kb



___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Finding Entropy Isn't That Hard

2013-09-13 Thread Kent Borg

On 09/13/2013 11:59 AM, Marcus Leech wrote:
Any physical-world sensor driver, where the sensor inherently has a 
bit of noise, I think has a moral obligation to contribute bits to 
the kernel entopy pool.


Within limits.  Mixing the entropy pool on Linux takes work and battery 
power.


Looking at some random Android kernel source code (git commit c73c9662) 
it looks like add_interrupt_randomness() is happening for every 
interrupt (your Android device's kernel may vary), so there is probably 
plenty of entropy.  And add_interrupt_randomness() throttles to only 
feed the randomness once a second, not wasting our time or battery.


Don't carry moral obligation beyond what is reasonable!

-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-09 Thread Kent Borg

On 09/08/2013 11:56 PM, Jerry Leichter wrote:

Which brings into the light the question:  Just *why* have so many random 
number generators proved to be so weak.


Your three cases left off an important one: Not bothering to seed the 
PRNG at all.  I think the Java/Android cryptographic (!) library bug 
that just came up was an instance of that.


I think the root of the problem is that programs are written, and bugs 
squashed, until the program works. Maybe throw some additional testing 
at it if we are being thorough, but then business pressures and boredom 
says ship it.


That won't catch a PRNG that wasn't seeded, nor a hashed password that 
wasn't salted, the unprotected URL, the SQL injection path, buffer 
overflow, etc.


Computer security is design, implementation, and skepticism.  But unless 
you can sell it with a buzzword...



-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-08 Thread Kent Borg

On 09/08/2013 06:16 PM, John Kelsey wrote:
I don't think you can do anything useful in crypto without some good 
source of random bits.


I don't see the big worry about how hard it is to generate random 
numbers unless:


 a) You need them super fast (because you are Google, trying to secure 
your very high-speed long lines), or


 b) You are some embedded device that is impoverished for both sources 
of entropy and non-volatile storage, and you need good random bits the 
moment you boot.


On everything in between, there are sources of entropy. Collect them, 
hash then together and use them to feed some good cryptography.  If you 
seem short of entropy, look for more in your hardware manual. Hash in 
any local unique information. Hash in everything you can find! (If the 
NSA knows every single bit you are hashing in, no harm, hash them in 
anyway, but...if the NSA has misunderestimated  any one of your 
bits...then you scored a bit! Repeat as necessary.)


I am thinking pure HW RNGs are more sinful than pure SW RNGs, because 
real world entropy is colored and hardware is the wrong place to fix 
that. So don't buy HW RNGs, buy HW entropy sources (or find them in your 
current HW) and feed them into a good hybrid RNG.


On a modern multi-GHz CPU the exact LSB of your highspeed system 
counters, when the interrupt hits your service routine, has uncertainty 
that is quite real once the you push the NSA a few centimeters from your 
CPU or SoC.  Just sit around until you have a few network packets and 
you can have some real entropy. Wait longer for more entropy.


In case you did notice, I am a fan of hybrid HW/SW RNGs.

-kb


P.S.  Entropy pools that are only saved on orderly shutdowns are risking 
crash-and-playback attacks. Save regularly, or something like that.


P.P.S. Don't try to estimate entropy, it is a fool's errand, get as much 
as you can (within reason) and feed it into some good cryptography.


P.P.P.S. Have an independent RNG? If it *is* independent, no harm in 
XORing it in.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-08 Thread Kent Borg

On 09/08/2013 09:15 PM, Perry E. Metzger wrote:
Perhaps you don't see the big worry, but real world experience says it 
is something everyone else should worry about anyway.


I overstated it.

Good random numbers are crucial, and like any cryptography, exact 
details matter.  Programmers are constantly making embarrassing 
mistakes.  (The recent Android RNG bug, was that Sun, Oracle, or Google?)


But there is no special reason to worry about corrupted HW RNGs because 
one should not be using them as-is, there are better ways to get good 
random data, ways not obvious to a naive civilian, but still well known.


Snowden reassured us when he said that good cryptography is still good 
cryptography.  If that includes both hashes and cyphers, then the 
fundamental components of sensible hybrid RNGs are sound.


Much more worrisome is whether Manchurian Circuits have been added to 
any hardware, no matter its admitted purpose, just waiting to be activated.


-kb

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography