Re: More info in my AES128-CBC question

2007-04-24 Thread Nicolas Williams
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
 No, there will be message integrity. For those of you asking, here's  
 a high level overview of the protocol is as follows:

 [...]

 3) Data needing confidentiality is encrypted with the SK in the mode  
 selected in step 1. The message is integrity protected with MK. A new  
 MK is generated after a message is sent using MK(i+1) = H[MK(i)]

You don't necessarily have to change the integrity protection key for
every message.  One thing this says is that the protocol involves an
ordered stream of messages.

 Hope this clarifies things somewhat.

It does.  You can get by without a random IV by using CBC analogously to
how you use counter modes and cipher streams in general.  The key thing
is to avoid key and IV/counter re-use.  For a protocol where ordered
delivery of messages is expected/ required this is easy to achieve.

Derive the key and/or counter/IV from a message sequence number and do
it in such a way that you either cannot repeat them or are very, very
unlikely to repeat them and you're fine.

But be careful.  Simply chaining the IV from message to message will
create problems (see SSH).

What is the concern with using random IVs/confounders anyways?  The need
for an entropy source?  If so keep in mind that a PRNG will be
sufficient for generating the IVs/confounders and that you'll generally
need some source of entropy for at least some protocol elements (e.g.,
nonces).

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-24 Thread Aram Perez

Hi Nico,

On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:


On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:

No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:



[...]



3) Data needing confidentiality is encrypted with the SK in the mode
selected in step 1. The message is integrity protected with MK. A new
MK is generated after a message is sent using MK(i+1) = H[MK(i)]


You don't necessarily have to change the integrity protection key for
every message.  One thing this says is that the protocol involves an
ordered stream of messages.


You need to change the integrity key if you want to prevent replay  
attacks.


No, the message do not have to be ordered in any fashion. And in  
fact, an attacker would not send the messages in the correct order.





Hope this clarifies things somewhat.


It does.  You can get by without a random IV by using CBC  
analogously to
how you use counter modes and cipher streams in general.  The key  
thing

is to avoid key and IV/counter re-use.  For a protocol where ordered
delivery of messages is expected/ required this is easy to achieve.

Derive the key and/or counter/IV from a message sequence number and do
it in such a way that you either cannot repeat them or are very, very
unlikely to repeat them and you're fine.

But be careful.  Simply chaining the IV from message to message will
create problems (see SSH).


The intention would be a new IV with each message begin sent.

What is the concern with using random IVs/confounders anyways?  The  
need

for an entropy source?  If so keep in mind that a PRNG will be
sufficient for generating the IVs/confounders and that you'll  
generally

need some source of entropy for at least some protocol elements (e.g.,
nonces).


The concern was that that's the way SD cards do it today. Another  
response was you haven't heard of anyone breaking SD cards have you?


Thanks,
Aram


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-24 Thread Leichter, Jerry
Some of the messages in this stream have demonstrated why it can be
difficult to get non-crypto people to listen to advice from crypto
experts:  Cryptography research is, by its nature, a pretty absolute
thing.  We find attacks, we try to eliminate them.  There's a strong
tendency to view *any* attack as significant, so *any* use of a
technique known to be weak is frowned on.

However, the issue isn't cryptography, it's security; and security
is a cost/benefit tradeoff.  Some of the other messages in this
thread have already made that point, by looking at some of the
specific tradeoffs that have to be made (usability, efficiency,
time to market, etc.)  However, in this particular case, one can
even analyze the threat quite directly.

Suppose we use AES128-CBC with a fixed IV.  It's clear that the only
vulnerability of concern occurs when a key is reused.  OK, where do
the keys come from?  We're told that they are session keys.  Assuming
that these are generated *correctly* - they are effectively random
independent variables - then you'd need to see 2^64 sessions to get
a 50% chance of a repeated key.  Note:  Note 2^64 *blocks* - something
you might actually get in a reasonable amount of time on the fastest
links - but 2^64 *sessions*.  Is that within the realm of interest
for this protocol?  Maybe, maybe not.  (Most likely not.)

A decent protocol will have authentication and some kind of anti-replay
mechanism.  Even if someone gets hold of two sessions that used the
same key, the authentication mechanism will block attempts to
merge data from the two sessions.  Alternatively, any anti-replay
mechanism will require carrying a nonce of some sort in the stream.
Realistically, this will be sent very early in the session, pretty
much ensuring that even with common keys and a common IV, there will
be little common data.  In fact, a practical recommendation might be
to put the nonce in the first block, in which case it ends up playing
the role of an IV and the whole discussion disappears.

