I don't believe MtE is good advice, and I have yet to see a decent reason
why one would want to use that instead of EtM.
Of course when we talk about EtM, the MAC should be applied over all
plaintext headers and trailers (including IV used for encryption, algorithm
identifier, protocol version, wh
On 2/13/06, Peter Gutmann <[EMAIL PROTECTED]> wrote:
> >I would expect that typically implementors would be following a published
> >standard, which would (well, one would hope) have had expert cryptographers
> >check it over sometime prior to publication
Published implementations aren't immune to
On Tue, Feb 14, 2006 at 03:24:09AM +1300, Peter Gutmann wrote:
> 1. There are a great many special-case situations where no published protocol
>fits. As the author of a crypto toolkit, I could give you a list as long
>as your arm of user situations where no existing protocol can be applie
Jack Lloyd <[EMAIL PROTECTED]> writes:
>On Fri, Feb 10, 2006 at 07:21:05PM +1300, Peter Gutmann wrote:
>> Well, that's the exact problem that I pointed out in my previous message - in
>> order to get this right, people have to read the mind of the paper author to
>> divine their intent. Since the
Paul Hoffman wrote:
> At 5:40 PM + 2/12/06, Ben Laurie wrote:
>> It also defends against the MD5 crack, and is one of the recommended
>> IETF solutions to hash problems.
>
> s/recommended/proposed/
>
> The IETF has not recommended any "solutions to hash problems". The sense
> of the room at t
At 5:40 PM + 2/12/06, Ben Laurie wrote:
It also defends against the MD5 crack, and is one of the recommended
IETF solutions to hash problems.
s/recommended/proposed/
The IETF has not recommended any "solutions to hash problems". The
sense of the room at the Hash BOF and the SAAG discussio
Travis H. wrote:
> On 2/8/06, Jack Lloyd <[EMAIL PROTECTED]> wrote:
>> An obvious example occurs when using a
>> deterministic authentication scheme like HMAC - an attacker can with high
>> probability detect duplicate plaintexts by looking for identical tags.
>
> I think though that the solution
On Fri, Feb 10, 2006 at 07:21:05PM +1300, Peter Gutmann wrote:
> Well, that's the exact problem that I pointed out in my previous message - in
> order to get this right, people have to read the mind of the paper author to
> divine their intent. Since the consumers of the material in the paper
> g
On 2/8/06, Jack Lloyd <[EMAIL PROTECTED]> wrote:
> An obvious example occurs when using a
> deterministic authentication scheme like HMAC - an attacker can with high
> probability detect duplicate plaintexts by looking for identical tags.
I think though that the solution is fairly simple; prepend
Jack Lloyd <[EMAIL PROTECTED]> writes:
>On Thu, Feb 09, 2006 at 05:01:05PM +1300, Peter Gutmann wrote:
>> So you can use encrypt-then-MAC, but you'd better be *very*
>> careful how you apply it, and MAC at least some of the additional
>> non-message-
>> data components as well.
>
>Looking at the d
> Don't forget Bleichenbacher's error channel attack on SSL
> implementations, which focussed on the mac then encrypt design of
> SSL... web servers gave different error for malformed padding vs
> plaintext MAC failure. The lesson I drew from that is the
> conservative choice is encrypt then MAC.
Don't forget Bleichenbacher's error channel attack on SSL
implementations, which focussed on the mac then encrypt design of
SSL... web servers gave different error for malformed padding vs
plaintext MAC failure. The lesson I drew from that is the
conservative choice is encrypt then MAC.
I dont th
On Thu, Feb 09, 2006 at 05:01:05PM +1300, Peter Gutmann wrote:
> So you can use encrypt-then-MAC, but you'd better be *very*
> careful how you apply it, and MAC at least some of the additional non-message-
> data components as well.
Looking at the definitions in the paper, I think it is pretty cl
Sidney Markowitz <[EMAIL PROTECTED]> writes:
>Krawczyk's paper shows that authenticate before encryption is not secure
>under assumptions that are not realistic, such as the encryption being
>subject to a chosen ciphertext attack, use of ECB mode, separate MAC
>authentication of each block along wi
Jack Lloyd <[EMAIL PROTECTED]> writes:
>Bellare and Namprempre have a paper on this [worth reading IMO;
>http://www-cse.ucsd.edu/~mihir/papers/oem.html] which suggests that this
>method (which they term Encrypt-and-MAC) has problems in terms of information
>leakage. An obvious example occurs when u
Simon Josefsson wrote:
> "Travis H." <[EMAIL PROTECTED]> writes:
> ...
>> 3) Authenticate the plaintext, not the ciphertext. This is a general
[...]
> I wonder whether this is really a good suggestion, considering
> Krawczyk's paper that show that this construct is not generically
> secure. See <
"Travis H." <[EMAIL PROTECTED]> writes:
> Hey,
>
> In "Practical Cryptography", Schneier mentions a couple of general
> principles that he thinks wise when writing code which uses or
> implements cryptographic routines.
...
> 3) Authenticate the plaintext, not the ciphertext. This is a general
>
On Sun, Feb 05, 2006 at 05:15:08AM -0600, Travis H. wrote:
> 3) Authenticate the plaintext, not the ciphertext. This is a general
> application of the rule "use semantically appropriate constructs".
> That is, our point in signing is to authenticate the plaintext, not an
> encrypted version of i
Hey,
In "Practical Cryptography", Schneier mentions a couple of general
principles that he thinks wise when writing code which uses or
implements cryptographic routines.
Bear with me as I try to remember them:
1) When using a user input, run it through a OWF first. NB: This is a
possible DoS ve
19 matches
Mail list logo
