I also was pondering as to how the implementers could have arrived at
this situation towards evaluating Stephen Farrell's draft idea to have
a service that double checks at key gen time (that none of the p, q
values are reused). http://www.ietf.org/id/draft-farrell-kc-00.txt
(Which I dont think
On 2012-02-18 7:40 PM, Adam Back wrote:
Occam's razor suggests cryptographic incompetence.. number one reason
deployed systems have crypto fails. Who needs to hire crypto people,
the developer can hack it together, how hard can it be etc. There's a
psychological theory of why this kind of
On 18/02/12 23:05 PM, Peter Gutmann wrote:
Morlock Elloimorlockel...@yahoo.com writes:
Properly designed rngs should refuse to supply bits that have less than
specified (nominal) entropy. The requestor can go away or wait.
So you're going to sacrifice availability for some nebulous (to the
I missed a favorite of mine that I've personally found multiple times
in deployed systems from small (10k users) to large (mil plus users),
without naming the guilty:
4. The RNG used was rand(3), and while there were multiple entropy
additions, they were fed using multiple invocations of
It was (2), they didn't wait.
Come on -- every one of these devices is some distribution of Linux that comes
with a stripped-down kernel and Busybox. It's got stripped-down startup, and no
one thought that it couldn't have enough entropy. These are *network* people,
not crypto people, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/16/2012 03:47 PM, Nico Williams wrote:
I'd thought that you were going to say that so many devices sharing
the same key instead of one prime would be better on account of the
problem being more noticeable. Otherwise I don't see the
On Fri, Feb 17, 2012 at 8:39 PM, Thierry Moreau
thierry.mor...@connotech.com wrote:
Ben Laurie wrote:
On Fri, Feb 17, 2012 at 7:32 PM, Thierry Moreau
thierry.mor...@connotech.com wrote:
Isn't /dev/urandom BY DEFINITION of limited true entropy?
$ ls -l /dev/urandom
lrwxr-xr-x 1 root
On Feb 16, 2012, at 9:52 AM, Marsh Ray wrote:
How often have we seen Linux distros generate SSH keys 2 seconds after the
first boot?
The paper that started this thread was talking about keys used for TLS, not
SSH. TLS certs are not usually generated during first boot. The devices had
plenty
On Sat, Feb 18, 2012 at 12:57:30PM -0500, Jeffrey I. Schiller wrote:
The problem is that ssh-keygen uses /dev/urandom and it should really
use /dev/random. I suspect that once upon a time it may have (I don't
have the history off hand) and someone got annoyed when it blocked and
solved the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/2012 01:50 PM, Thor Lancelot Simon wrote:
Um, why would it ever _unblock_, on such a device under typical
first-boot conditions?
The idea would be that bootstrap would continue without the key being
generated. The key generation could then
On Feb 18, 2012, at 11:37 AM, Jeffrey I. Schiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/2012 01:50 PM, Thor Lancelot Simon wrote:
Um, why would it ever _unblock_, on such a device under typical
first-boot conditions?
The idea would be that bootstrap would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/18/2012 03:02 PM, Paul Hoffman wrote:
Really? Many cryptographers would say that number of unpredictable
bits is very much a part of the question? ...
Of course it is. What I meant was that if /dev/random returns data,
its contract is to
Mozilla has issued a statement about MITM certs:
https://blog.mozilla.com/security/2012/02/17/message-to-certificate-authorities-about-subordinate-cas/
(Ack: Paul Hoffman posted this link to g+)
___
cryptography mailing list
cryptography@randombit.net
What crypto mumbo jumbo is this?
From: http://www.porticor.com/2012/02/thewhir-q-and-a/
--
Lets’ define the challenge, first. Customers want to both have their
cake and eat it: they want security and they want to enjoy the
flexibility offered by modern clouds. Let’s demystify
14 matches
Mail list logo