In summary:  Yes, ideally one uses a random IV.  In practice, what this
adds - in many common protocol styles - is robustness of a sort, not
real additional security.  (However, actual robustness of cryptosystems -
robustness against all the common kinds of errors that people make in
design, implementation, fielding, and use - doesn't appear to be within
reach of current techniques.)  If possible, it's certainly better to use
the best practices known - and random or nonce IV's are among those - 
but getting defensive about how no one is listening to the crypto
experts is not appropriate here.  Save that for the really egregious
mistakes - of which there are plenty.
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: More info in my AES128-CBC question

2007-04-24 Thread Geoffrey Hird
Leichter, Jerry wrote:

 Suppose we use AES128-CBC with a fixed IV.  It's clear that the only
 vulnerability of concern occurs when a key is reused.  OK, where do

No, remember that if the IV is in the clear, an attacker can
make some controlled bit changes in the first plaintext block.
(There has been no assumption of integrity enforcement.)

I wonder how Adam Perez is communicating the IV.

gh

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry
 Sent: Monday, April 23, 2007 11:41 AM
 To: cryptography@metzdowd.com
 Subject: Re: More info in my AES128-CBC question
 
 Some of the messages in this stream have demonstrated why it can be
 difficult to get non-crypto people to listen to advice from crypto
 experts:  Cryptography research is, by its nature, a pretty absolute
 thing.  We find attacks, we try to eliminate them.  There's a strong
 tendency to view *any* attack as significant, so *any* use of a
 technique known to be weak is frowned on.
 
 However, the issue isn't cryptography, it's security; and security
 is a cost/benefit tradeoff.  Some of the other messages in this
 thread have already made that point, by looking at some of the
 specific tradeoffs that have to be made (usability, efficiency,
 time to market, etc.)  However, in this particular case, one can
 even analyze the threat quite directly.
 
 Suppose we use AES128-CBC with a fixed IV.  It's clear that the only
 vulnerability of concern occurs when a key is reused.  OK, where do
 the keys come from?  We're told that they are session keys.  Assuming
 that these are generated *correctly* - they are effectively random
 independent variables - then you'd need to see 2^64 sessions to get
 a 50% chance of a repeated key.  Note:  Note 2^64 *blocks* - something
 you might actually get in a reasonable amount of time on the fastest
 links - but 2^64 *sessions*.  Is that within the realm of interest
 for this protocol?  Maybe, maybe not.  (Most likely not.)
 
 A decent protocol will have authentication and some kind of 
 anti-replay
 mechanism.  Even if someone gets hold of two sessions that used the
 same key, the authentication mechanism will block attempts to
 merge data from the two sessions.  Alternatively, any anti-replay
 mechanism will require carrying a nonce of some sort in the stream.
 Realistically, this will be sent very early in the session, pretty
 much ensuring that even with common keys and a common IV, there will
 be little common data.  In fact, a practical recommendation might be
 to put the nonce in the first block, in which case it ends up playing
 the role of an IV and the whole discussion disappears.
 
 In summary:  Yes, ideally one uses a random IV.  In practice, 
 what this
 adds - in many common protocol styles - is robustness of a sort, not
 real additional security.  (However, actual robustness of 
 cryptosystems -
 robustness against all the common kinds of errors that people make in
 design, implementation, fielding, and use - doesn't appear to 
 be within
 reach of current techniques.)  If possible, it's certainly 
 better to use
 the best practices known - and random or nonce IV's are among those - 
 but getting defensive about how no one is listening to the crypto
 experts is not appropriate here.  Save that for the really egregious
 mistakes - of which there are plenty.
   -- Jerry
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to 
 [EMAIL PROTECTED]
 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-24 Thread Nicolas Williams
On Mon, Apr 23, 2007 at 11:23:54AM -0700, Aram Perez wrote:
 On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:
 On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
 No, there will be message integrity. For those of you asking, here's
 a high level overview of the protocol is as follows:
 
 [...]
 
 3) Data needing confidentiality is encrypted with the SK in the mode
 selected in step 1. The message is integrity protected with MK. A new
 MK is generated after a message is sent using MK(i+1) = H[MK(i)]
 
 You don't necessarily have to change the integrity protection key for
 every message.  One thing this says is that the protocol involves an
 ordered stream of messages.
 
 You need to change the integrity key if you want to prevent replay  
 attacks.

