Won't this annoy the Five Eyes?
Idea to encrypt stuff on the web at rest hits the IETF's Standard Track
Amid the rise of HTTPS, there are still many spots where content shifted encrypted across the web is ultimately stored in wide-open plain text, so a Mozilla engineer wants to close one of those gaps. In an Internet Engineering Task Force RFC published this month, a proposal by Martin Thomson (also a member of the Internet …
COMMENTS
-
-
-
Tuesday 27th June 2017 08:05 GMT Anonymous Coward
it is absolutely vital and fundamentally needed to authenticate content
otherwise, the Daily Fail page that I am reading might be differently sourced/presented to the Daily Fail page that Maybotities/Corbynettes are reading, and they in their bubbles could see different pages/content. That way lies madness & chaos. All solved by a quick hash & confirm. Sir Tim, get on it!
Five Eyes TLA have a job to do , and they could still do it when all webpages are authenticated, but it might stop the online bandits with even less morals
-
Tuesday 27th June 2017 06:46 GMT John Smith 19
Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me
But how good is the security with HTTPS?
The real challenge for effective privacy with TCP/IP will be the routing data.
How the f**k do you encrypt routing data (IE The headers) but still make them usable?
-
-
Thursday 29th June 2017 12:17 GMT John Smith 19
"The real challenge for effective privacy with TCP/IP will be the routing data."
The best I can come up with was some kind of token which is compared when the packet gets to its destination (matching token == destination) and a return token that indicates a "direction" in which the packets needs to "diffuse" in order to get it nearer to its destination, rather than an actual path to follow.
Sadly I have no idea how you'd encode that idea of "direction" or wheather that "token" should be the same for all packet streams going to or from the same end point, or different ones for each different session with that end point, or how you stop MIM attacks by token spoofing etc. Not to mention sizing this so it can accommodate the size of the internet, as well as allowing for future growth.
Basically I'm just not smart enough to figure out how to solve this problem.
But I really hope someone can....
-
-
Tuesday 27th June 2017 08:05 GMT Anonymous Coward
"Using this content coding requires knowledge of a key. How this key is acquired is not defined in this document."
So, a particular client can PUT an encrypted file or GET an encrypted file, but this is only useful if the symmetric key has been previously agreed with the server or content owner.
It would probably be simpler to use an application/pgp MIME type.
The advantage of the mechanism in this RFC is that some limited random access to the encrypted content is possible.
-
Wednesday 28th June 2017 21:32 GMT Mark 65
AES 128
Rather, Thomson's RFC suggests using AES 128 in Galois/Counter Mode.
By choosing AES 128, and given the amount of time this may take to come to fruition, are we not MD5/SHA1-ing ourselves here? It's just possible by the time this gets implemented AES 128 is not as safe as it used to be. Given the amount of processor power available in just about any chip these days, especially when you can have embedded AES circuitry, should we not be shooting for AES 256 just to be on the safe side?