6 ms·

I was chair of the IPSEC working group at the IETF, and I think I know what John Gilmore was referring to with respect to the question of the Initialization Vec

by tytso 13y ago

I was chair of the IPSEC working group at the IETF, and I think I know what John Gilmore was referring to with respect to the question of the Initialization Vector. The person who expressed a concern with a per-packet IV (which by the way had indeed done a lot of consulting for the NSA; nice guy, though) didn't like the idea because it's too easy for people to screw up and use an incrementing counter for the IV. This is bad, because if the first couple of bytes in the packet are mostly fixed (becuase you are encapsulating a TCP or UDP packet, for example), the resulting plaintext in the first block of these packets will have a very low hamming distance between them, and this can enable certain cryptoanalytic attacks (i.e., such as differential cryptoanalysis). He was not advocating using the same IV across the entire session, in the sense that we would use the same IV for each packet (which would have been a cryptographic disaster), but rather we use the previous packet's cipherblock as the IV for the next packet (i.e., just keep chaining the cipherblocks). As is often the case in standards bodies when there is disagreement, neither side won, and we left things unspecified. The RFC doesn't constrain how the IV should be chosen, so you can initialize the IV either way. There was language indicating that the IV should never be the same, as well as an additional method of generating the IV, by using a Linear Feedback Shift Register (LFSR), which also will eliminate the potential problem of related plaintext being sent to the crypto algorithm. So although the RFC doesn't say this, I would recommend either the use of a LFSR, or the last cipherblock in the previous packet encrypted using that key, and to avoid using a simple counter in your IPSEC implementation for the Initialization Vector (IV) in each packet. So to be fair, in this particular case, the person with "known associations with the NSA" was actually trying to make things better, although he did feel constrained in not explaining all of his reasons in the open wg meeting. Which no doubt tripped Gilmore's paranoia, and I can't blame him for that either.

pkl2 13y ago
> which by the way had indeed done a lot of consulting for the NSA; nice guy, though Brings up an interesting point. Going forward should it be disqualifying to be currently working for the NSA to be on one of these committees? To have formerly worked for them? To done a lot of consulting? To have done any consulting? To have ever had a security clearance? Witchhunts have a deservedly negative connotation, but what if you are actually surrounded by witches?
- XorNot 13y ago
  So the rest of the above comment where it was explained that the whole issue is actually kind of nuanced, has important security implications when it comes to implementation details and is not at all "intentionally compromising", you just skipped over that hey?
  - stelonix 13y ago
    He brought up another point. Given the known NSA revelations so far, it seems ignorant at best to welcome people who have ties with the NSA without putting their opinions under some scrutiny.
    - bennyg 13y ago
      I say sure, extra scrutiny there. But we should also hold hackers (in the laymen sense of the word) who steal either information, finances, or actual things under just as tight of scrutiny too. I don't trust either to be honest.
- tytso 13y ago
  The hard part is that the NSA has two missions --- cracking foreign crypto, and protecting US crypto. When an NSA employee speaks, we will have no idea whether he or she is speaking with the "protect US crypto" hat on, or the "SIGINT enablement" hat on. I'd say the more important thing is that we not trust any one single person (or corporation). Everything needs to be open, and everything needs to be studied and verified by independent authorities. This also applies to how you implement your security. You want two person controls for everything, and separation of roles --- those people who can bypass file access controls had better not also be able to wipe log records. The NSA is relearning that lesson the hard way as they try to figure out what records Snowden might have leaked --- apparently Snowden had the ability to impersonate other users, as well as wipe the log records which were _hopefully_ being made when person A uses an "su"-like command to impersonate person B. After all, when someone stands up to give a suggestion at a standards meeting, or when someone goes through the hiring process to be one of your sysadmins, they won't be wearing a sign saying, "I do a huge amount of consultant work with the NSA and I have Top Secret/SCI/POLY clearance". Neither will job applicants have signs saying, "I'm getting paid by the Chinese MSS", or "I'm here to steal your SSL private keys".
