Is there a way to embed redundancy in a crypto key so that another key a few bits away can still decrypt the data?
Calling NSA to find your encryption key after a few bits were flipped (2010)
21–30 of 125 posts
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#22Bit flips are scary even on Earth. At a previous job, we had a customer who suddenly couldn’t send us email anymore. When their IT sent us the server logs to “prove” it’s our fault, we saw that the one letter in the cached MX record was wrong. This was puzzling, until I looked at the ASCII table to verify that the difference was exactly one bit. We never found out where in the name resolution process the bit got flip…
I have super bivalent opinions about Intel. This is the opposite of ambivalent, it means heavily charged in both directions, but cancellation is not allowed.
So that's why they should have let all their chips do ECC instead of making it a premium feature, it would have been better for their brand as "Chipzilla" and had no real cost. And it's dangerous! In fact a soft-error at sea level killed an operating system update on me, lost about tens of thousands of data and money. I have standing to sue Intel, until this sentence clause in which I hereby forfeit the suit, together with requesting them to reconsider ECC (error correction codes) in all their chips as a safeguard needed due to Moore's Law, which was their business plan. Just give it a thought, Intel.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#23Earlier quoted context omitted.
This is taken care of at the filesystem level.
Can you explain what you mean by that?
Filesystems keep checksums of every block of data. If single bits are flipped then they can be corrected. If you encrypt at a lower level than the filesystem then you're at the mercy of that lower level's error correction, but in practice it is rare to encrypt at a lower level. Typically it's done at the filesystem level or higher, including when using self-encrypting drives.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#24Is there a way to embed redundancy in a crypto key so that another key a few bits away can still decrypt the data?
DES (and TDES) has 1 parity bit for every 7 bits of key. Nobody really uses it as far as I've seen (e.g. they just generate random keys with invalid parity), but it's built in to the key itself.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#25Earlier quoted context omitted.
This is taken care of at the filesystem level.
Can you explain what you mean by that?
Correctly configured RAID setups also make it possible to detect and recover errors across drives & data without downtime, this is commonly how it's done in datacenters.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#26I'm kind of surprised that this took "two weeks, a stable of computers, and billions of combinations tested"? If we make the (generous) assumption that this was using a 128-bit key (more than was common in 1993—the age of DES and 56-bit keys, unless you were using public key crypto – which would be a very strange choice for a military satellite), we have:
256 (2 * 128) keys with 1 bit different
32,512 (2^2 * 128 choose 2) keys with 2 bits different
2,731,008 (2^3 * 128 choose 3) keys with 3 bits different
170,688,000 (2^4 * 128 choose 4) keys with 4 bits different
8,466,124,800 (2^5 * 128 choose 5) keys with 5 bits different
So to reach billions of combinations you need 5 bitflips, which seems quite high! But I guess space is a pretty rough environment :)
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#27Bit flips are scary even on Earth. At a previous job, we had a customer who suddenly couldn’t send us email anymore. When their IT sent us the server logs to “prove” it’s our fault, we saw that the one letter in the cached MX record was wrong. This was puzzling, until I looked at the ASCII table to verify that the difference was exactly one bit. We never found out where in the name resolution process the bit got flip…
Happens even on end user browsers resulting in bit-flipped domains being looked up: https://securitee.org/files/bitsquatting_www2013.pdf
Bitsquatting is a great name. I’m not 100% that this isn’t just typosquatting though.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#28Is there a way to embed redundancy in a crypto key so that another key a few bits away can still decrypt the data?
Encode it for storage with FEC.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#29Always sucks to put into place a triple-redundant system, and a cosmic ray finds the one weak link that wasn't redundant. Space isn't for the faint-hearted.
Re: Calling NSA to find your encryption key after a few bits were flipped (2010)
#30Earlier quoted context omitted.
Can you explain what you mean by that?
Filesystems keep checksums of every block of data. If single bits are flipped then they can be corrected. If you encrypt at a lower level than the filesystem then you're at the mercy of that lower level's error correction, but in practice it is rare to encrypt at a lower level. Typically it's done at the filesystem level or higher, including when using self-encrypting drives.
> If you encrypt at a lower level than the filesystem then you're at the mercy of that lower level's error correction, but in practice it is rare to encrypt at a lower level.
My understanding is that many SSDs do encryption transparently. The ATA protocol even has a “SECURE ERASE” command that instructs the drive to wipe just the encryption key. This allowed even “bad blocks” to be erased securely.