Vin McLellan <[EMAIL PROTECTED]> writes:
> 4. Is this an issue for the client or the server? Normally, this would
> only be an issue for the "server" (i.e., the party that receives the
> connection request), since normal SSL clients don't automatically
> large numbers of connections.
It's worth not
Eric, thanks for putting together such a great description -- it was
helpful to see the novel observations of this attack compared to
Vaudenay's original paper from Eurocrypt '02.
For those who may not be aware, I wanted to point out that there is also
a very nice paper by John Black and Hector
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> I'm struck by the similarity of this attack to Matt Blaze's master key
> paper. In each case, you're guessing at one position at a time, and
> using the response of the security system as an oracle. What's crucial
> in both cases is the one-a
If I'm not mistaken, the OpenSSL spec says that you should
MAC the (compressed) message, and then encrypt the message
and the MAC.
This composition is not generically secure, on the other hand you
can prove some nice things about the composition encrypt-then-
MAC assuming certain conditions, see fo
On Fri, Feb 21, 2003 at 06:31:20AM -0800, Ed Gerck wrote:
> Shannon proved that if
> "n" (bits, bytes, letters, etc.) is the unicity distance of a ciphersystem,
> then ANY message that is larger than "n" bits CAN be uniquely deciphered
> from an analysis of its ciphertext
[...]
> Conversely, Shann
>From Wired News --
http://www.wired.com/news/infostructure/0,1377,57753,00.html?tw=wn_ascii
Hackers Run Wild and Free on AOL
By Christopher Null
Using a combination of trade tricks and clever programming, hackers have
thoroughly compromised security at America Online, potentially exposing
the pe
I have a question about RC4. Assume key k1 and k2 are 128 bits and let
E(k, m) denote the RC4 encryption of m by k, is there a key, k3, of RC4
satisfying that E(k2, E(k1, m)) = E(k3, m) and if yes, how can we find
such k3?
Thanks,
Steve
--
The idea is also similar to timing attacks against very, very
badly-implemented password checking schemes; e.g. where a reply by some
verifying server to a correct guess on the first n characters of a
password takes slightly longer than a reply to a correct guess on only
the initial n-1 characters
