Victor Duchovni [EMAIL PROTECTED] writes:
Wouldn't the old root also (until it actually expires) verify any
certificates signed by the new root? If so, why does a server need to send
the new root?
Because the client may not have the new root yet, and when they try and verify
using the expired
Matt Blaze wrote:
an even more important problem
than psychic debunking, namely electronic voting. I think intuitive
cryptography is a very important open problem for our field.
The first problem of voting is that neither side (paper vote vs e-vote)
accepts that voting is hard to do right --
* Perry E. Metzger:
If you go over to, say, www.fidelity.com, you will find that you can't
even get to the http: version of the page any more -- you are always
redirected to the https: version.
Of course, this only helps if users visit the site using bookmarks
that were created after the
[Perry, please use this one if possible]
Matt Blaze wrote:
an even more important problem
than psychic debunking, namely electronic voting. I think intuitive
cryptography is a very important open problem for our field.
Matt,
You mentioned in your blog about the crypto solutions for voting
http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html
IBM donates new privacy tool to open-source
By Joris Evers
Staff Writer, CNET News.com
Published: January 25, 2007, 9:00 PM PST
IBM has developed software designed to let people keep personal
On Wed, Jan 24, 2007 at 03:28:50PM -0800, Allen wrote:
If 4 gigs is right, would it then be records to look for to break
the code via birthday attacks would be things like seismic data,
In case anyone else couldn't parse this, he means the amount of
encrypted material necessary to break the
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
Wouldn't the old root also (until it actually expires) verify any
certificates signed by the new root? If so, why does a server need to send
the new root?
Because the client may not
On Mon, 22 Jan 2007 16:57:34 -0800
Abe Singer [EMAIL PROTECTED] wrote:
On Sun, Jan 21, 2007 at 12:13:09AM -0500, Steven M. Bellovin wrote:
One sometimes sees claims that increasing the salt size is
important. That's very far from clear to me. A collision in the
salt between two entries
On Fri, Jan 26, 2007 at 11:42:58AM -0500, Victor Duchovni wrote:
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
In some cases it may be useful to send the entire chain, one such being
when a
CA re-issues its root with a new expiry date, as Verisign did when its roots
On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote:
Wouldn't the old root also (until it actually expires) verify any
certificates signed by the new root? If so, why does a server need to
send the new root? So long as the recipient has either the new or the
old root, the
So I was reading this:
http://en.wikipedia.org/wiki/Merkle-Damgard
It seems to me the length-extension attack (given one collision, it's
easy to create others) is not the only one, though it's obviously a
big concern to those who rely on it.
This attack thanks to Schneier:
If the ideal hash
On Sun, Jan 28, 2007 at 11:52:16AM -0500, Steven M. Bellovin wrote:
Is that all in one /etc/passwd file (or the NIS equivalent)? Or is it a
Kerberos KDC? I note that a salt buys the defense much less in a
For SDSC, one file. For UCSD, not sure, but I suspect it's (now) a KDC.
(Brian, are
12 matches
Mail list logo
