Jack Lloyd ll...@randombit.net writes:
On Wed, Oct 06, 2010 at 04:52:46PM +1300, Peter Gutmann wrote:
Right, because the problem with commercial PKI is all those attackers who are
factoring 1024-bit moduli, and apart from that every other bit of it works
perfectly.
_If_ Mozilla and the
Bill Stewart bill.stew...@pobox.com writes:
Basically, 2048's safe with current hardware
until we get some radical breakthrough
like P==NP or useful quantum computers,
and if we develop hardware radical enough to
use a significant fraction of the solar output,
we'll probably find it much
Perry E. Metzger pe...@piermont.com writes:
Ekr has an interesting blog post up on the question of whether protocol
support for periodic rekeying is a good or a bad thing:
http://www.educatedguesswork.org/2010/03/against_rekeying.html
I'd be interested in hearing what people think on the
Perry E. Metzger pe...@piermont.com writes:
This does necessitate an extra manufacturing step in which the device
gets individualized, but you're setting the default password to a
per-device string and having that taped to the top of the box anyway,
right? If you're not, most of the boxes
Victor Duchovni [EMAIL PROTECTED] writes:
On Tue, Jun 03, 2008 at 04:37:20PM -0400, Eric Cronin wrote:
On Jun 3, 2008, at 11:51 AM, Adam Aviv wrote:
Depending on the level of protection you want, you could just add a
script to your .forward to encrypt your email before delivery using
Taral [EMAIL PROTECTED] writes:
On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote:
For example, reading a lot of data from linux's /dev/urandom will
deplete the entropy pool in the kernel, which effectively makes reads
from /dev/random stall. The two devices uses the same entropy pool
Ben Laurie [EMAIL PROTECTED] writes:
Steven M. Bellovin wrote:
On Sat, 24 May 2008 20:29:51 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Of course, we have now persuaded even the most stubborn OS that
randomness matters, and most of them make it available, so perhaps
this concern is moot.
David Wagner [EMAIL PROTECTED] writes:
Crawford Nathan-HMGT87 writes:
One of the problems with the Linux random number generator
is that it happens to be quite slow, especially if you need a lot of
data.
/dev/urandom is blindingly fast. For most applications, that's
all you need.
Alas,
Following up on an old thread with some new information:
Hitachi's white paper is available from:
http://www.hitachigst.com/tech/techlib.nsf/techdocs/74D8260832F2F75E862572D7004AE077/$file/bulk_encryption_white_paper.pdf
...
The interesting part is the final sentence of the white paper:
Jacob Appelbaum [EMAIL PROTECTED] writes:
Seagate recently announced a 1TB drive for desktop systems and a 250GB
laptop drive. What's of interest is that it appears to use a system
called DriveTrust for Full Disk Encryption. It's apparently AES-128.
The detail lacking press release is here:
Alexander Klimov [EMAIL PROTECTED] writes:
Are you afraid of attackers secretly changing your software (to
monitor you?) while your computer is off?
I believe this is a not completely unreasonable threat. Modifying files
on the /boot partition to install a keylogger is not rocket science, and
Paul Hoffman [EMAIL PROTECTED] writes:
At 5:51 PM +0100 4/4/07, Dave Korn wrote:
Can anyone seriously imagine countries like Iran or China signing up to a
system that places complete control, surveillance and falsification
capabilities in the hands of the US' military intelligence?
No.
Leichter, Jerry [EMAIL PROTECTED] writes:
I agree that there are two issues, and they need to be treated
properly. The first - including data after the ASN.1 blob in the
signature computation but then ignoring it in determining the
semantics - is, I'll argue, an implementation error. You
Leichter, Jerry [EMAIL PROTECTED] writes:
Granted, one or more implementations got this wrong. (Has anyone looked
to see if all the incorrect code all descends from a common root, way
back when?)
We have at least three independent widely used implementations that
got things wrong: OpenSSL,
[EMAIL PROTECTED] (Peter Gutmann) writes:
Consequently, I think the focus on e=3 is misguided.
It's not at all misguided. This whole debate about trying to hang on to e=3
seems like the argument about epicycles, you modify the theory to handle
anomalies, then you modify it again to handle
Whyte, William [EMAIL PROTECTED] writes:
This is incorrect. The simple form of the attack
is exactly as described above - implementations
ignore extraneous data after the hash. This
extraneous data is _not_ part of the ASN.1 data.
James A. Donald wrote:
But it is only
Jostein Tveit [EMAIL PROTECTED] writes:
Anyone got a test key with a real and a forged signature to test
other implementations than OpenSSL?
There are actually two problems to consider...
First, there is the situation by Bleichenbacher at Crypto 06 and
explained in:
Werner Koch [EMAIL PROTECTED] writes:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design
Steven M. Bellovin [EMAIL PROTECTED] writes:
http://mathworld.wolfram.com/news/2005-11-08/rsa-640/
There are timing details in:
http://www.crypto-world.com/announcements/rsa640.txt
They claim they need 5 months of 80 machines with 2.2GHz processors.
Using these numbers, I think it would be
Victor Duchovni [EMAIL PROTECTED] writes:
On Wed, Nov 09, 2005 at 05:27:12PM +0100, Simon Josefsson wrote:
I'm not sure translating complexity into running time is reasonable,
but pending other ideas, this is a first sketch.
It is not reasonable, because the biggest constraint is memory
I thought that this might be of some interest; I just released a new
version of GnuTLS that disable RSA-MD5 for some X.509 uses by default.
See announcements and details below.
Feedback and suggestions are always welcome.
Cheers,
Simon
From: Simon Josefsson [EMAIL PROTECTED]
Subject: GnuTLS
Werner Koch [EMAIL PROTECTED] writes:
On Mon, 29 Aug 2005 17:32:47 +0200, Simon Josefsson said:
which are Fermat pseudoprime in every base. Some applications,
e.g. Libgcrypt used by GnuPG, use Fermat tests, so if you have control
of the random number generator, I believe you could make
Ben Laurie [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
No, the certificate is verifiable in deterministic polynomial time.
The test is probabilistic, though, but as long as it works, I don't
see why that matters. However, I suspect the ANSI X9.80 or ISO 18032
paths are more promising
Ben Laurie [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
Ben Laurie [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
So Miller-Rabin is good for testing random candidates, but it is easy to
maliciously construct an n that passes several rounds of
Miller-Rabin.
Interesting! So how
Ben Laurie [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
So Miller-Rabin is good for testing random candidates, but it is easy to
maliciously construct an n that passes several rounds of
Miller-Rabin.
Interesting! So how does one go about constructing such an n?
I wonder if the
Perry E. Metzger [EMAIL PROTECTED] writes:
Guus Sliepen [EMAIL PROTECTED] writes:
In that case, I don't see why you don't bend your efforts towards
producing an open-source implementation of TLS that doesn't suck.
We don't want to program another TLS library, we want to create a VPN
Bill Stewart [EMAIL PROTECTED] writes:
* Your laptop see and uses the name yahoo.com.attackersdomain.com.
You may be able to verify this using your DNSSEC root key, if the
attackersdomain.com people have set up DNSSEC for their spoofed
entries, but unless you are using bad software or
Bill Stewart [EMAIL PROTECTED] writes:
At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Bill Stewart writes:
This looks like it has the ability to work around DNSSEC.
Somebody trying to verify that they'd correctly reached yahoo.com
would instead verify
28 matches
Mail list logo
