On Sun, 28 Jan 2007, Steven M. Bellovin wrote:
Beyond that, 60K doesn't make that much of a difference even with a
traditional /etc/passwd file -- it's only an average factor of 15
reduction in the attacker's workload. While that's not trivial, it's
also less than, say, a one-character
John Gilmore wrote:
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
...
For example, when making a purchase online,
Original Message
Subject: Physics News Update 810
PHYSICS NEWS UPDATE
The American Institute of Physics Bulletin of Physics News
Number 810 30 January 2007 by Phillip F. Schewe, Ben Stein, Turner
Brinton, and Davide Castelvecchi www.aip.org/pnu
[...]
| ...I agree with you about intuitive cryptography. What you're
| complaining about is, in effect, Why Johnny Can't Hash. There was
| another instance of that in today's NY Times. In one of the court
| cases stemming from the warrantless wiretapping, the Justice
| Department is, in the holy
On Tue, 30 Jan 2007 16:10:47 -0500 (EST)
Leichter, Jerry [EMAIL PROTECTED] wrote:
|
| ...There's an obvious cryptographic solution, of course: publish the
| hash of any such documents. Practically speaking, it's useless.
| Apart from having to explain hash functions to lawyers, judges,
|
| |
| | ...There's an obvious cryptographic solution, of course: publish the
| | hash of any such documents. Practically speaking, it's useless.
| | Apart from having to explain hash functions to lawyers, judges,
| | members of Congress, editorial page writers, bloggers, and talk
| | show
Victor Duchovni [EMAIL PROTECTED] writes:
What I don't understand is how the old (finally expired) root helps to
validate the new unexpired root, when a verifier has the old root and the
server presents the new root in its trust chain.
You use the key in the old root to validate the
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
What I don't understand is how the old (finally expired) root helps to
validate the new unexpired root, when a verifier has the old root and the
server presents the new root in its trust
I am not convinced that we need intuitive cryptography.
Many things in life are not understood by the general public.
How does a car really work: most people don't know but they still drive one.
How does a microwave oven work?
People don't need to understand the details, but the high level
Bill Stewart wrote:
Salt is designed to address a couple of threats
- Pre-computing password dictionaries for attacking wimpy passwords
...
Yes indeed. The rainbow-tables style attacks are important to protect
against, and a salt does the trick. This is why you can find rainbow tables
for
Travis H. wrote:
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
Victor Duchovni wrote:
On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote:
That doesn't make sense to me -- the end-of-chain (server or client)
certificate won't be signed by _both_ the old and new root,
I wouldn't
think (does x.509 even make this possible)?
Or do I
Hey, quick question.
If one wants to have multiple keys, but for ease-of-use considerations
want to only have the user enter one, is there a preferred way to
derive multiple keys that, while not independent, are computationally
independent?
I was thinking of hashing the passphrase with a unique
The social aspects of ease-of-use versus security are well-known.
People would rather use something that works than something that
is secure but hard to use. Ease-of-use trumps risks.
What is less recognized, even though it seems intuitive, is that
convenience (even though costlier and harder to
James Muir wrote:
It is my understanding that SSL is engineered to resist mitm attacks, so
I am suspicious of these claims. I wondered if someone more familiar
with SSL/TLS could comment.
Isn't in the case that the application doing SSL on the client should
detect what this proxy server is
Am Freitag, den 02.02.2007, 16:15 -0500 schrieb James Muir:
You can find more and download Odysseus here:
http://www.bindshell.net/tools/odysseus
It is my understanding that SSL is engineered to resist mitm attacks,
so
I am suspicious of these claims. I wondered if someone more
James Muir wrote:
It is my understanding that SSL is engineered to resist mitm attacks, so
I am suspicious of these claims. I wondered if someone more familiar
with SSL/TLS could comment.
Isn't in the case that the application doing SSL on the client should
detect what this proxy server is
James Muir wrote:
I was reading a hacking blog today and came across this:
http://www.darknet.org.uk/2007/02/odysseus-win32-proxy-telemachus-http-transaction-analysis/
Odysseus is a proxy server, which acts as a man-in-the-middle during
an HTTP session. A typical HTTP proxy will relay
re:
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
basically digital certificates were designed as the electronic equivalent for offline distribution of information ... paradigm left over from the letters of credit and letters of introduction out of the sailing ship days (and
[I prefer to keep discussions on-list where possible. CCing the list.]
Beryllium Sphere LLC wrote:
Bruce Schneier pointed out years ago that it's trivial for a virus
or Trojan to add a new trusted CA to the browser's list of trusted
roots. At least one advertising support web
20 matches
Mail list logo
