--
From: Kevin W. Wall kevin.w.w...@gmail.com
Subject: Re: Detecting attempts to decrypt with incorrect secret key in
OWASP ESAPI
So given these limited choices, what are the best options to the
questions I posed in my original post yesterday?
On 17/09/2009 21:42, David Wagner wrote:
Kevin W. Wall wrote:
So given these limited choices, what are the best options to the
questions I posed in my original post yesterday?
Given these choices, I'd suggest that you first encrypt with AES-CBC mode.
Then apply a message authentication code
Peter Gutmann wrote:
David Wagner d...@cs.berkeley.edu writes:
(You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)
The answer to that depends on whether you need to support an existing base of
crypto software and hardware. Even though (in this case) it's a new
Kevin W. Wall kevin.w.w...@gmail.com writes:
(Obviously some of these padding schemes such as OAEP are not suitable with
symmetric ciphers. Or at least I don't think they are.)
You'd be surprised at what JCE developers will implement just because they
can, and what therefore gets used by
On Sep 17, 2009, at 1:20 AM, Peter Gutmann wrote:
Kevin W. Wall kevin.w.w...@gmail.com writes:
(Obviously some of these padding schemes such as OAEP are not
suitable with
symmetric ciphers. Or at least I don't think they are.)
You'd be surprised at what JCE developers will implement just
Hi all,
I was referred to this site by a former colleague who thought this
is something that someone with professional cryptanalysis experience should
comment on. Also, I apologize in advance for the length of this
post (especially since it's my first one). Just trying to be thorough.
I have
Advice: if you're creating something for general-purpose use, at a minimum
make sure it provides authentication, integrity, *and* confidentiality.
A reasonable choice might be Encrypt-then-Authenticate where you first
encrypt with AES-CBC, then append a AES-CMAC message authentication
code on the
--
From: Kevin W. Wall kevin.w.w...@gmail.com
Subject: Detecting attempts to decrypt with incorrect secret key in OWASP
ESAPI
The new default for the new encryption / decryption methods is to be
128-bit AES/CBC/PKCS5Padding and use of a random
I don't exactly follow the argument for using CCM mode instead
AES-CBC encryption followed by AES-CMAC, and I'm not familiar with
the political/perception arguments (who complains about the latter?),
but whatever. It's hardly worth arguing over. The cryptographic mode
of operation is unlikely to
--
From: David Wagner d...@cs.berkeley.edu
Sent: Wednesday, September 16, 2009 5:19 PM
To: cryptography@metzdowd.com
Subject: Re: Detecting attempts to decrypt with incorrect secret key in
OWASP ESAPI
I don't exactly follow the argument for
David Wagner d...@cs.berkeley.edu writes:
(You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)
The answer to that depends on whether you need to support an existing base of
crypto software and hardware. Even though (in this case) it's a new standard,
it still requires support
11 matches
Mail list logo