wbl 13y ago
What you said makes no sense. The assumption is that a block cipher is secure to differential cryptanalysis. CBC mode requires unpredictable IV, and as the BEAST attack shows, chaining is a bad idea. RFC 3602 specifies using a random IV. Could you please cite minutes and an RFC, and maybe some more information so we can judge for ourselves?
- marshray 13y ago
  > The assumption is that a block cipher is secure to differential cryptanalysis. That assumption was not taken for granted back in the 90's. It was only with years of cryptanalysis of AES (which had had resistance to known plaintext an explicit design goal) that designers felt comfortable with things like CTR mode. In practice, we've learned that the block ciphers are by far the strongest part of the system, and it's the block cipher modes that provide the weakness for attackers. IMHO this is the type of poisoned knowledge that the US spies should be blamed for.
  - diminish 13y ago
    ..isn't a good place to be paranoid the core of AES, namely substitution-permutation network hocus-pocus. (Joan Daemen' and Vincent Rijmen's). A backdoor transformation would suffice to make all other paranoia superfluous.
    - marshray 13y ago
      I'm not saying its impossible, but decades of public cryptanalysis have failed to produce a significant dent in the security of 3DES or AES. On the other hand, we've seen a total discrediting of LFSR-based schemes and a steady flow of issues resulting from the block modes (padding and timing oracles). We should be paranoid, but mostly that we might be not worrying about the right things.
      - diminish 13y ago
        You are right that padding/timing attacks on block modes and weaknesses in PRGs form the bulk of contemporary cryptanalysis. Nonetheless, if there is one single backdoor transform with a unique key on AES substitution-permutation network which would make further attacks possible, it would be nearly impossible to devise a adversary/challenge to reveal it using current cryptanalysis techniques. The standardization history for AES, and the organizations involved does not give much hope neither.
marshray 13y ago
An LFSR? Really? If this person was really NSA-qualified to recommend this stuff, he would have known that known plaintext was the least of your problems. I'm sorry, tytso. It sounds like you all got expertly socially engineered.
- eps 13y ago
  Elaborate?
  - marshray 13y ago
    Discussion continued in other thread https://news.ycombinator.com/item?id=6347924 https://news.ycombinator.com/item?id=6347924
