Live data from Hacker News

Calling NSA to find your encryption key after a few bits were flipped (2010)

astroengineer.wordpress.com

111–120 of 125 posts

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#111
post #35

Earlier quoted context omitted.

It's your error, having a system with important data no actual/realtime backup no second system and no plan to recover from a failed update and no ecc is YOUR error alone. However, intel should have made ecc the standard and not just for 1000$+ Xeons.

"It's your error, having a system with important data no actual/realtime backup" Have you ever taken picture of anything important with your phone, like a crime, or a car accident? Have you ever called 911 or sent money? How dare you use an unreliabke system without ECC, what if a random bitflip would cause it to send 10x more money or data woupd be lost without realtime backup! This disrespect to users and wanky att…

>Have you ever taken picture of anything important with your phone, like a crime, or a car accident? Have you ever called 911 or sent money?

I don't compare my phone to a server (24x7) with 10000$ worth of data, but even if i do i would make a versioned backup every X minutes, especially before "updates".

But yes phones should have ecc too.

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#112
post #71
post #35

Earlier quoted context omitted.

It's your error, having a system with important data no actual/realtime backup no second system and no plan to recover from a failed update and no ecc is YOUR error alone. However, intel should have made ecc the standard and not just for 1000$+ Xeons.

It's turtles all the way down, sadly. The bitflip could have hit an OS distribution service. Yes, the target machines should check the checksum, but the distribution service could have flipped the bit before the checksum was computed. But, yeah, ECC should be the standard. Also, Intel should be better about documenting where they've left holes in their online checksums, machine check exception implementations, etc.

>The bitflip could have hit an OS distribution service.

No because the updates are signed (integrity).

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#113

Earlier quoted context omitted.

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

SSDs have a lot more aggressive error correction than most filesystems because they anticipate a high error rate and are constantly changing the map of logical blocks to physical blocks. Tapes at rest don't have to worry about that though.

> SSDs have a lot more aggressive error correction than most filesystems

Most filesystems do not do any error correction. ZFS, btrfs, ReFS, bcachefs are a few notable exceptions. And for the most part these schemes are for multiple device resilience - which is architected quite differently from the schemes used in an SSD or tape (yes, even tape).

> Tapes at rest don't have to worry about that though.

This isn't really true. Pretty much every physical medium at the densities used in modern time requires robust error correction because all physical media has flaws either manufactured or acquired from wear and degradation. For instance, modern LTO tapes use relatively robust 2D Reed-Solomon forward error correction similar to DVD/Blu-Ray.

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#114
post #109

Can a cosmic rays flip 0’s to 1’s and visa versa, or just in in one direction? Edit: I am thinking of memory chips

I think only 1 to 0, as the cosmic ray cause electrons to "discharge" hence lowering the voltage, assuming that 1 is a little bit higher voltage than 0. But far from an expert in electronics and physics :)

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#115
post #111

Earlier quoted context omitted.

"It's your error, having a system with important data no actual/realtime backup" Have you ever taken picture of anything important with your phone, like a crime, or a car accident? Have you ever called 911 or sent money? How dare you use an unreliabke system without ECC, what if a random bitflip would cause it to send 10x more money or data woupd be lost without realtime backup! This disrespect to users and wanky att…

>Have you ever taken picture of anything important with your phone, like a crime, or a car accident? Have you ever called 911 or sent money? I don't compare my phone to a server (24x7) with 10000$ worth of data, but even if i do i would make a versioned backup every X minutes, especially before "updates". But yes phones should have ecc too.

I do, because a picture of the criminal might be worth more than $10,000, or you might have to call an ambulance and your life is worth something

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#116

Earlier quoted context omitted.

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.

> Filesystems keep checksums of every block of data. False. A limited number of filesystems keep checksums of data - most notably ZFS and btrfs. Some like ext4 and APFS will do it for metadata only. One of the most commonly used filesystems, NTFS, does not for either data or metadata. > Typically it's done at the filesystem level or higher, including when using self-encrypting drives. I don’t know where you got this…

Those filesystems (ZFS, BTRFS) have robust error correction, but every modern filesystem has checksums for every block. Checkdisk isn't powered by magic.

Also, look into TCG Pyrite. Almost all consumer drives with SED features are Pyrite.

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#117
post #111

Earlier quoted context omitted.

>Have you ever taken picture of anything important with your phone, like a crime, or a car accident? Have you ever called 911 or sent money? I don't compare my phone to a server (24x7) with 10000$ worth of data, but even if i do i would make a versioned backup every X minutes, especially before "updates". But yes phones should have ecc too.

I do, because a picture of the criminal might be worth more than $10,000, or you might have to call an ambulance and your life is worth something

>I do, because a picture of the criminal might be worth more than $10,000, or you might have to call an ambulance and your life is worth something

He had the chance to have a good solution and decided it's not worth it, that's the difference.

>and your life is worth something

Restart your phone.

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#118
post #39

Earlier quoted context omitted.

Article says "which was only a handful of bits away from the original". As non-native speaker i don't know the exact nuance of handful when considering bits, but it seems a lot

No a handful in this abstract context (strengthened by the word “only”) means not so many (which given even the power of the computers at the disposal of the NSA at the time was enough to ruin your 2 weeks).

More like a pinch of bits, then?

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#119

Earlier quoted context omitted.

Bit flips are quite useful for sorting huge arrays of data: https://news.ycombinator.com/item?id=28766154

That's not a proper sort. A sort is not just a function that takes in a list and returns a list that is sorted. The result must also include all of the elements that you had when starting. That property isn't checked by the code you linked.

You're arguing that the code that uses internal failure as functionality is invalid?

Damn, I wish I had your kind of expertise.

Re: Calling NSA to find your encryption key after a few bits were flipped (2010)

#120

Earlier quoted context omitted.

> Filesystems keep checksums of every block of data. False. A limited number of filesystems keep checksums of data - most notably ZFS and btrfs. Some like ext4 and APFS will do it for metadata only. One of the most commonly used filesystems, NTFS, does not for either data or metadata. > Typically it's done at the filesystem level or higher, including when using self-encrypting drives. I don’t know where you got this…

Those filesystems (ZFS, BTRFS) have robust error correction, but every modern filesystem has checksums for every block. Checkdisk isn't powered by magic. Also, look into TCG Pyrite. Almost all consumer drives with SED features are Pyrite.

> but every modern filesystem has checksums for every block.

At least 2 people have informed you that you’re wrong. Now it’s up to you if you choose to educate yourself on this topic or remain a fool.

> Checkdisk isn't powered by magic.

What is “checkdisk”? If you’re talking about chkdsk, or Check Disk, or fsck like tools - none of those require checksums to do what they do. At a basic level they check the integrity of on disk data structures - the actual connectivity, valid counts, etc. How in your mind does a checksum contribute to this task?

Chkdsk exists for FAT32, which you already seem to admit has no checksums. How do you think it works?

> Also, look into TCG Pyrite. Almost all consumer drives with SED features are Pyrite.

What does this have to do with anything - it certainly isn’t filesystem level encryption.

Post reply on HN