Google Decides Not To Use Speck For Disk Encryption, Instead Developing HPolyC

[phoronix]

Phoronix: Google Decides Not To Use Speck For Disk Encryption, Instead Developing HPolyC

While the controversial Speck crypto support was added to Linux 4.17 and with Linux 4.18 it's being exposed via fscrypt for a disk encryption option, which Google intended to be used on low-end "Android Go" devices that don't have CPUs with capable native encryption extensions, instead Google is backtracking...

http://www.phoronix.com/scan.php?page=news_item&px=No-Speck-Yes-HPolyC-Encryption

[davidbepo]

it was obvious before but now its even clearer, this speck cipher has a backdoor, a shame it was accepted on the kernel

[microcode]

it was obvious before but now its even clearer, this speck cipher has a backdoor, a shame it was accepted on the kernel

Well, there's lots of crap you shouldn't be using in the kernel. Ultimately at the time the upstream had no particular reason to reject Speck at the time. With the suspicious circumstances of its development and promotion now well known, it is unlikely it would be accepted today.

The terms Eric uses to describe this "construction" (I think he means construct) are encouraging, I look forward to seeing what third party experts think of this mode.

[chithanh]

With the suspicious circumstances of its development and promotion now well known, it is unlikely it would be accepted today.

No. No new information/results/facts about Speck have emerged since it was accepted into the mainline kernel. Just the discussion has progressed.

Ideally, such discussion would happen before mainline kernel inclusion, but at least there is the chance to drop fscrypt support for it before 4.18 release (after which it would be basically enshrined there forever due to kernel policy).

[Danniello]

LOL. It is silly. Google will not use "controversial" cryptography algorithm created by government agency. It is like say that military company will not use "controversial" ammo, because it was created by government - instead they will use ammo created by themselves, because it will be more humanitarian for victims

Google do not need cryptography with "backdoors", because parent elements of their systems are fully controlled by them. Like Google Play Services - it is fully remotely controlled with "root" privileges. User do not have such power (without unlock/root phone). Owner of Android phone in reality is only tenant of their system.

[Weasel]

LOL. It is silly. Google will not use "controversial" cryptography algorithm created by government agency. It is like say that military company will not use "controversial" ammo, because it was created by government - instead they will use ammo created by themselves, because it will be more humanitarian for victims

Google do not need cryptography with "backdoors", because parent elements of their systems are fully controlled by them. Like Google Play Services - it is fully remotely controlled with "root" privileges. User do not have such power (without unlock/root phone). Owner of Android phone in reality is only tenant of their system.

It's something called Public Relations.

[ssokolow]

Google do not need cryptography with "backdoors", because parent elements of their systems are fully controlled by them. Like Google Play Services - it is fully remotely controlled with "root" privileges. User do not have such power (without unlock/root phone). Owner of Android phone in reality is only tenant of their system.

Yes, but Google did discover that the NSA had been tapping the private fiber-optic lines between their data centers without any kind of information request. That's why they now even encrypt traffic on lines that aren't supposed to be public and are made difficult to tap because of the technology used. There is still a difference between "Google can" and "The NSA can", even if it's just Google getting in a snit about not being warned first.

[microcode]

Google do not need cryptography with "backdoors", because parent elements of their systems are fully controlled by them. Like Google Play Services - it is fully remotely controlled with "root" privileges. User do not have such power (without unlock/root phone). Owner of Android phone in reality is only tenant of their system.

This is a full disk encryption mode, not a DRM mechanism. It exists to prevent your data from being read without credentials, on your device, and not only that: they're giving it away to you without prejudice, even if you don't buy anything from them or see any of their ads.

[torsionbar28]

Yes, but Google did discover that the NSA had been tapping the private fiber-optic lines between their data centers without any kind of information request. That's why they now even encrypt traffic on lines that aren't supposed to be public and are made difficult to tap because of the technology used. There is still a difference between "Google can" and "The NSA can", even if it's just Google getting in a snit about not being warned first.

Honestly, at this point I trust the NSA a lot more than I trust Google. Assuming both entities posses my data.

The NSA is concerned only with potential criminal activity, and more specifically international criminal activity not US citizens. NSA goes to great lengths to be secretive and clandestine about that, and while it gathers in bulk, it does not share it.

Google has no such restrictions, and will (and does) happily sell your data to the highest bidder, and will use it absolutely any way it can to monetize it, selling it to foreign and domestic entities. No thanks. Of course you agree to all of this when you enroll in "free" services like Gmail, Youtube, etc....