- tptacek 13y ago
  What's the attack you're thinking of against CBC with IVs drawn from an LFSR?
  - anologwintermut 13y ago
    LFSRs are not cryptographically secure random number generators. So you can, given a few IVs, recover the internal state and predict all subsequent IVs. Then it's just a matter of mounting an (adaptive) chosen plaintext attack against the system knowing what the next IV will be. This is something you can't do against AES CBC mode if the IV is actually random. It fails in the same way if you use the last packet's cipher-text as the IV and there are pauses between packets.
    - tptacek 13y ago
      The point of using an LFSR for IV generation is that it allows you not to transmit the IV on every message. Can you go into more detail about how you, a passive observer, are collecting enough information to reverse the LFSR? (This is aside from the fact that we're talking about an extremely elaborate way to construct a CPA attack against a protocol that does not automatically give attackers chosen plaintext).

by tytso 13y ago

pkl2 13y ago

> which by the way had indeed done a lot of consulting for the NSA; nice guy, though Brings up an interesting point. Going forward should it be disqualifying to be currently working for the NSA to be on one of these committees? To have formerly worked for them? To done a lot of consulting? To have done any consulting? To have ever had a security clearance? Witchhunts have a deservedly negative connotation, but what if you are actually surrounded by witches?

XorNot 13y ago
So the rest of the above comment where it was explained that the whole issue is actually kind of nuanced, has important security implications when it comes to implementation details and is not at all "intentionally compromising", you just skipped over that hey?
- stelonix 13y ago
  He brought up another point. Given the known NSA revelations so far, it seems ignorant at best to welcome people who have ties with the NSA without putting their opinions under some scrutiny.
  - bennyg 13y ago
    I say sure, extra scrutiny there. But we should also hold hackers (in the laymen sense of the word) who steal either information, finances, or actual things under just as tight of scrutiny too. I don't trust either to be honest.
tytso 13y ago
The hard part is that the NSA has two missions --- cracking foreign crypto, and protecting US crypto. When an NSA employee speaks, we will have no idea whether he or she is speaking with the "protect US crypto" hat on, or the "SIGINT enablement" hat on. I'd say the more important thing is that we not trust any one single person (or corporation). Everything needs to be open, and everything needs to be studied and verified by independent authorities. This also applies to how you implement your security. You want two person controls for everything, and separation of roles --- those people who can bypass file access controls had better not also be able to wipe log records. The NSA is relearning that lesson the hard way as they try to figure out what records Snowden might have leaked --- apparently Snowden had the ability to impersonate other users, as well as wipe the log records which were _hopefully_ being made when person A uses an "su"-like command to impersonate person B. After all, when someone stands up to give a suggestion at a standards meeting, or when someone goes through the hiring process to be one of your sysadmins, they won't be wearing a sign saying, "I do a huge amount of consultant work with the NSA and I have Top Secret/SCI/POLY clearance". Neither will job applicants have signs saying, "I'm getting paid by the Chinese MSS", or "I'm here to steal your SSL private keys".

wbl 13y ago

What you said makes no sense. The assumption is that a block cipher is secure to differential cryptanalysis. CBC mode requires unpredictable IV, and as the BEAST attack shows, chaining is a bad idea. RFC 3602 specifies using a random IV. Could you please cite minutes and an RFC, and maybe some more information so we can judge for ourselves?

marshray 13y ago
> The assumption is that a block cipher is secure to differential cryptanalysis. That assumption was not taken for granted back in the 90's. It was only with years of cryptanalysis of AES (which had had resistance to known plaintext an explicit design goal) that designers felt comfortable with things like CTR mode. In practice, we've learned that the block ciphers are by far the strongest part of the system, and it's the block cipher modes that provide the weakness for attackers. IMHO this is the type of poisoned knowledge that the US spies should be blamed for.
- diminish 13y ago
  ..isn't a good place to be paranoid the core of AES, namely substitution-permutation network hocus-pocus. (Joan Daemen' and Vincent Rijmen's). A backdoor transformation would suffice to make all other paranoia superfluous.
  - marshray 13y ago
    I'm not saying its impossible, but decades of public cryptanalysis have failed to produce a significant dent in the security of 3DES or AES. On the other hand, we've seen a total discrediting of LFSR-based schemes and a steady flow of issues resulting from the block modes (padding and timing oracles). We should be paranoid, but mostly that we might be not worrying about the right things.
    - diminish 13y ago
      You are right that padding/timing attacks on block modes and weaknesses in PRGs form the bulk of contemporary cryptanalysis. Nonetheless, if there is one single backdoor transform with a unique key on AES substitution-permutation network which would make further attacks possible, it would be nearly impossible to devise a adversary/challenge to reveal it using current cryptanalysis techniques. The standardization history for AES, and the organizations involved does not give much hope neither.

marshray 13y ago

An LFSR? Really? If this person was really NSA-qualified to recommend this stuff, he would have known that known plaintext was the least of your problems. I'm sorry, tytso. It sounds like you all got expertly socially engineered.

eps 13y ago
Elaborate?
- marshray 13y ago
  Discussion continued in other thread https://news.ycombinator.com/item?id=6347924 https://news.ycombinator.com/item?id=6347924
tptacek 13y ago
What's the attack you're thinking of against CBC with IVs drawn from an LFSR?
- anologwintermut 13y ago
  LFSRs are not cryptographically secure random number generators. So you can, given a few IVs, recover the internal state and predict all subsequent IVs. Then it's just a matter of mounting an (adaptive) chosen plaintext attack against the system knowing what the next IV will be. This is something you can't do against AES CBC mode if the IV is actually random. It fails in the same way if you use the last packet's cipher-text as the IV and there are pauses between packets.
  - tptacek 13y ago
    The point of using an LFSR for IV generation is that it allows you not to transmit the IV on every message. Can you go into more detail about how you, a passive observer, are collecting enough information to reverse the LFSR? (This is aside from the fact that we're talking about an extremely elaborate way to construct a CPA attack against a protocol that does not automatically give attackers chosen plaintext).