Re: More info in my AES128-CBC question
| 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
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
| | 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
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
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
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
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
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
| 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
| 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
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
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
| 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
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
| 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
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
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
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
| 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
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
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
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
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
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
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
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
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
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]
Re: More info in my AES128-CBC question
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
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
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]
Re: More info in my AES128-CBC question
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
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
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]
