Re: More info in my AES128-CBC question

2007-05-14 Thread Leichter, Jerry
|  Just being able to generate traffic over the link isn't enough to
|  carry out this attack.
| 
| Well, it depends on if you key per-flow or just once for the link.  If
| the latter, and you have the ability to create traffic over the link,
| and there's a 1-for-1 correspondence between plaintext and encrypted
| packets, then you have a problem.
I have no clue what this means.
 
| Scenarios include:
| 
| Private wifi network, you are sending packets at a customer from
| unprivileged node on internet; you want known plaintext for the key
| used to secure the wifi traffic, or you want the contents of his
| connection.
| 
| Target is VPN'ed into corporate headquarters, you are sending packets
| at them (or you send them email, they download it from their mail server)
Again, we're talking about a particular attack, which requires (a) not
known, but chosen plaintext; (b) more, *adaptive* chosen plaintext:  You
have to be in a position to choose the plaintext for the next block that
will be encrypted *after* you've seen the ciphertext of the previous
block.

Nothing like e-mail is going to work, since even supposing you could grab
the last packet on the link and get your mail message to be the next
thing to get sent over the link:  The first block of a mail message as
a server delivers it is never going to be completely under your control,
and in fact it's unlikely you can control any of it.  (If what you meant
by 1-for-1 correspondence between plaintext and encrypted packets,
then I guess that mail doesn't come close.)

You can certainly come up with artificial scenarios where such an attack
would work.  For example, suppose you know that the victim it tailing
some file, and you can write to that file.  Then by appending to the
file you are inserting chosen plaintext into his datastream.  Maybe you
could come up with some analogous attack around an RSS feed, but I'm
skeptical - you have to be able to choose every byte of the first block
or the attack is impossible.  Further, suppose you can choose the first
block, but only some fraction of the time.  Well ... without some other
signal, you can't tell if the first block failed to match your target
because your target was wrong, or because you didn't manage to get your
block in.  So now you have to try repeatedly.  What was always a brute-
force search just got multiplied by some factor.

Again, it's not that this isn't a potentially significant attack.  It's
that the combination of special circumstances you need to pull it off -
a block known to have high value; a small enough set of possible values
for that block that you have hope of guessing it correctly before the
key is reused; enough pauses in the datastream to actually let you try
enough probes to get a significant probability of confirming a guess;
the ability to insert random packets into the plaintext repeatedly
without it being noticed - limits the plausible attack scenarios to a
rather small set.  One can worry about everything or one can try to
field real systems.
-- Jerry

| -- 
| Kill dash nine, and its no more CPU time, kill dash nine, and that
| process is mine. -- URL:http://www.subspacefield.org/~travis/
| For a good time on my UBE blacklist, email [EMAIL PROTECTED]
| 

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


Re: More info in my AES128-CBC question

2007-05-13 Thread Hal Finney
Earlier someone asked about comparisons between full-width CFB and CBC.
They are very similar in certain ways. For example, the sequence of
operations for both are the same: xor the next block of plaintext; encrypt
the result; xor the next block of plaintext; encrypt the result; and so
on. The difference relates to the handling of the IV and the last block;
and more importantly, to where in this chain we define the output to be.
For CBC the output is after the encrypt steps; for CFB the output is
after the xor teps.  This also implies that, except for the first and
last blocks, you can transform a CBC encryption into a CFB encryption
by xoring the plaintext into the ciphertext, and vice versa.

In terms of IV, CFB encrypts the IV and then xors with the first block
of plaintext.  CBC xors the IV with the plaintext and then encrypts.
So you have a little more flexibility in terms of choosing your IV,
with CFB mode.  A simple counter should be good enough.  However the
penalty for erroneously reusing an IV is worse; it reveals the XOR of the
respective plaintexts, whereas in CBC mode it will only reveal whether
the plaintexts are identical.