Or construct your MAC so that there is a sequence number in it.

E.g., SSHv2 uses HMAC without changing the integrity key.

If deriving a new key is slower than adding a sequence number into the
input of HMAC (which it most likely is) then you're likely to prefer the
latter.

If there isn't a good reason for rejecting what I suggest then one might
worry that changing the integrity key on every message (but not the
confidentiality key?) is something that a non-expert might do and that
there may be other problems with this protocol.  Much experience has
been gained with other protocols in these areas; do leverage it.

 But be careful.  Simply chaining the IV from message to message will
 create problems (see SSH).
 
 The intention would be a new IV with each message begin sent.

As long as it doesn't repeat.  Also, if it's not random then make that
IV the first block of plaintext (with a fixed IV) -- that is, use a
confounder, and make sure it doesn't repeat.

 What is the concern with using random IVs/confounders anyways?  The
 need for an entropy source?  If so keep in mind that a PRNG will be
 sufficient for generating the IVs/confounders and that you'll
 generally need some source of entropy for at least some protocol
 elements (e.g., nonces).
 
 The concern was that that's the way SD cards do it today. Another  
 response was you haven't heard of anyone breaking SD cards have you?

Fallacious responses, those.

A legitimate response w.r.t. confounders might be but that wastes a
cipher block's worth of bits on the wire, which it certainly does, and
if you're really hard pressed for bandwidth and use mostly small
messages then you'd mind the confounder.  But I see no reason not to use
a random or pseudo-random IV -- a device that can do crypto can and
should have a decent PRNG (and a true, if low-bandwidth RNG to seed it).

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Training your customers to be phishing victims, part umpteen.

2007-04-24 Thread Perry E. Metzger

The following is a real email, with minor details removed, in which
J.P. Morgan Chase works hard to train its customers to become phishing
victims.

I've left in the name that the email was sent under -- I see no reason
to protect the guilty. The original version of the email was multipart
alternative, with an HTML version that is, believe it or not, even
worse than the text version.

I've been watching Chase operate like this for a few years now, and
every time I think they've hit the bottom of the ocean of misguided
behavior, they come out with a new demonstration that there are new
depths yet to dive to.

Perry

From: Chase Business Banking [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Chase Business Customers, we need your help!
Date: Tue, 24 Apr 2007 XX:XX:XX -


We're working to better serve your business needs!

=

Dear Business Customer, 

We're updating our records and need your help to ensure we have 
the most up-to-date information about your business. This is an 
important step in ensuring that we can continue to provide you 
with timely and accurate information about your accounts.

Go here to answer a couple of questions about your business 
profile:
http://click.chase.com/X.X.X..X

It will take you less than 60 seconds, and then you're done! 
And remember, the more we know your business, the better we can 
serve your ever-changing needs.

Thanks for choosing Chase.

Sincerely,

Janet M. Hawkins

Chief Marketing Officer
Business Banking

-
E-mail Security Information 
 
If you would like to learn more about e-mail security or want to 
report a suspicious e-mail, click here:
http://click.chase.com/X.X.X.

Note: If you are concerned about clicking links in this e-mail, 
the Chase Online services mentioned above can be accessed by 
typing www.chase.com directly into your browser.
-

ABOUT THIS MESSAGE
TO UNSUBSCRIBE from future promotional e-mails from Chase, please 
reply to this e-mail and type UNSUBSCRIBE in the Subject line. 
The e-mail address from which you send the request will be removed 
from our e-mail list. Please allow ten business days for us to 
process your request. You will continue to receive service related 
e-mail messages that concern your existing Chase banking products 
and services.

If you want to contact Chase, please do not reply to this message, 
but instead go to www.chase.com. For faster service, please enroll 
or log in to your account. Replies to this message will not be 
read or responded to.

Your personal information is protected by advanced technology. For 
more detailed security information, view our Online Privacy Policy: 
http://click.chase.com/X.X.X.
To request in writing: Chase Privacy Operations, 451 Florida 
Street, Fourth Floor, LA2-9376, Baton Rouge, LA 70801. 

JPMorgan Chase Bank, N.A. Member FDIC. Equal Opportunity Lender
(C) 2007 JPMorgan Chase  Co.

X

This e-mail was sent to: [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]