Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Idea to encrypt stuff on the web at rest hits the IETF's Standard Track

Mozilla engineer spots a gap in online security, reaches for the patch kit

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 Architecture Board), first mooted in late 2015, has been updated and pushed into the IETF's Standard Track.

In RFC 8188, Thomson explains there are good reasons to encrypt data long after it has been exchanged between clients and servers.

If, for example, you may want to store files uploaded to a server encrypted with a particular key so that only the person, or people, with the necessary decryption key can unlock it. The data can be sent securely to the server via HTTPS but you may want to automatically keep it protected even when it's committed to disk. Rather than hoping that engineers remember to implement that level of security, Thomson hopes to embed the capability into applications with a standard specifying content coding for HTTP.

He also notes that it wasn't practical to adapt message-based encryption formats (he cites OpenPGP's RFC 4880, the Cryptographic Message Syntax in RFC 5652 and other examples) because those don't meet HTTP's need for stream processing. Rather, Thomson's RFC suggests using AES 128 in Galois/Counter Mode.

The scheme “only provides content-origin” authentication, the RFC notes, but that “ensures that an entity with access to the content-encryption key produced the encrypted data.” ®

 

Similar topics

TIP US OFF

Send us news


Other stories you might like