bear [EMAIL PROTECTED] writes:
On 30 May 2003, Eric Rescorla wrote:
Bill Stewart [EMAIL PROTECTED] writes:
(1) They use MD5 instead of HMAC for message authentication. Scary.
If MD5 itself is to be trusted as a hash function, this is not
particularly scary. They are using MD5 over
for PKCS-1) but it's a long process. However, I don't
think it's helpful to design a new system that doesn't have any
obvious advantages over one of the standard systems.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com
turn a sou or two. And you can
bet the buyer wouldn't be doing any posting. With apologies
to Bon Ami, Hasn't cracked yet is not a compelling security
story.
It's vastly better than just designed last week by someone
who has no relevant experience
-Ekr
--
[Eric Rescorla
after you've established the ssl
session. :(
This is being fixed. See draft-ietf-tls-extensions-06.txt
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com
seen 100k SSL implementations and that included the ASN.1
processing for certs. I would imagine that one could do a compliant
SSL implementation that used fixed RSA keys in roughly the same
code size as your stuff.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
tom st denis [EMAIL PROTECTED] writes:
Two weeks ago I sat down to learn how to code my own SSL lib [key
on
being small]. Suffice it to say after reading the 67 page RFC for
SSL
3.0 I have no clue
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
In other words, this is just an exercise in Not Invented Here.
Wonderful.
Oh, ok so I need your permission?
No, you don't need my permission. You can do any fool thing you
want. It would just be nice if you
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
Heck, if you could find a security flaw in LibTomNet [v0.03] I'll
buy
you a beer.
Your protocol does not use appear to have any protection against
active attacks on message sequence, including message
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
tom st denis [EMAIL PROTECTED] writes:
The point I'm trying to make is that just because a fairly standard
product exists doesn't mean diversity is a bad thing. Yes, people
may
fail to create
Ian Grigg [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
My logic is that if you're going to create something new, it should
be better than what already exists.
Right. But better is not a binary choice in real
life. SSL is only better if it exceeds all
requirements when compared
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
This is all fine, but irrelevant to my point, which is that
if you're designing a channel security protocol it should
provide channel level integrity and anti-replay unless there's
some really good reason
the deployment of same. Maybe Eric will offer me
$100 for my annotated copy just to shut me the
f**k up ;-) I've so far discovered
No payoffs, but I'd love to know what you've discovered :)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http
Ian Grigg [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Ian Grigg [EMAIL PROTECTED] writes:
I think it's pretty
inarguable that SSL is a big success.
One thing that has been on my mind lately is how
to define success of a crypto protocol. I.e.,
how to take your thoughts, and my
what I think
the implicit threat model is based on my memory of the zeitgeist
at the time and the characteristics of SSL.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com
James A. Donald [EMAIL PROTECTED] writes:
--
On 7 Sep 2003 at 9:48, Eric Rescorla wrote:
It seems to me that your issue is with the authentication
model enforced by browsers in the HTTPS context, not with SSL
proper.
To the extent that trust information is centrally handled
and TLSv1.1 are Internet Drafts.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe
) [Reverse order to prevent
replay]
Now, the attacker chooses 0 as his DH public. This makes ZZ always
equal to zero, no matter what the peer's DH key is. He can now forge
the rest of the exchange and intercept the connection.
-Ekr
--
[Eric Rescorla
Guus Sliepen [EMAIL PROTECTED] writes:
On Mon, Sep 29, 2003 at 07:53:29AM -0700, Eric Rescorla wrote:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature and ripping
off one of the many skeletons that already exist
Guus Sliepen [EMAIL PROTECTED] writes:
On Mon, Sep 29, 2003 at 09:35:56AM -0700, Eric Rescorla wrote:
Was there any technical reason why the existing cryptographic
skeletons wouldn't have been just as good?
Well all existing authentication schemes do what they are supposed do,
that's
.
This is true whether you're using signatures, encryption, or neither.
Not necessarily.
If you're using fully ephemeral DH keys and a properly designed
key, then you shouldn't need to validate the other public share.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED
the identities of the communicating peers.
Personally, I don't have much use for identity protection,
but this is the reason as I understand it.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com
that implements a stripped down subset
of SSL (e.g. self-signed certs or anonymous DH).
(4) Design your own protocol and then implement it.
Since SSL without certificates is about as simple as a stream
security protocol can be, I don't see that (4) holds much of
an advantage over (3)
-Ekr
--
[Eric
Adam Back [EMAIL PROTECTED] writes:
On Wed, Oct 01, 2003 at 08:53:39AM -0700, Eric Rescorla wrote:
there's another rationale my clients often give for
wanting a new security system [existing protcools] too heavyweight for
some applications.
I hear this a lot, but I think that Perry
Don Davis [EMAIL PROTECTED] writes:
eric wrote:
The way I see it, there are basically four options:
(1) Use OpenSSL (or whatever) as-is.
(2) Strip down your toolkit but keep using SSL.
(3) Write your own toolkit that implements a
stripped down subset of SSL (e.g. self-signed
be acceptable practice without some form of
security.
It doesn't protect against MITM.
You could, however, use a static DH key and then client could
cache it as with SSH.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com
will make things less simple.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
for a given DN/key pair.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
octets). Only when you have
a complete record in hand can you start to parse.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]
http://www.rtfm.com/
-
The Cryptography Mailing List
Folks,
Does anyone know if there is a blind signature scheme that works with
DSA or ECDSA? I know about Camenisch, Pivetau and Stadler's Blind
Signatures Based on the Discrete Logarithm Problem (1994), but as far
as I can tell that doesn't produce straight DSA-verifiable signatures
and so is a
Perry E. Metzger [EMAIL PROTECTED] writes:
The New York Times reports:
Chalabi Reportedly Told Iran That U.S. Had Code
June 2, 2004
By JAMES RISEN and DAVID JOHNSTON
Ahmad Chalabi told an Iranian official that the U.S. had
broken the communications code of Iran's intelligence
Cryptography readers who are also interested in systems security may be
interested in reading my paper from the Workshop on Economics
and Information Security '04:
Is finding security holes a good idea?
Eric Rescorla
RTFM, Inc.
A large amount of effort is expended every year
[EMAIL PROTECTED] writes:
From: Eric Rescorla [EMAIL PROTECTED]
Is finding security holes a good idea?
Paper:http://www.dtc.umn.edu/weis2004/rescorla.pdf
Slides: http://www.dtc.umn.edu/weis2004/weis-rescorla.pdf
In section 1 there's a crucial phrase not properly followed up
Ben Laurie [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Cryptography readers who are also interested in systems security may be
interested in reading my paper from the Workshop on Economics
and Information Security '04:
Is finding security holes a good idea?
Eric Rescorla
Ariel Waissbein [EMAIL PROTECTED] writes:
Roughly speaking:
If I as a White Hat find a bug and then don't tell anyone, there's no
reason to believe it will result in any intrusions. The bug has to
become known to Black Hats before it can be used to mount
intrusions. This can
Thor Lancelot Simon [EMAIL PROTECTED] writes:
On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote:
in the paper.
Roughly speaking:
If I as a White Hat find a bug and then don't tell anyone, there's no
reason to believe it will result in any intrusions. The bug has to
I don't
Jerrold Leichter [EMAIL PROTECTED] writes:
| Thor Lancelot Simon [EMAIL PROTECTED] writes:
|
| On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote:
| Roughly speaking:
| If I as a White Hat find a bug and then don't tell anyone, there's no
| reason to believe it will result
Damien Miller [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
I don't think that's clear at all. It could be purely stochastic.
I.e. you look at a section of code, you find the bug with some
probability. However, there's a lot of code and the auditing
coverage isn't very deep so bugs persist
Thor Lancelot Simon [EMAIL PROTECTED] writes:
On Tue, Jun 15, 2004 at 09:37:42PM -0700, Eric Rescorla wrote:
If you won't grant that humans experienced in a given field tend to think
in similar ways, fine. We'll just have to agree to disagree; but I think
you'll have a hard time making your
Birger Toedtmann [EMAIL PROTECTED] writes:
Am Do, den 10.06.2004 schrieb Eric Rescorla um 20:37:
Cryptography readers who are also interested in systems security may be
interested in reading my paper from the Workshop on Economics
and Information Security '04:
Is finding security holes
Perry E. Metzger [EMAIL PROTECTED] writes:
John Gilmore [EMAIL PROTECTED] writes:
It would be relatively easy to catch someone
doing this - just cross-correlate with other
information (address of home and work) and
then photograph the car at the on-ramp.
Am I missing something?
It seems
If you haven't already, you should check out the Koblitz and Menezes
paper about Provable Security on eprint:
http://eprint.iacr.org/2004/152.pdf
Here's the abstract:
We give an informal analysis and critique of several typical provable
security results. In some cases there are intuitive but
J Harper [EMAIL PROTECTED] writes:
This barely deserves mention, but is worth it for the humor:
Information Security Expert says SSL (Secure Socket Layer) is Nothing More
Than a Condom that Just Protects the Pipe
http://www.prweb.com/releases/2004/7/prweb141248.htm
What's wrong with a condom
Ben Laurie [EMAIL PROTECTED] writes:
The recent conversation on SSL where Eric Rescorla was lampooned for
saying (in effect) I've tried it on several occasions and it seemed
to work, therefore it must be trustworthy to which he responded
actually, that's a pretty reasonable way of assessing
Ian Grigg [EMAIL PROTECTED] writes:
Notwithstanding that, I would suggest that the money
already lost is in excess of the amount paid out to
Certificate Authorities for secure ecommerce certificates
(somewhere around $100 million I guess) to date. As
predicted, the CA-signed certificate
Ed Felten's blog is carrying the rumor that a break in SHA-1
is going to be announced soon:
http://www.freedom-to-tinker.com/archives/000661.html
I've also done some off-the-cuff analysis of how bad this
would be in practice, which you can find here:
I've now successfully reproduced the MD5 collision result. Basically
there are some endianness problems.
The first problem is the input vectors. They're given as hex words, but
MD5 is defined in terms of bitstrings. Because MD5 is little-endian, you
need to reverse the written byte order to
I've posted source code that demonstrates the MD5 collisions
on my web site at:
http://www.rtfm.com/md5coll.tar.gz.
It's just a modified version of the RFC1321 MD5 source code
with the byte-flipping in the state initialization. It also
includes machine readable test vectors and a makefile. Just
Does anyone know the details of the certificate generation algorithms
used by various CAs?
In particular, Verisign's is very long and I seem to remember someone telling
me it was a hach but I don't recall the details...
Thanks,
-Ekr
[EMAIL PROTECTED] writes:
-Original Message-
From: Eric Rescorla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 01, 2004 7:01 AM
To: [EMAIL PROTECTED]
Cc: Ben Nagy; [EMAIL PROTECTED]
Subject: Re: SSL/TLS passive sniffing
Ian Grigg [EMAIL PROTECTED] writes:
[...]
However
John Denker [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Uh, you've just described the ephemeral DH mode that IPsec
always uses and SSL provides.
I'm mystified by the word always there, and/or perhaps by
the definition of Perfect Forward Secrecy. Here's the dilemma:
On the one hand
James A. Donald [EMAIL PROTECTED] writes:
--
On 6 Dec 2004 at 16:14, Dan Kaminsky wrote:
* Many popular P2P networks (and innumerable distributed
content databases) use MD5 hashes as both a reliable search
handle and a mechanism to ensure file integrity. This makes
them blind to any
ANNOUNCE: PureTLS version 0.9b5
Copyright (C) 1999-2005 Claymore Systems, Inc.
http://www.rtfm.com/puretls
DESCRIPTION
PureTLS is a free Java-only implementation of the SSLv3 and TLSv1
(RFC2246) protocols. PureTLS was developed by Eric Rescorla for
Claymore Systems, Inc, but is being distributed
Stefan Lucks [EMAIL PROTECTED] writes:
Magnus Daum and myself have generated MD5-collisons for PostScript files:
http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/
This work is somewhat similar to the work from Mikle and Kaminsky, except
that our colliding files are not
Weger, B.M.M. de [EMAIL PROTECTED] writes:
Technically speaking you're correct, they're signing a program.
But most people, certainly non-techies like Alice's boss,
view postscript (or MS Word, or name your favourite document
format that allows macros) files not as programs but as static
Ian G [EMAIL PROTECTED] writes:
I'd like to take a password and expand it into
several keys. It seems like a fairly simple operation
of hashing the concatonatonation of the password
with each key name in turn to get each key.
Are there any 'gotchas' with that?
iang
PS: some psuedo code
There's an interesting paper up on eprint now:
http://eprint.iacr.org/2005/205
Another look at HMQV
Alfred Menezes
HMQV is a `hashed variant' of the MQV key agreement protocol. It
was recently introduced by Krawczyk, who claimed that HMQV has
very
Ian G [EMAIL PROTECTED] writes:
Trei, Peter wrote:
Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.
Perfectly acceptable over chat, no? That
Dave Howe [EMAIL PROTECTED] writes:
Ian G wrote:
none of the above. Using SSL is the wrong tool
for the job.
For the one task mentioned - transmitting the username/password pair
to the server - TLS is completely appropriate. However, hash based
verification would seem to be more secure,
Will Morton [EMAIL PROTECTED] writes:
I am designing a transport-layer encryption protocol, and obviously wish
to use as much existing knowledge as possible, in particular TLS, which
AFAICT seems to be the state of the art.
In TLS/SSL, the client and the server negotiate a 'master secret'
Ben Laurie [EMAIL PROTECTED] writes:
Ian G wrote:
Ben Laurie wrote:
...
Hopefully over the next year, the webserver (Apache)
will be capable of doing the TLS extension for sharing
certs so then it will be reasonable to upgrade.
In fact, I'm told (I'll dig up the reference) that there's
Hey boys and girls! Want to help your country defeat that mean old
Osama? Then check out the National Security Agency's CryptoKids web site
(http://www.nsa.gov/kids/):
On this site, you can learn all about codes and ciphers, play lots
of games and activities, and get to know each of us -
Travis H. [EMAIL PROTECTED] writes:
That leaves me with the following design:
That random numbers be sent en clair from the system that can generate
them to the system that needs them, where they are decrypted using a
random key (generated locally by /dev/random) and fed into the system
that
Travis H. [EMAIL PROTECTED] writes:
On 2/4/06, Eric Rescorla [EMAIL PROTECTED] wrote:
Look, this design just reduces to a standard cryptographic PRNG with
some of the seed being random and periodically being reseeded by the
random network stream you're sending around. There's no need
Travis H. [EMAIL PROTECTED] writes:
On 2/24/06, Alex Pankratov [EMAIL PROTECTED] wrote:
Tero Kivinen wrote:
Secondly I cannot find where it
authenticates the crypto suite used at all (it is not included in the
signature of the AUTH message).
Crypto suite is essentially just a protocol
Travis H. [EMAIL PROTECTED] writes:
On 5/14/06, Victor Duchovni [EMAIL PROTECTED] wrote:
Security is fragile. Deviating from well understood primitives may be
good research, but is not good engineering. Especially fragile are:
Point taken. This is not for a production system, it's a
Ryan Singel reports that despite the rather lax standards required for
wiretaps, some FBI agents seem to have decided that they could skip
procedure:
The revelation is the second this year showing that FBI employees
bypassed court order requirements for phone records. In July, the
FBI
At Wed, 30 Jan 2008 09:04:37 +1000,
James A. Donald wrote:
Ivan Krstic' wrote:
Some number of these muppets approached me over the
last couple of years offering to donate a free license
for their excellent products. I used to be more polite
about it, but nowadays I ask that they
At Wed, 30 Jan 2008 17:59:51 -,
Dave Korn wrote:
On 30 January 2008 17:03, Eric Rescorla wrote:
We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.
TCP could need some stronger integrity protection. 8
At Thu, 31 Jan 2008 03:04:00 +0100,
Philipp Gühring wrote:
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept
At Fri, 01 Feb 2008 18:42:03 +1000,
James A. Donald wrote:
Guus Sliepen wrote:
Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
At Sun, 03 Feb 2008 12:51:25 +1000,
James A. Donald wrote:
--
Ivan Krstic' wrote:
The wider point of Peter's writeup -- and of the
therapy -- is that developers working on security
tools should _know_ they're working in a notoriously,
infamously hard field where the odds are
At Mon, 4 Feb 2008 09:33:37 -0500 (EST),
Leichter, Jerry wrote:
Commenting on just one portion:
| 2. VoIP over DTLS
| As Perry indicated in another message, you can certainly run VoIP
| over DTLS, which removes the buffering and retransmit issues
| James is alluding to. Similarly, you
At Mon, 04 Feb 2008 14:29:50 +1000,
James A. Donald wrote:
James A. Donald wrote:
I have figured out a solution, which I may post here
if you are interested.
Ian G wrote:
I'm interested. FTR, zooko and I worked on part of
the problem, documented briefly here:
At Thu, 7 Feb 2008 10:34:42 -0500 (EST),
Leichter, Jerry wrote:
| Since (by definition) you don't have a copy of the packet you've lost,
| you need a MAC that survives that--and is still compact. This makes
| life rather more complicated. I'm not up on the most recent lossy
| MACing
At Thu, 7 Feb 2008 14:42:36 -0500 (EST),
Leichter, Jerry wrote:
| Obviously, if you *really* use every k'th packet to define what is in
| fact a substream, an attacker can arrange to knock out the substream he
| has chosen to attack. So you use your encryptor to permute the
| substreams,
At Sun, 04 May 2008 20:14:42 -0400,
Perry E. Metzger wrote:
Marcos el Ruptor [EMAIL PROTECTED] writes:
All this open-source promotion is a huge waste of time. Us crackers
know exactly how all the executables we care about (especially all
the crypto and security related programs) work.
At Wed, 14 May 2008 19:52:58 -0400,
Steven M. Bellovin wrote:
Given the published list of bad ssh keys due to the Debian mistake (see
http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be
updated to contain a blacklist of those keys? I suspect that a Bloom
filter would be
At Fri, 27 Jun 2008 07:52:59 -0700 (PDT),
Erik Ostermueller wrote:
If I exchange messages with a system and the messages are encrypted
with a symmetric key, what further benefit would we get by using a
MAC (Message Authentication Code) along with the message encryption?
Being new to all this,
At Thu, 10 Jul 2008 18:10:27 +0200,
Eugen Leitl wrote:
In case somebody missed it,
http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE)
I'm not sure what the status of http://postel.org/anonsec/
is, the mailing list traffic dried up a while back.
This is the first I
At Tue, 15 Jul 2008 18:33:10 -0400 (EDT),
Leichter, Jerry wrote:
For an interesting discussion of IPETEE, see:
www.educatedguesswork.org/moveabletype/archives/2008/07/ipetee.html
Brief summary: This is an initial discussion - the results of a
drinking session - that got leaked as an
At Wed, 23 Jul 2008 17:32:02 -0500,
Thierry Moreau wrote:
Anne Lynn Wheeler wrote about various flavors of certificateless
public key operation in various standards, notably in the financial
industry.
Thanks for reporting those.
No doubt that certificateless public key operation
At Fri, 8 Aug 2008 11:50:59 +0100,
Ben Laurie wrote:
However, since the CRLs will almost certainly not be checked, this
means the site will still be vulnerable to attack for the lifetime of
the certificate (and perhaps beyond, depending on user
behaviour). Note that shutting down the site DOES
At Fri, 8 Aug 2008 17:31:15 +0100,
Dave Korn wrote:
Eric Rescorla wrote on 08 August 2008 16:06:
At Fri, 8 Aug 2008 11:50:59 +0100,
Ben Laurie wrote:
However, since the CRLs will almost certainly not be checked, this
means the site will still be vulnerable to attack for the lifetime
At Fri, 08 Aug 2008 10:43:53 -0700,
Dan Kaminsky wrote:
Eric Rescorla wrote:
It's easy to compute all the public keys that will be generated
by the broken PRNG. The clients could embed that list and refuse
to accept any certificate containing one of them. So, this
is distinct from CRLs
At Fri, 8 Aug 2008 15:52:07 -0400 (EDT),
Leichter, Jerry wrote:
| Funnily enough I was just working on this -- and found that we'd
| end up adding a couple megabytes to every browser. #DEFINE
| NONSTARTER. I am curious about the feasibility of a large bloom
| filter that fails back
At Tue, 19 Aug 2008 20:57:33 -0700,
Alex Pankratov wrote:
CC'ing cryptography mail list as it may be of some interest to the
folks over there.
-Original Message-
From: [EMAIL PROTECTED] [mailto:p2p-hackers-
[EMAIL PROTECTED] On Behalf Of Lars Eggert
Sent: August 19, 2008
Some colleagues (Hovav Shacham, Brandon Enright, Scott Yikel, and
Stefan Savage) and I have been doing some followup work on the Debian
OpenSSL PRNG bug. Perry suggested that some cryptography readers
might be interested in our preliminary analysis of the DHE angle,
which can be found here:
At Wed, 27 Aug 2008 17:05:44 +0200,
Philipp Gühring wrote:
Hi,
I am searching for symmetric encryption algorithms for decimal strings.
Let's say we have various 40-digit decimal numbers:
2349823966232362361233845734628834823823
3250920019325023523623692235235728239462
At Wed, 27 Aug 2008 16:10:51 -0400 (EDT),
Jonathan Katz wrote:
On Wed, 27 Aug 2008, Eric Rescorla wrote:
At Wed, 27 Aug 2008 17:05:44 +0200,
There are a set of techniques that allow you to encrypt elements of
arbitrary sets back onto that set.
The original paper on this is:
John
At Thu, 28 Aug 2008 17:32:10 +1200,
Peter Gutmann wrote:
Eric Rescorla [EMAIL PROTECTED] writes:
There are a set of techniques that allow you to encrypt elements of arbitrary
sets back onto that set.
... and most of them seem to be excessively complicated for what they end up
achieving
At Mon, 1 Sep 2008 21:00:55 +0100,
Ben Laurie wrote:
The core issue is that HTTPS is used to establish end-to-end security,
meaning, in particular, authentication and secrecy. If the MitM can
disable the upgrade to HTTPS then he defeats this aim. The fact that
the server declines to serve an
At Mon, 1 Sep 2008 21:56:52 +0100,
Ben Laurie wrote:
On Mon, Sep 1, 2008 at 9:49 PM, Eric Rescorla [EMAIL PROTECTED] wrote:
At Mon, 1 Sep 2008 21:00:55 +0100,
Ben Laurie wrote:
The core issue is that HTTPS is used to establish end-to-end security,
meaning, in particular, authentication
At Sat, 20 Sep 2008 15:55:12 -0400,
Steven M. Bellovin wrote:
On Thu, 18 Sep 2008 17:18:00 +1200
[EMAIL PROTECTED] (Peter Gutmann) wrote:
- Use TLS-PSK, which performs mutual auth of client and server
without ever communicating the password. This vastly complicated
phishing since the
At Tue, 20 Jan 2009 17:57:09 +1300,
Peter Gutmann wrote:
Steven M. Bellovin s...@cs.columbia.edu writes:
So -- who supports TLS 1.2?
Not a lot, I think. The problem with 1.2 is that it introduces a pile of
totally gratuitous incompatible changes to the protocol that require quite a
bit
At Sat, 24 Jan 2009 14:55:15 +1300,
Peter Gutmann wrote:
Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those
between SSL and TLS. I'm not particularly happy about that either, but it's
what we felt was necessary to do a principled job.
It may have been a nicely principled
McDonald, Hawkes and Pieprzyk claim that they have reduced the collision
strength of SHA-1 to 2^{52}.
Slides here:
http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf
Thanks to Paul Hoffman for pointing me to this.
-Ekr
At Sat, 02 May 2009 21:53:40 +1200,
Peter Gutmann wrote:
Perry E. Metzger pe...@piermont.com writes:
Greg Rose g...@qualcomm.com writes:
It already wasn't theoretical... if you know what I mean. The writing
has been on the wall since Wang's attacks four years ago.
Sure, but this should
At Sat, 2 May 2009 15:00:36 -0400,
Matt Blaze wrote:
The serious concern here seems to me not to be that this particular
weakness is a last straw wedge that enables some practical attack
against some particular protocol -- maybe it is and maybe it isn't.
What worries me is that SHA-1 has been
At Tue, 10 Nov 2009 20:11:50 -0500,
d...@geer.org wrote:
|
| This is the first attack against TLS that I consider to be
| the real deal. To really fix it is going to require a change to
| all affected clients and servers. Fortunately, Eric Rescorla
| has a protocol extension
100 matches
Mail list logo