Hal Finney
PGP Corporation

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Leichter, Jerry
|  |   Frankly, for SSH this isn't a very plausible attack, since
|  |   it's not clear how you could force chosen plaintext into an
|  |   SSH session between messages.  A later paper suggested that
|  |   SSL is more vulnerable: A browser plugin can insert data into
|  |   an SSL protected session, so might be able to cause
|  |   information to leak.
|  |  
|  |  Hmm, what about IPSec?  Aren't most of the cipher suites used
|  |  there CBC mode?
|  | 
|  | ESP does not chain blocks across packets.  One could produce an
|  | ESP implementation that did so, but there is really no good reason
|  | for that, and as has been widely discussed, an implementation
|  | SHOULD use a PRNG to generate the IV for each packet.
|  I hope it's a cryptographically secure PRNG.  The attack doesn't
|  require any particular IV, just one known to an attacker ahead of
|  time.
|  
|  However, cryptographically secure RNG's are typically just as
|  expensive as doing a block encryption.  So why not just encrypt the
|  IV once with the session key before using it?  (This is the
|  equivalent of pre-pending a block of all 0's to each packet.)
| 
| But if the key doesn't change between messages then this makes the IV
| of the second block constant and if any plaintext repeats in the first
| block of plaintext then you have a problem.
I guess my proposal was ambiguous.  You don't use the encryption of
the *initial* IV for each packet; you use the encryption of what you
would otherwise have used as the IV, i.e., the last ciphertext block
of the previous packet.  The IV of the packet after that is just as
variable as it ever was.  (If it were not, then CBC would be just
about useless:  The CBC encryption of, say, the second block of two
all 0 blocks would always be the same!)
-- Jerry

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Travis H.
On Wed, May 09, 2007 at 06:11:03PM -0400, Leichter, Jerry wrote:
 Just being able to generate traffic over the link isn't enough to
 carry out this attack.

Well, it depends on if you key per-flow or just once for the link.  If
the latter, and you have the ability to create traffic over the link,
and there's a 1-for-1 correspondence between plaintext and encrypted
packets, then you have a problem.

Scenarios include:

Private wifi network, you are sending packets at a customer from
unprivileged node on internet; you want known plaintext for the key
used to secure the wifi traffic, or you want the contents of his
connection.

Target is VPN'ed into corporate headquarters, you are sending packets
at them (or you send them email, they download it from their mail server)

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpEWNibI30LX.pgp
Description: PGP signature


Re: More info in my AES128-CBC question

2007-05-12 Thread Nicolas Williams
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
 |   Frankly, for SSH this isn't a very plausible attack, since it's not
 |   clear how you could force chosen plaintext into an SSH session between
 |   messages.  A later paper suggested that SSL is more vulnerable:
 |   A browser plugin can insert data into an SSL protected session, so
 |   might be able to cause information to leak.
 |  
 |  Hmm, what about IPSec?  Aren't most of the cipher suites used there
 |  CBC mode?
 | 
 | ESP does not chain blocks across packets.  One could produce an ESP
 | implementation that did so, but there is really no good reason for
 | that, and as has been widely discussed, an implementation SHOULD use
 | a PRNG to generate the IV for each packet.
 I hope it's a cryptographically secure PRNG.  The attack doesn't require
 any particular IV, just one known to an attacker ahead of time.
 
 However, cryptographically secure RNG's are typically just as expensive
 as doing a block encryption.  So why not just encrypt the IV once with
 the session key before using it?  (This is the equivalent of pre-pending
 a block of all 0's to each packet.)

But if the key doesn't change between messages then this makes the IV of
the second block constant and if any plaintext repeats in the first
block of plaintext then you have a problem.

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


Re: More info in my AES128-CBC question

2007-05-12 Thread Travis H.
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
 However, cryptographically secure RNG's are typically just as expensive
 as doing a block encryption.  So why not just encrypt the IV once with
 the session key before using it?  (This is the equivalent of pre-pending
 a block of all 0's to each packet.)

There's many ways to deal with it if you're willing to do more crypts
per block.  For example, you could derive an independent key and use
that to encrypt a counter for IVs... becoming a cryptographically
strong permutation... that'd work as long as you didn't send so many
IVs that you ran through most of the cycle (the last value in the
cycle is 100% predictable).

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpYqqeHkErOq.pgp
Description: PGP signature


Re: More info in my AES128-CBC question

2007-05-09 Thread Travis H.
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
 Frankly, for SSH this isn't a very plausible attack, since it's not
 clear how you could force chosen plaintext into an SSH session between
 messages.  A later paper suggested that SSL is more vulnerable:
 A browser plugin can insert data into an SSL protected session, so
 might be able to cause information to leak.

Hmm, what about IPSec?  Aren't most of the cipher suites used there
CBC mode?  If it doesn't key each flow seperately, and the opponent
has the ability to generate traffic over the link, which isn't
unreasonable, then this would seem feasible.  And then there's openvpn,
which uses SSL for the point-to-point link, thus probably vulnerable,
more vulnerable than a browser.  I am also aware of SSL being used
many places other than browsers and openvpn.

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpvjZwMdNcnK.pgp
Description: PGP signature


Re: More info in my AES128-CBC question

2007-05-09 Thread Steven M. Bellovin
On Wed, 9 May 2007 15:35:44 -0400
Thor Lancelot Simon [EMAIL PROTECTED] wrote:

 On Wed, May 09, 2007 at 01:13:36AM -0500, Travis H. wrote:
  On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
   Frankly, for SSH this isn't a very plausible attack, since it's
   not clear how you could force chosen plaintext into an SSH
   session between messages.  A later paper suggested that SSL is
   more vulnerable: A browser plugin can insert data into an SSL
   protected session, so might be able to cause information to leak.
  
  Hmm, what about IPSec?  Aren't most of the cipher suites used there
  CBC mode?
 
 ESP does not chain blocks across packets.  One could produce an ESP
 implementation that did so, but there is really no good reason for
 that, and as has been widely discussed, an implementation SHOULD use
 a PRNG to generate the IV for each packet.

Mostly right.  RFC 2405 stated:

   Implementation note:

  Common practice is to use random data for the first IV and the
  last 8 octets of encrypted data from an encryption process as the
  IV for the next encryption process; this logically extends the CBC
  across the packets.

not as a requirement but as a hint.  On the other hand, RFC 3602 says

   The IV MUST be chosen at random, and MUST be
   unpredictable.




--Steve Bellovin, http://www.cs.columbia.edu/~smb

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


Re: More info in my AES128-CBC question

2007-05-09 Thread Leichter, Jerry
|   Frankly, for SSH this isn't a very plausible attack, since it's not
|   clear how you could force chosen plaintext into an SSH session between
|   messages.  A later paper suggested that SSL is more vulnerable:
|   A browser plugin can insert data into an SSL protected session, so
|   might be able to cause information to leak.
|  
|  Hmm, what about IPSec?  Aren't most of the cipher suites used there
|  CBC mode?
| 
| ESP does not chain blocks across packets.  One could produce an ESP
| implementation that did so, but there is really no good reason for
| that, and as has been widely discussed, an implementation SHOULD use
| a PRNG to generate the IV for each packet.
I hope it's a cryptographically secure PRNG.  The attack doesn't require
any particular IV, just one known to an attacker ahead of time.

However, cryptographically secure RNG's are typically just as expensive
as doing a block encryption.  So why not just encrypt the IV once with
the session key before using it?  (This is the equivalent of pre-pending
a block of all 0's to each packet.)
-- Jerry

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


Re: More info in my AES128-CBC question

2007-05-09 Thread Leichter, Jerry
|  Frankly, for SSH this isn't a very plausible attack, since it's not
|  clear how you could force chosen plaintext into an SSH session between
|  messages.  A later paper suggested that SSL is more vulnerable:
|  A browser plugin can insert data into an SSL protected session, so
|  might be able to cause information to leak.
| 
| Hmm, what about IPSec?  Aren't most of the cipher suites used there
| CBC mode?  If it doesn't key each flow seperately, and the opponent
| has the ability to generate traffic over the link, which isn't
| unreasonable, then this would seem feasible.  And then there's openvpn,
| which uses SSL for the point-to-point link, thus probably vulnerable,
| more vulnerable than a browser.  I am also aware of SSL being used
| many places other than browsers and openvpn.
Just being able to generate traffic over the link isn't enough to
carry out this attack.  You have to be able to get the sender to
encrypt a chosen block for you as the first thing in a packet.  How
would you do that?  Suppose there was an echo command that would
cause the receiver to send back (within the encrypted channel) whatever
data you asked.  Well, how do you get an echo command inserted into
the encrypted, presumably authenticated, flow going back the other
way?

The browser SSL attack could work because plugin code runs *within* the
browser - which knows the key - and it can add material to the red
(plaintext) connection data.  How do you propose mounting the attack
given only access to the black connection data?

I'm not saying there couldn't be such an attack, or that it's not
worth defending against - just that it appears to be very hard to
pull off.
-- Jerry

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


Re: More info in my AES128-CBC question

2007-04-27 Thread Alexander Klimov
On Wed, 25 Apr 2007, Travis H. wrote:
  If the IV chained across continguous messages as in SSHv2
  then you have a problem (see above).

 I don't fully understand what it means to have IVs chained
 across contiguous (?) messages, as in CBC mode each ciphertext
 block forms the IV of the block after it, effectively;
 basically an IV is just C_0 for some stream.

The order of events is important. Consider a chosen plaintext
attack: a secret message was sent other a CBC-encrypted channel.
For example, it was a single block with padded yes or no and
the encryption is x0||x1, where x0 is a random IV and

  x1 = E(x0 xor yes),

the attacker can now submit their message to find the secret
one. If the attacker knows that x1 is going to be used as the
next IV, they can try to submit

  m = x0 xor yes xor x1

it will be encrypted as

  x2 = E(m xor x1) = E(x0 xor yes) = x1

so if x2 = x1 the attacker knows that yes was sent, otherwise
it was no.

If the new IV is randomly selected *after* the attacker has made
his choice the attack is impossible.

-- 
Regards,
ASK

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


Re: More info in my AES128-CBC question

2007-04-27 Thread Nicolas Williams
On Wed, Apr 25, 2007 at 10:58:01PM -0500, Travis H. wrote:
 On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
  A confounder is an extra block of random plaintext that is prepended to
  a message prior to encryption with a block cipher in CBC (or CTS) mode;
  the resulting extra block of ciphertext must also be sent to the peer.
 
 Not true.  Since we are comparing confounders to IVs, let's make identical
 assumptions; that the value is somehow agreed upon in advance.

The term confounder as used in Kerberos V is as I described.

  If the
  IV chained across continguous messages as in SSHv2 then you have a
  problem (see above).
 
 I don't fully understand what it means to have IVs chained across
 contiguous (?) messages, as in CBC mode each ciphertext block forms
 the IV of the block after it, effectively; basically an IV is just
 C_0 for some stream.

The last ciphertext block of one message is the IV for the next.

Nico
-- 

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


Re: More info in my AES128-CBC question

2007-04-27 Thread Leichter, Jerry
|  What problem does this (chaining IV from message to message) introduce
|  in our case?
| 
| See RFC4251:
| 
| 
|Additionally, another CBC mode attack may be mitigated through the
|insertion of packets containing SSH_MSG_IGNORE.  Without this
|technique, a specific attack may be successful.  For this attack
|(commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
|work, the attacker would need to know the Initialization Vector (IV)
|of the next block that is going to be encrypted.  In CBC mode that is
|the output of the encryption of the previous block.  If the attacker
|does not have any way to see the packet yet (i.e., it is in the
|internal buffers of the SSH implementation or even in the kernel),
|then this attack will not work.  If the last packet has been sent out
|to the network (i.e., the attacker has access to it), then he can use
|the attack.
| 
This still doesn't describe how the attack works.  It's very special-
ized: A chosen-plaintext attack that can confirm the decryption of a a
previously intercepted block (but cannot directly reveal it).

In the following, all encryptions are with respect to a fixed (but
unknown to the attacker) key.  Earlier, the attacker intercepted I and
E(I xor X), where X is some unknown data and I is the IV that was used
in encrypting it.  (That is, I is simply the previous encrypted block.)
The attacker has a guess Y as to what X is and wishes to confirm it.  He
also knows J, the next IV to be used; and can choose the next block to
be encrypted.  He chooses Y xor J xor I.  The CBC encryptor sends:

E(J xor Y xor J xor I) == E(I xor Y)

The attacker examines this block as it's transmitted, and compares it
to E(I xor X).  If they are the same, then X == Y.

Notice that this requires true *chosen* plaintext - known plaintext does
you no good at all.  And you have to be able to choose any plaintext -
what you're stuffing in there will look essentially random, because J
and for that matter I are essentially random.  Since all you'll see is
the encrypted result, you have to be able to choose *all* the bits.

Since SSH sends the password at a guessable point in the stream, the
block containing is locatable and it has high value.  If an attacker
grabs it, he could try password guessing attacks through the
subsequent encryption.

Frankly, for SSH this isn't a very plausible attack, since it's not
clear how you could force chosen plaintext into an SSH session between
messages.  A later paper suggested that SSL is more vulnerable:
A browser plugin can insert data into an SSL protected session, so
might be able to cause information to leak.  Note that for this to be
an interesting attack, we have to posit that the plugin can be caused
to run within a browser during a secure session containing valuable
data, but also that the browser is sufficiently secure that the plugin
can't get at the data directly.  (The Java security model does try to
enforce this kind of separation.)

It's really tough to formalize exactly what is going on here, since
there's this whole funny notion of knowing the next IV to be used in
time to choose the next plaintext.  I guess we assume that the
implementation doesn't allow you to change the contents of a message
once you've passed it down to the crypto layer; otherwise, you could
in principle apply this attack between every pair of CBC-encrypted
blocks.  Unrealistic?  There were attacks against OS 360 in which
you passed in a channel program, then modified it while it was being
executed, sometimes from the CPU, sometimes by causing one element
in the channel program to do I/O that overwrote another element before
the channel got there.  So I would certainly not dismiss this as
completely impossible.

What the RFC seems to be suggesting is that the first block of every
message be SSH_MSG_IGNORE.  Since the first block in any message is now
fixed, there's no way for the attacker to choose it.  Since the attacker
doesn't know the key, even knowing the IV used with this fixed message
doesn't tell him what IV will be used for the block after, the earliest
one he could specify.  The same IV will likely never by seen again
during the lifetime of the key, so knowing the output of encrypting the
fixed message with that IV is also useless.  Adding some random data to
the ignored block can be done but has no effect on the security.  Note
that the wire overhead is the same here as with sending a new IV: One
block.  You can avoid that by making the IV's computable by a party that
knows the key:  E.g., use E(n) as the IV for the n'th block.  Or even
simpler, take the saved IV and encrypt it an extra time before using it.
The advantage of the RFC's approach is that it works with older peers:
They messages they send remain vulnerable, but the messages a new
implementation sends them are not, but are completely understandable.
If you need to upgrade an already fielded protocol, this is the best 

Re: More info in my AES128-CBC question

2007-04-27 Thread Nicolas Williams
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
 What the RFC seems to be suggesting is that the first block of every
 message be SSH_MSG_IGNORE.  Since the first block in any message is now
 fixed, there's no way for the attacker to choose it.  Since the attacker

SSH_MSG_IGNORE messages carry [random] data.

Effectively what the RFC is calling for is a confounder.

Nico
-- 

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


Re: More info in my AES128-CBC question

2007-04-27 Thread Leichter, Jerry
|  What the RFC seems to be suggesting is that the first block of every
|  message be SSH_MSG_IGNORE.  Since the first block in any message is now
|  fixed, there's no way for the attacker to choose it.  Since the attacker
| 
| SSH_MSG_IGNORE messages carry [random] data.
| 
| Effectively what the RFC is calling for is a confounder.
No, not really, for any reasonable interpretation I can make of
that term.  You can send a message that consists of enough 0 bytes
to be sure that the entire first block is fixed, and you've gotten
all the security you can get against the attack in question.  (If
you're using SSH_MSG_IGNORE to protect against traffic analysis, you
might want to do something different - but that's a completely
distinct attack and the security considerations are entirely
different.)

-- Jerry
 
| Nico
| -- 
| 
| 

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


Re: More info in my AES128-CBC question

2007-04-26 Thread Allen



Aram Perez wrote:

Another response was you haven't heard of anyone breaking SD cards have 

you?

I love responses like this. In the physical world there are the 
examples of the Kyptonite lock and the Master Combination lock. 
By the time you hear about the methodology of the attack someone 
has lost their $16000+ motorcycle or had their wallet with $1000 
and identity papers stolen from their gym locker and they really 
were telling the truth about knowing they locked it up properly.


My counter to this sort of response is, How many people are 
attacking it that you don't know about yet?


For one I can almost (not being on staff I can't be absolutely 
sure) guarantee that the NSA is hard at work at cracking SD 
cards. Why, you might ask? Simple. What would be the easiest way 
for a spy to smuggle critical information out of a country? As an 
ostensible tourist with a camera and multiple SD cards. Even 
easier would be to give the camera to a real tourist as a gift 
and then steal it back when they get home.


There is a very fine balancing act between confidentiality (or 
secrecy, if you'd rather) and an open society with 
accountability. America's existence is partly as a result of 
people objecting to a Star Chamber legal system and yet the 
security of democracy resides on having truly secure and private 
elections that can not be tampered with without it becoming 
known. This is where cryptography can play a critical role in 
maintaining trust in our system of governance and protecting 
people who hold divergent views or beliefs from intimidation.


Best,

Allen

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


Re: More info in my AES128-CBC question

2007-04-26 Thread Travis H.
On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
 A confounder is an extra block of random plaintext that is prepended to
 a message prior to encryption with a block cipher in CBC (or CTS) mode;
 the resulting extra block of ciphertext must also be sent to the peer.

Not true.  Since we are comparing confounders to IVs, let's make identical
assumptions; that the value is somehow agreed upon in advance.

Then, one need not send it; the receiver can compute C_(i-1) = E_k(confounder)
without actually having it sent to him, and from there
continue decryption with P_i = C_(i-1) xor D_k(C_i) and so on.

 If the
 IV chained across continguous messages as in SSHv2 then you have a
 problem (see above).

I don't fully understand what it means to have IVs chained across
contiguous (?) messages, as in CBC mode each ciphertext block forms
the IV of the block after it, effectively; basically an IV is just
C_0 for some stream.

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgp5R1OqVH44H.pgp
Description: PGP signature


Re: More info in my AES128-CBC question

2007-04-26 Thread Alexander Klimov
On Wed, 25 Apr 2007, Hagai Bar-El wrote:
 It seems as Aram uses a different IV for each message encrypted with
 CBC. I am not sure I see a requirement for randomness here. As far
 as I can tell, this IV can be a simple index number or something as
 predictable, as long as it does not repeat within the same key
 scope.

For CBC mode the IV should be random because it is added
directly to plaintext. For example, if one sends `010' with IV
`001' the result of the xor will be the same as if they
subsequently send `101' with IV `110' and thus an attacker will
be able to learn something about the plaintext. If the IV is
random then we expect a collision after 2^{n/2} messages, but if
IV has some structure (or if an attacker knows the next IV
before they insert their own plaintext to be encrypted) the
probability of collision may become too high.

For some other modes (e.g., CFB, OFB, or CTR) the IV only needs
to be fresh, since the IV is first processed by the cipher. But
even in this case it is a good idea to use random IVs to protect
against state roll-back attacks.

-- 
Regards,
ASK

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


RE: More info in my AES128-CBC question

2007-04-25 Thread Leichter, Jerry
|  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.
In the original proposal, the IV was *fixed*:  It was always 0.  As a
result, it wasn't communicated, so could not be manipulated.

Integrity enforcement is required for other reasons anyway (and, based
on later responses, was always part of the protocol).

-- Jerry

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


Re: More info in my AES128-CBC question

2007-04-25 Thread Hagai Bar-El
Hello Nico,

On 25/04/07 02:18, Nicolas Williams wrote:
 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.

Is there anything wrong with changing the integrity key every message as
means for preventing cut-and-paste attacks between messages or against
taking messages out of their order? It may not be the most efficient
way; adding a message counter to the HMAC does make more sense, but is
there a problem with the way Aram uses now? (I don't see any.)

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

What problem does this (chaining IV from message to message) introduce
in our case?

 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.

It seems as Aram uses a different IV for each message encrypted with
CBC. I am not sure I see a requirement for randomness here. As far as I
can tell, this IV can be a simple index number or something as
predictable, as long as it does not repeat within the same key scope.

 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).

I don't understand the difference between a confounder and an IV in
terms of bits on the wire. After all, in both cases the confounder or IV
need to be passed to the other side, unless they are implicitly known.

Hagai.


-- 
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com

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


Re: More info in my AES128-CBC question

2007-04-25 Thread Nicolas Williams
On Wed, Apr 25, 2007 at 05:20:30PM +0300, Hagai Bar-El wrote:
 On 25/04/07 02:18, Nicolas Williams wrote:
  But be careful.  Simply chaining the IV from message to message will
  create problems (see SSH).
 
 What problem does this (chaining IV from message to message) introduce
 in our case?

See RFC4251:


   Additionally, another CBC mode attack may be mitigated through the
   insertion of packets containing SSH_MSG_IGNORE.  Without this
   technique, a specific attack may be successful.  For this attack
   (commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
   work, the attacker would need to know the Initialization Vector (IV)
   of the next block that is going to be encrypted.  In CBC mode that is
   the output of the encryption of the previous block.  If the attacker
   does not have any way to see the packet yet (i.e., it is in the
   internal buffers of the SSH implementation or even in the kernel),
   then this attack will not work.  If the last packet has been sent out
   to the network (i.e., the attacker has access to it), then he can use
   the attack.


  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.
 
 It seems as Aram uses a different IV for each message encrypted with
 CBC. I am not sure I see a requirement for randomness here. As far as I
 can tell, this IV can be a simple index number or something as
 predictable, as long as it does not repeat within the same key scope.

I think you should really consider the SSHv2 experience and add a
confounder.  The confounder plaintext block need not be random or
pseudo-random, just non-repeating.

  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).
 
 I don't understand the difference between a confounder and an IV in
 terms of bits on the wire. After all, in both cases the confounder or IV
 need to be passed to the other side, unless they are implicitly known.

A confounder is an extra block of random plaintext that is prepended to
a message prior to encryption with a block cipher in CBC (or CTS) mode;
the resulting extra block of ciphertext must also be sent to the peer.

An IV is a cipher block size's worth of bits that is XORed into the
first plaintext block when encrypting/decrypting; if you somehow agree
upon an IV to use and so does not take up any bits on the wire.  If the
IV chained across continguous messages as in SSHv2 then you have a
problem (see above).  If it's constant then you have a problem that you
can solve by deriving per-message keys or by generating a pseudo-random
IV from a sequence number.

Since the protocol describe generates per-message integrity keys I
imagine that it might generate per-message confidentiality keys as well,
in which case the IV issue goes away.

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 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]


Additional Re: More info in my AES128-CBC question

2007-04-23 Thread Allen
Sorry gang. In my response to David I forgot to provide the link 
to a brief history of ulcers from the CDC which is very 
interesting from the point of view of how long it takes for 
experts to accept evidence.


http://www.cdc.gov/ulcer/history.htm

Have fun.

Allen

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


Re: More info in my AES128-CBC question

2007-04-23 Thread Hagai Bar-El
Hello David,

On 22/04/07 00:04, David Wagner wrote:
 Hagai Bar-El writes:
 What Aram wrote is many of the attendees have very little security
 experience, not: there are no attendees with security experience.
 There are people at the relevant OMA group who know enough about
 security, but just like in the real world -- they are outnumbered by
 plain feature-set people, and thus have to come up with very clear
 arguments to get their way.
 
 So the people who don't know anything about security are reluctant to
 listen to those who do?  That's not a good sign.  It may be standard
 operating procedure in groups like this, but that doesn't make it right.
 It's still dysfunctional and dangerrous.  If the committee doesn't have
 a commitment to security and is reluctant to listen to the experts,
 that's a risk factor.

The group is not reluctant to listen, but it does expect to hear firm
reasoning, so the security consideration weights properly among other,
as important, considerations. Security gurus A' say A, Performance gurus
B' say B, which may partially conflict with A, and UI gurus C' say C. If
the product is broken then it's dead, but also if the product is slow
and annoys people, and also if average people can't use it for UI
reasons. It's easy to make a product that is never used, even if it's
secure. When we look at things, we see them as secure/insecure, but the
market and the economy sees a more complex picture where security is
very important, but is one important factor along with other important
factors that influence the design decision.

As long as security comes for no cost -- sure, why not. However, when
security comes at a cost that may make the product less useful, A' need
to convince (A' U B' U C') that they should have their way.

 If you're sick and you go to a doctor, do you tell the doctor you'd
 better come up with some very clear arguments if you want me to follow
 your advice?  Do you tell your doctor you'd better build a strong case
 before I will listen to you?  I would hope not.  That would be silly.
 Doctors are medical professionals with a great deal of training and
 expertise in the subject.  They can speak with authority when it comes
 to your health.  So why do people with no training in security think
 that they can freely ignore the advice of security professionals without
 any negative consequences?

As long as what the Doctor says costs you very little (in terms of risk
and/or money), you follow his advice blindly because challenging it will
cost you more. When the doctor tells you that you need a heart surgery
-- you do challenge it: you try to get a second opinion, you ask him to
explain the case in ways you can understand and be able to gain more
information on the subject. At least I hope you do.

People don't ignore security professionals. However, when high costs are
involved, challengeable rationale is called for. As long as economy is
not a single-factor B/W, this is how it should be.

 AND (3) If you don't care about replacement attacks on the (1 to i)
 blocks that will result only in a (possibly-undetected) corruption when
 decrypting the i+1 block (rather than two blocks, with a varying and
 non-attacker-changeable). [...]
 
 Wait a minute.  This reference to replacement attacks has me concerned.  
 Does the protocol use a message authentication code (MAC)?  I hope so.
 If your protocol uses a MAC, and uses it properly, then replacement
 attacks are not an issue, and the only issue with using a fixed IV is 
 related to confidentiality.  If you don't use a MAC, you've got bigger
 problems, and even random IVs won't be enough.

I generally agree.
Some protocols try to be cheap on MAC, assuming that the strict
structure of the protocol will cause a failure if something goes bad.
For example, if a message has an intrinsic entropy of 2 bits (say, a
return status code), and is sent as one block (you can't send less),
then you don't really need a MAC, as long as the recipient knows not to
crash disgracefully if it receives an invalid status code.

I guess my point is meaningless for the case in question, as MACs are
used...

Hagai.


-- 
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com

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


More info in my AES128-CBC question

2007-04-22 Thread David Wagner
Hagai Bar-El writes:
What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the real world -- they are outnumbered by
plain feature-set people, and thus have to come up with very clear
arguments to get their way.

So the people who don't know anything about security are reluctant to
listen to those who do?  That's not a good sign.  It may be standard
operating procedure in groups like this, but that doesn't make it right.
It's still dysfunctional and dangerrous.  If the committee doesn't have
a commitment to security and is reluctant to listen to the experts,
that's a risk factor.

If you're sick and you go to a doctor, do you tell the doctor you'd
better come up with some very clear arguments if you want me to follow
your advice?  Do you tell your doctor you'd better build a strong case
before I will listen to you?  I would hope not.  That would be silly.
Doctors are medical professionals with a great deal of training and
expertise in the subject.  They can speak with authority when it comes
to your health.  So why do people with no training in security think
that they can freely ignore the advice of security professionals without
any negative consequences?


I do not know the protocol in question, but in a nutshell: Generally,
CBC with a fixed IV (be it zero or any other value) is to be avoided for
the reason described in previous posts. In some circumstances this
restriction may be relaxed, such as:

(1) if the first unknown (to the attacker) block _always_ follows (not
necessarily immediately) a session-specific block (a block that is not
likely to repeat for the same key, such as a message-id). For example,
if every encrypted structure starts with an id that never repeats among
structures, and all security-wise meaningful blocks follow it, you are
_probably_ safe.

(2) if the key is never re-used among structures you encrypt.

Right.

AND (3) If you don't care about replacement attacks on the (1 to i)
blocks that will result only in a (possibly-undetected) corruption when
decrypting the i+1 block (rather than two blocks, with a varying and
non-attacker-changeable). [...]

Wait a minute.  This reference to replacement attacks has me concerned.  
Does the protocol use a message authentication code (MAC)?  I hope so.
If your protocol uses a MAC, and uses it properly, then replacement
attacks are not an issue, and the only issue with using a fixed IV is 
related to confidentiality.  If you don't use a MAC, you've got bigger
problems, and even random IVs won't be enough.

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


Re: More info in my AES128-CBC question

2007-04-22 Thread Paul Hoffman

At 2:04 PM -0700 4/21/07, David Wagner wrote:

Hagai Bar-El writes:

What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the real world -- they are outnumbered by
plain feature-set people, and thus have to come up with very clear
arguments to get their way.


So the people who don't know anything about security are reluctant to
listen to those who do?  That's not a good sign. It may be standard
operating procedure in groups like this, but that doesn't make it right.
It's still dysfunctional and dangerrous.  If the committee doesn't have
a commitment to security and is reluctant to listen to the experts,
that's a risk factor.


In a typical standards-setting environment, non-security people are 
usually only willing to listen to security people up to a certain 
threshold. There are three normal scenarios:


- A security person proposes a good way to do security for the 
proposed protocol. A non-security person says (incorrectly) I heard 
that doesn't work. The security person argues that it does work 
here, and the non-security person, not wanting to look foolish, digs 
in his heels. People get bored of hearing an argument they don't 
understand and make an arbitrary decision.


- A non-security person proposes a bad way to do security for the 
proposed protocol. A security person explains why that is insecure. 
The non-security person argues (sometimes correctly) that they did it 
in this other protocol so we should copy that, and the security 
person tries to explain why this is bad security. People get bored of 
hearing an argument they don't understand and make an arbitrary 
decision.


- A security person proposes two different ways to do security for 
the proposed protocol. The second is significantly faster than the 
first, but has worse security properties. People say the first is 
good enough for our scenario and pick it, often not even bothering 
to document the diminished security properties.


FWIW, this can happen when designing pure security protocols, 
swapping non-security person with security novice or security 
tourist or security hobbiest or security poser.



So why do people with no training in security think
that they can freely ignore the advice of security professionals without
any negative consequences?


Because doing so can get things finished earlier and/or make a more 
efficient protocol.


Same as it ever was.

--Paul Hoffman, Director
--VPN Consortium

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


Re: More info in my AES128-CBC question

2007-04-22 Thread Greg Black
On 2007-04-21, David Wagner wrote:

 If you're sick and you go to a doctor, do you tell the doctor you'd
 better come up with some very clear arguments if you want me to follow
 your advice?  Do you tell your doctor you'd better build a strong case
 before I will listen to you?  I would hope not.  That would be silly.

Not at all.  That would be smart.  Blind deference to experts, in any
field, is just plain stupid.

 Doctors are medical professionals with a great deal of training and
 expertise in the subject.  They can speak with authority when it comes
 to your health.  So why do people with no training in security think
 that they can freely ignore the advice of security professionals without
 any negative consequences?

Asking the professionals to make a clear case is not the same as freely
ignoring them.  But blindly following those who speak with authority
leads to all sorts of nonsensical outcomes.

If we are consulting an expert, it behoves us to examine the expert's
reasoning.  If we are the experts, we should expect to have to explain
ourselves to those who rely on us -- and we should volunteer those
explanations rather than making people drag them out of us.

Cheers, Greg

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


Re: More info in my AES128-CBC question

2007-04-21 Thread Hagai Bar-El
Hello all,

On 20/04/07 08:32, Aram Perez wrote:
 The proposal for using AES128-CBC with a fixed IV of all zeros is for
 a protocol between two entities that will be exchanging messages.
 This is being done in a standards body (OMA) and many of the
 attendees have very little security experience. As I mentioned, the
 response to my question of why would we standardize this was that's
 how SD cards do it.
 
 I'll look at the references and hopefully convince enough people that
 it's a bad idea.


Relating to the anger at the random bunch of people [who] design crypto
protocols:

What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the real world -- they are outnumbered by
plain feature-set people, and thus have to come up with very clear
arguments to get their way.

Aram figured fixed IV's is generally a bad idea, and probably so did
others at OMA, but since the security people have to build a case and
not just say well, it's generally not a good idea, a more descriptive
explanation of possible attacks (a justification) was sought for.

Now to the subject matter:

I do not know the protocol in question, but in a nutshell: Generally,
CBC with a fixed IV (be it zero or any other value) is to be avoided for
the reason described in previous posts. In some circumstances this
restriction may be relaxed, such as:

(1) if the first unknown (to the attacker) block _always_ follows (not
necessarily immediately) a session-specific block (a block that is not
likely to repeat for the same key, such as a message-id). For example,
if every encrypted structure starts with an id that never repeats among
structures, and all security-wise meaningful blocks follow it, you are
_probably_ safe.

(2) if the key is never re-used among structures you encrypt.

AND (3) If you don't care about replacement attacks on the (1 to i)
blocks that will result only in a (possibly-undetected) corruption when
decrypting the i+1 block (rather than two blocks, with a varying and
non-attacker-changeable). For example: If Message #1 and Message #2 are
encrypted with the same key, you can take blocks 1,2,3,..,i of Message
#2 and paste them in Message #1, and only block i+1 will decrypt badly.
If you had protected (attacker unchangeable) and varying IV's, block 1
would have decrypted badly too, for whatever it's worth.
(Comment: block 1 can be any higher index, as long as there are no
earlier blocks that differ between the messages.)

As the others stressed: the implication of these conditions/limitations,
as well as others which I may have not spotted, depend on the protocol...


Hagai.


P.S. Aram, as you know, I am signed on the OMA NDA, so you can send me
the protocol. If other members here are signed on the OMA NDA, I guess
it could be useful if you notified Aram in a private message, so you can
get your copy and examine it too.


-- 
Hagai Bar-El - Information Security Analyst
T/F: 972-8-9354152 Web: www.hbarel.com

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


More info in my AES128-CBC question

2007-04-20 Thread Aram Perez
Hi Folks,

First, thanks for all your answers.

The proposal for using AES128-CBC with a fixed IV of all zeros is for a 
protocol between two entities that will be exchanging messages. This is being 
done in a standards body (OMA) and many of the attendees have very little 
security experience. As I mentioned, the response to my question of why would 
we standardize this was that's how SD cards do it.

I'll look at the references and hopefully convince enough people that it's a 
bad idea.

Thanks again,
Aram Perez

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


Re: More info in my AES128-CBC question

2007-04-20 Thread Victor Duchovni
On Thu, Apr 19, 2007 at 10:32:58PM -0700, Aram Perez wrote:

 Hi Folks,
 
 First, thanks for all your answers.
 
 The proposal for using AES128-CBC with a fixed IV of all zeros is for a 
 protocol between two entities that will be exchanging messages. This is being 
 done in a standards body (OMA) and many of the attendees have very little 
 security experience. As I mentioned, the response to my question of why would 
 we standardize this was that's how SD cards do it.
 
 I'll look at the references and hopefully convince enough people that it's a 
 bad idea.
 

You still have not described the protocol, or how keys are used/managed.
The question has no answer outside the context of a specific protocol,
other than in general it is best practice to use random IVs or otherwise
unlikely to repeat IVs.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: More info in my AES128-CBC question

2007-04-20 Thread Steven M. Bellovin
On Thu, 19 Apr 2007 22:32:58 -0700
Aram Perez [EMAIL PROTECTED] wrote:

 Hi Folks,
 
 First, thanks for all your answers.
 
 The proposal for using AES128-CBC with a fixed IV of all zeros is for
 a protocol between two entities that will be exchanging messages.
 This is being done in a standards body (OMA) and many of the
 attendees have very little security experience. As I mentioned, the
 response to my question of why would we standardize this was that's
 how SD cards do it.
 
 I'll look at the references and hopefully convince enough people that
 it's a bad idea.
 
Let me make a stronger statement.  If the standards group has very
little security experience, they *will* get many things wrong.  They
desperately need to get several clueful individuals involved and
*listen* to them.

The WEP group made that mistake.  I use WEP in my classes as a case
study in how to do crypto wrong.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

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


Re: More info in my AES128-CBC question

2007-04-20 Thread Ivan Krstić
Aram Perez wrote:
 The proposal for using AES128-CBC with a fixed IV of all zeros is for
 a protocol between two entities that will be exchanging messages.
 This is being done in a standards body (OMA) and many of the
 attendees have very little security experience. 

We don't let a bunch of random people design airbags. How on earth is it
a good idea to let a random bunch of people design crypto protocols? Is
this the same bunch of people that will be shocked, just SHOCKED when
someone demonstrates that their design is idiotic and doesn't protect
anyone or anything?

No, really, that people with very little security experience feel
comfortable doing this kind of work just boggles my mind. Please
congratulate everyone involved, and remind them to always use their PPTP
VPN over their WEP-protected wireless.

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

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