The "Great" in Great Britain never meant great as in supa-dupa.
It derives from the French "Grande" as in "big", referring to the Island of Britain as the larger part or Brittany, with the smaller part being Brittany in the North of France. This goes back to the Norman conquests, where the French though they owned it, but once they got there, the locals quickly absorbed them into the borg and they decided they were British after all.
Not all of them. For example in SP800-90 the AES-CTR-DRBG has publicly published proofs of its security. Also I understand the hash and hmac DRBGs to be secure but I've never read the proofs.
The sore thumb was the Dual-EC-DRBG which was suspect from day one and shown to have a back door in 2006.
I myself pointed out the back door in FIPS140-2 section 4.9.2 that I call the "FIPS Entropy Destroyer" and I refused to implement it and I've submitted comments to NIST to fix it in the spec.
SHA1 is broken. SHA2 is suspect. SHA3 seems good, but Skein would have been more secure and faster and easier to implement since the algorithm is so dividable that you can make small iterative implementations or really fast parallel implementations. So I'm suspect about the choice of Keccak.
HMAC-x seem fine, but block cipher MACs seem to have better foundations. SHA1 fell because it has a nasty block cipher in its core. Basing a MAC on a well analyzed block cipher seems to be far more sensible. So again, I'm suspect of the SHAs.
Yes. It's not the algorithm that's a problem. It's its vulnerability to sidechannel analysis, putting the key schedule through the same sequence each time.
In AES-CTR you use the same key in each block with a different, incrementing IV. Then XOR the output with the data.
This is algorithmically secure, because you would need more blocks than there are atoms in the universe to break the algorithm. However each time you invoke AES with the same key, the key schedule software or circuit goes through the same sequence, leaving it open to statistical sidechannel analysis or fault injection analysis.
I don't want to give the NSA the finger, or rather that's not my primary job. I do want to develop secure products regardless of the NSA, that make it into that hands of many people, who then enjoy secure computing without having to get involved in the fight. The NSA is a great help in some ways and an undermining force in other ways. As professionals we have to deal with that reality. Delivering secure solutions in mass market products is not just a technical problem. It involves politics, risk management and paranoid lawyers. ECC wins on the technical bit and screws the pooch on the other three. I'm not going to let those issues get in the way.
Saving a few bits on the stored key is not a good tradeoff with having to deal with all the people who don't have the technical knowledge to know what's right or wrong with ECC, but they've sure heard lots of FUD before.
Lots of algorithms are adequate. The challenge these days battling complexity in communication and computing standards that lead to vulnerable implementations.
FIPS 140-2 is a spec about boundaries. You draw a boundary and the spec talk about how data passed through the boundary and about the stuff that allowed inside the boundary.
One the primary things is asks is that the crypto algorithms are NIST approved. E.G. AES or SP800-90 or SHA1/2/3.
So to build a FIPS140-2 compliant thing, you first determine the box (the boundary) and the function. Then implement that function using crypto algorithms from the list of NIST approved algorithms.
Curve 25519, chacha20 and poly1305 do not appear in any NIST published specification.
If you pick only one variant of one algorithm for each of the algorithms types, the code is very small and simple and doesn't need to be in a library, that typically needs to support many configurations for many consumers.
If you have a crypto application, write your algorithm one way, once with no configuration or runtime variation. It will serve you well.
I'd sooner fix the symmetric crypto. That's more my area of expertise. But the point is well taken.
However one good algorithm is better than 3 choices in security critical applications like this. All that ciphersuite negotiation, build configuration and other stuff is just attack surface. So I don't know it would help to add RSA. It would help to pick RSA as the only asymmetric algorithm.
25519 is nice and all, but in the minds of people who have to make products, that's mostly because it deftly works around the very FUDy patent issues. The minutiae of the other benefits are not gating for 25519 or any other useful curve.
>it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks
Agreed. Don't use OpenSSL's RSA code. I'd choose to implement a fixed function, fixed key size, reasonably constant time RSA. Options in crypto software suck.
The AES key schedule can be computed inline with the round function, both for encrypt and decrypt. Computing the key schedule inline means that the state isn't left laying around in memory. Also, the majority of side channel attacks against key schedule rely on repeated behaviors. A simple principle that is a good mitigation is to never use the same key twice. Pre-computing the key schedule is only an optimization when you are using the same key repeatedly. So AES-CTR encourages both sins. Using the same key multiple times and then optimizing by keeping the key schedule state laying around.
The CTR mode is just a non-ideal PRF to generate bits that are XORed with the data. On each block the key is the same but the IV changes. The PRF is non ideal because no block will match (since AES or any other block cipher, with a fixed key is a bijective mapping) whereas in true random data, blocks may match with the usual statistical probability.
So if we picked a better block cipher based PRF, like say the SP800-90 AES-CTR-DRBG, both key and IV change on each step, so the output looks more like a real PRF and the key isn't used twice and so there's no incentive to optimize with a pre computed key schedule.
The inline computation is nice and simple and constant time. This is a particularly inefficient implementation, you can do better: void next_key(unsigned char *key, int round) {
unsigned char rcon;
unsigned char sbox_key[4];
unsigned char rcon_table[12] =
{
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
0x1b, 0x36, 0x36, 0x36
};
>Are these Hypercom terminals even less than $200?
Some are. On Amazon I've seen $70 terminals. Our model is $269 because adding an ethernet interface adds $200 to the price. Odd that since I just brought a 16 port switch to $70.
But to get one that works with the bank I have to get it from the bank and they charge their own price. Presumably they throw some secret numbers in there that any decent hacker could extract.
My wife has a retail store and a credit card reader.
If I wandered into the bank and asked how I get a C&P terminal for the store, they would stare at me blankly. It simply isn't available. The terminals exist, but the bank isn't going to talk to it until they're good an ready to, which at the current rate of progress is 'never'.
Target has more leverage, but small retailers have to take what the bank makes available.
For this and other reasons, we will probably switch banks, but people should be under the impression that retailers in the Us can 'just switch'. They can't. The bank decides which terminals it will work with. This is bizarre given that the terminals are completely generic.
Slashdot Mirror
>I'm pretty sure your historical facts are slightly wrong
That's why I work in tech.
The "Great" in Great Britain never meant great as in supa-dupa.
It derives from the French "Grande" as in "big", referring to the Island of Britain as the larger part or Brittany, with the smaller part being Brittany in the North of France. This goes back to the Norman conquests, where the French though they owned it, but once they got there, the locals quickly absorbed them into the borg and they decided they were British after all.
Not all of them. For example in SP800-90 the AES-CTR-DRBG has publicly published proofs of its security. Also I understand the hash and hmac DRBGs to be secure but I've never read the proofs.
The sore thumb was the Dual-EC-DRBG which was suspect from day one and shown to have a back door in 2006.
I myself pointed out the back door in FIPS140-2 section 4.9.2 that I call the "FIPS Entropy Destroyer" and I refused to implement it and I've submitted comments to NIST to fix it in the spec.
SHA1 is broken. SHA2 is suspect. SHA3 seems good, but Skein would have been more secure and faster and easier to implement since the algorithm is so dividable that you can make small iterative implementations or really fast parallel implementations. So I'm suspect about the choice of Keccak.
HMAC-x seem fine, but block cipher MACs seem to have better foundations. SHA1 fell because it has a nasty block cipher in its core. Basing a MAC on a well analyzed block cipher seems to be far more sensible. So again, I'm suspect of the SHAs.
Yes. It's not the algorithm that's a problem. It's its vulnerability to sidechannel analysis, putting the key schedule through the same sequence each time.
In AES-CTR you use the same key in each block with a different, incrementing IV. Then XOR the output with the data.
This is algorithmically secure, because you would need more blocks than there are atoms in the universe to break the algorithm.
However each time you invoke AES with the same key, the key schedule software or circuit goes through the same sequence, leaving it open to statistical sidechannel analysis or fault injection analysis.
Because when you invoke AES with the same key many times, you leave yourself more vulnerable to side channel and fault injection attacks.
Here: http://icanhazdigitalsecurity....
The NSA has been heavily promoting ECC.
>So start using ECC and give the NSA the finger
I don't want to give the NSA the finger, or rather that's not my primary job. I do want to develop secure products regardless of the NSA, that make it into that hands of many people, who then enjoy secure computing without having to get involved in the fight. The NSA is a great help in some ways and an undermining force in other ways. As professionals we have to deal with that reality. Delivering secure solutions in mass market products is not just a technical problem. It involves politics, risk management and paranoid lawyers. ECC wins on the technical bit and screws the pooch on the other three. I'm not going to let those issues get in the way.
Saving a few bits on the stored key is not a good tradeoff with having to deal with all the people who don't have the technical knowledge to know what's right or wrong with ECC, but they've sure heard lots of FUD before.
Lots of algorithms are adequate. The challenge these days battling complexity in communication and computing standards that lead to vulnerable implementations.
Apologies for the huge number of typos I managed to fit into that response.
That crap is years old and has been in many products. You'll find it in linux drivers.
That's the Dual-EC-DRBG that has magic numbers.
The 25519 spec describes the source of all the constants.
FIPS 140-2 is a spec about boundaries. You draw a boundary and the spec talk about how data passed through the boundary and about the stuff that allowed inside the boundary.
One the primary things is asks is that the crypto algorithms are NIST approved. E.G. AES or SP800-90 or SHA1/2/3.
So to build a FIPS140-2 compliant thing, you first determine the box (the boundary) and the function. Then implement that function using crypto algorithms from the list of NIST approved algorithms.
Curve 25519, chacha20 and poly1305 do not appear in any NIST published specification.
If you pick only one variant of one algorithm for each of the algorithms types, the code is very small and simple and doesn't need to be in a library, that typically needs to support many configurations for many consumers.
If you have a crypto application, write your algorithm one way, once with no configuration or runtime variation. It will serve you well.
I'd sooner fix the symmetric crypto. That's more my area of expertise. But the point is well taken.
However one good algorithm is better than 3 choices in security critical applications like this.
All that ciphersuite negotiation, build configuration and other stuff is just attack surface.
So I don't know it would help to add RSA. It would help to pick RSA as the only asymmetric algorithm.
25519, chacha20 and poly1305 are not FIPSable algorithms.
25519 is nice and all, but in the minds of people who have to make products, that's mostly because it deftly works around the very FUDy patent issues.
The minutiae of the other benefits are not gating for 25519 or any other useful curve.
But what it is not is mature. RSA is.
>it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks
Agreed. Don't use OpenSSL's RSA code. I'd choose to implement a fixed function, fixed key size, reasonably constant time RSA. Options in crypto software suck.
I don't like AES-CTR as a privacy mode for online communications and I don't like this
void
aesctr_keysetup(aesctr_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
x->rounds = rijndaelKeySetupEnc(x->ek, k, kbits);
}
The AES key schedule can be computed inline with the round function, both for encrypt and decrypt.
Computing the key schedule inline means that the state isn't left laying around in memory.
Also, the majority of side channel attacks against key schedule rely on repeated behaviors. A simple principle that is a good mitigation is to never use the same key twice.
Pre-computing the key schedule is only an optimization when you are using the same key repeatedly.
So AES-CTR encourages both sins. Using the same key multiple times and then optimizing by keeping the key schedule state laying around.
The CTR mode is just a non-ideal PRF to generate bits that are XORed with the data. On each block the key is the same but the IV changes.
The PRF is non ideal because no block will match (since AES or any other block cipher, with a fixed key is a bijective mapping) whereas in true random data, blocks may match with the usual statistical probability.
So if we picked a better block cipher based PRF, like say the SP800-90 AES-CTR-DRBG, both key and IV change on each step, so the output looks more like a real PRF and the key isn't used twice and so there's no incentive to optimize with a pre computed key schedule.
The inline computation is nice and simple and constant time. This is a particularly inefficient implementation, you can do better:
void next_key(unsigned char *key, int round)
{
unsigned char rcon;
unsigned char sbox_key[4];
unsigned char rcon_table[12] =
{
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
0x1b, 0x36, 0x36, 0x36
};
sbox_key[0] = sbox(key[13]);
sbox_key[1] = sbox(key[14]);
sbox_key[2] = sbox(key[15]);
sbox_key[3] = sbox(key[12]);
rcon = rcon_table[round];
xor_32(&key[0], sbox_key, &key[0]);
key[0] = key[0] ^ rcon;
xor_32(&key[4], &key[0], &key[4]);
xor_32(&key[8], &key[4], &key[8]);
xor_32(&key[12], &key[8], &key[12]);
}
Can we have it with Normal RSA for key agreement/key exchange?
Elliptic Curves are a minefield you need a degree in math to navigate. I prefer my crypto to be tractable.
>Are these Hypercom terminals even less than $200?
Some are. On Amazon I've seen $70 terminals. Our model is $269 because adding an ethernet interface adds $200 to the price. Odd that since I just brought a 16 port switch to $70.
But to get one that works with the bank I have to get it from the bank and they charge their own price. Presumably they throw some secret numbers in there that any decent hacker could extract.
But not the shitty Hypercom terminals you find in a large fraction of independent retailers.
>4% I doubt
Doubtless to know this, you must have better evidence.
So why not do the math, publish a paper refuting the logic of the paper that produced the 4% number?
I was under the impression PCI referenced 8583 and the transport wrapper. Maybe not. I'm not searching PCI specs for fun.
The wire protocols are standardized by PCI.
My wife has a retail store and a credit card reader.
If I wandered into the bank and asked how I get a C&P terminal for the store, they would stare at me blankly. It simply isn't available. The terminals exist, but the bank isn't going to talk to it until they're good an ready to, which at the current rate of progress is 'never'.
Target has more leverage, but small retailers have to take what the bank makes available.
For this and other reasons, we will probably switch banks, but people should be under the impression that retailers in the Us can 'just switch'. They can't. The bank decides which terminals it will work with. This is bizarre given that the terminals are completely generic.