On Tue, Jun 21, 2005 at 10:38:42PM -0400, Perry E. Metzger wrote:
Jerrold Leichter [EMAIL PROTECTED] writes:
Usage in first of these may be subject to Bernstein's attack. It's much
harder to see how one could attack a session key in a properly implemented
system the same way. You
At 02:44 AM 6/20/2005, Peter Gutmann wrote:
Stephan Neuhaus [EMAIL PROTECTED] writes:
Concerning the practical use of AES, you may be right (even though it would
be nice to have some advice on what one *should* do instead).
Would switching to triple-AES (or double-AES) or something help?
Yeah,
Jerrold Leichter [EMAIL PROTECTED] writes:
Usage in first of these may be subject to Bernstein's attack. It's much
harder to see how one could attack a session key in a properly implemented
system the same way. You would have to inject a message into the ongoing
session.
I gave an
| It's much harder to see how one could attack a session key in a properly
| implemented system the same way. You would have to inject a message into
| the ongoing session. However, if the protocol authenticates its messages,
| you'll never get any response to an injected message. At best,
Ian G [EMAIL PROTECTED] writes:
Definitely. Maybe time for a BCP, not just for AES but for general block
ciphers?
What is a BCP? Best Coding Practices? Block Cipher Protocol?
Best Current Practice, a special-case type of RFC. Based on recent experience
with this style of collaborative
Ian G [EMAIL PROTECTED] writes:
On Tuesday 21 June 2005 13:45, Peter Gutmann wrote:
Best Current Practice, a special-case type of RFC. Based on recent experience
with this style of collaborative document editing, I've set up a wiki at
http://blockcipher.pbwiki.com/, blank username, password
| Uhh, that wasn't really what I was after, that's pretty much textbook stuff,
| what I wanted was specifically advice on how to use block ciphers in a way
| that avoids possibilities for side-channel (and similar) attacks. I have some
| initial notes that can be summarised as Don't let yourself
Ian Grigg [EMAIL PROTECTED] writes:
Alternatively, if one is in the unfortunate position of being an oracle for a
single block encryption then the packet could be augmented with a cleartext
random block to be xor'd with the key each request.
Moves you from being an encryption oracle to a
http://cr.yp.to/talks.html#2005.06.01 has slides that people might find
useful as an overview of what's going on. In particular, there's a list
of six obstacles to performing array lookups in constant time. People
who mention just one of the obstacles are oversimplifying the problem.
Hal Finney
[EMAIL PROTECTED] (Peter Gutmann) writes:
[EMAIL PROTECTED] (Hal Finney) writes:
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack.
It is? Recovering a key from a
Peter Gutmann wrote:
Stephan Neuhaus [EMAIL PROTECTED] writes:
Concerning the practical use of AES, you may be right (even though it would
be nice to have some advice on what one *should* do instead).
Definitely. Maybe time for a BCP, not just for AES but for general block
ciphers?
I
Stephan Neuhaus [EMAIL PROTECTED] writes:
Concerning the practical use of AES, you may be right (even though it would
be nice to have some advice on what one *should* do instead).
Definitely. Maybe time for a BCP, not just for AES but for general block
ciphers?
But as far as I know, resistance
On Mon, Jun 20, 2005 at 01:54:46AM -, D. J. Bernstein wrote:
One can carry out the final search with nothing more than known
ciphertext: try decrypting the ciphertext with each key and see which
result looks most plausible. It should even be possible to carry out a
timing attack with
[EMAIL PROTECTED] (Hal Finney) writes:
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack.
It is? Recovering a key from a server custom-written to act as an oracle for
the
On Fri, Jun 17, 2005 at 11:57:29PM +1200, Peter Gutmann wrote:
[EMAIL PROTECTED] (Hal Finney) writes:
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack.
It is?
Peter Gutman writes:
[EMAIL PROTECTED] (Hal Finney) writes:
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack.
It is? Recovering a key from a server custom-written
Hal Finney wrote:
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack. Bernstein was actually able to recover
the AES key using a somewhat artificial server which reported
Steven M. Bellovin writes:
Dan Bernstein has a new cache timing attack on AES:
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack. Bernstein was actually able to recover
the AES key using a somewhat artificial server which reported its own
timing to do
18 matches
Mail list logo