On Thu, 15 Aug 2013 13:11, wasabe...@gmail.com said:
To: and From: headers leak the emails/identity of communicating parties,
but it's not the only place that happens. I've never used PGP but I've used
OpenPGP allows sending messages without information on the used keys
(e.g. gpg
I thought that decent crypto programs (openssh, openssl, tls suites)
should read from random so they stay secure and don't start generating
/insecure/ data when entropy runs low. The only way I could see this
as being a smart thing to do is if these programs also looked at how
much entropy the
I think the programs block when reading from random, if the kernel
doesnt have enough entropy. When reading from urandom, that is not the
case. Basically the internal pool is reused to generate pseudo random
bits so that the call doesnt need to block.
As far as I know, there is no measure like 50
On Fri, Aug 16, 2013 at 10:03 AM, Swair Mehta swairme...@gmail.com wrote:
As far as I know, there is no measure like 50 or so for /dev/random.
/proc/sys/kernel/random/entropy_avail
___
cryptography mailing list
cryptography@randombit.net
On Fri, Aug 16, 2013 at 11:03 AM, Dominik Schürmann
domi...@dominikschuermann.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For a research project on OCSP, we are searching for expired and
revoked X.509 certificates with their corresponding private keys. Any
help or pointers to
On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote:
I thought that decent crypto programs (openssh, openssl, tls suites)
should read from random so they stay secure and don't start generating
/insecure/ data when entropy runs low.
This presumes that urandom is somehow
On Fri, Aug 16, 2013 at 11:42 AM, Tony Arcieri basc...@gmail.com wrote:
On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote:
I thought that decent crypto programs (openssh, openssl, tls suites)
should read from random so they stay secure and don't start generating
On Fri, Aug 16, 2013 at 12:03 PM, Tony Arcieri basc...@gmail.com wrote:
On Fri, Aug 16, 2013 at 8:47 AM, Patrick Mylund Nielsen
cryptogra...@patrickmylund.com wrote:
Not for nothing, but that refers to both random and urandom, showing one
problem with the entropy estimation, and another
On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote:
Nothing really gets anyone past the enormous supply of zero-day vulns in
their complete stacks. In the end I assume there's no technological PRISM
workarounds.
I agree that compromise of the client is relevant. My current
On Tue, Aug 13, 2013 at 01:52:38PM -0500, Nicolai wrote:
Zooko: Congrats on the service. I'm wondering if you could mention on the
site which primitives are used client-side. All I see is that combinations
of sftp and ssl are used for data-in-flight.
Thanks!
I'm not sure what your
On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen
cryptogra...@patrickmylund.com wrote:
Yes, but they aren't talking about urandom. Your reply made it sound like
random is weak, but the paper points to both (as urandom is seeded by
random), and they propose a new AES-based PRNG that
On Fri, Aug 16, 2013 at 2:11 PM, zooko zo...@zooko.com wrote:
On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote:
Nothing really gets anyone past the enormous supply of zero-day vulns in
their complete stacks. In the end I assume there's no technological PRISM
workarounds.
I
On Fri, Aug 16, 2013 at 3:30 PM, Tony Arcieri basc...@gmail.com wrote:
On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen
cryptogra...@patrickmylund.com wrote:
Yes, but they aren't talking about urandom. Your reply made it sound like
random is weak, but the paper points to both (as
On Fri, Aug 16, 2013 at 12:49 PM, Patrick Mylund Nielsen
cryptogra...@patrickmylund.com wrote:
You replied with a link to a paper that states that both /dev/random and
/dev/urandom have the same weaknesses, and said that /dev/random isn't
robust.
I was quoting the title of the paper in the
On Fri, Aug 16, 2013 at 12:55 PM, Tony Arcieri basc...@gmail.com wrote:
I was quoting the title of the paper in the context of a thread in which
someone claimed that /dev/random should be used in lieu of /dev/random.
That's all I was pointing out.
Blah, /dev/urandom...
--
Tony Arcieri
also posted here: https://leastauthority.com/blog/open_letter_silent_circle.html
This open letter is in response to the `recent shutdown of Lavabit`_ ,
the ensuing `shutdown of Silent Circle's “Silent Mail” product`_, `Jon
Callas's posts about the topic on G+`_, and `Phil Zimmermann's
interview
Aaron Toponce writes:
Cryptographers don't like the idea that it's possible, even if it's
excessively remote, and highly unprobable. This is why you see suggestions
to use /dev/random for long term SSH, SSL and OpenPGP keys.
Cryptographers are certainly not responsible for this superstitious
On Fri, Aug 16, 2013 at 7:24 PM, D. J. Bernstein d...@cr.yp.to wrote:
I'm not saying that /dev/urandom has a perfect API. [...]
It might be useful to think of what a good API would be. I've thought
before that the Unix everything-as-a-file philosophy makes for lame
entropy APIs, and yet it's
At startup, likely to be short of entropy.
Actual behavior, and even existence, of /dev/random and /dev/urandom
varies substantially from one implementation to another.
If /dev/random blocks when short of entropy, then likely to block at
startup, which is good. Services that need entropy do
On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com
wrote:
If /dev/urandom seeded at startup, and then seeded no further, bad, but not
very bad.
If /dev/urandom seeded at startup from /dev/random, then should block at
startup.
If /dev/urandom never blocks, bad. Should block
On Fri, Aug 16, 2013 at 10:33:11PM -0400, shawn wilson wrote:
On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com wrote:
At startup, likely to be short of entropy.
If /dev/urandom seeded at startup, and then seeded no further, bad, but not
very bad.
If /dev/urandom
21 matches
Mail list logo