Profile cover photo
Profile photo
Soumya Roy
Soumya's posts

Post has attachment
Marvelous job by the Chrome 32 team to optimize for mobile web sites...

Post has attachment
Chrome Dev Summit, Live.

Post has shared content
A Sneak Peak to help developers build great Glassware with the Mirror API
Developers have started building great Glassware with the Mirror API and today will have even broader access to Glass with a Sneak Peek of the Glass Development Kit.  Here's a recording of the announcement earlier today in our San Francisco Basecamp.

You can download the library and learn more about the GDK here:

The full GDK Developer Preview will be available in the coming weeks.  We can’t wait to start working on this next chapter of Glass Development with you.

Post has shared content
Here is the official GDG India Page ! This will help you track all the activities, announcements & events by GDGs across India.

#gdg   #gdgIndia  

Post has shared content

Post has shared content
Look out for an exciting event towards Google Cloud Developer challenge!
Got an interesting web app idea?  Nurture it, code it, and win some big prizes from Google.

#gcdc   #gdgbangalore

Post has shared content
Nice overview of the problems and promise of building artificial intelligence systems, featuring +Yann LeCun among others.

Post has shared content
Nice overview of the problems and promise of building artificial intelligence systems, featuring +Yann LeCun among others.

Post has shared content
Nice overview of the problems and promise of building artificial intelligence systems, featuring +Yann LeCun among others.

Post has shared content
Authenticated Encryption.
On the limits of the use cases for authenticated encryption

What is authenticated encryption?

“Authenticated Encryption” is an abstraction that is getting a lot of attention among cryptographers and crypto programmers nowadays. Authenticated Encryption is just like normal (symmetric) encryption, in that it prevents anyone who doesn't know the key from learning anything [*] about the text. The "authenticated" part is that it also prevents anyone who doesn't know the key from undetectably altering the text. (If someone who doesn't know the key does alter the text, then the recipient will cleanly reject it as corrupted rather than accepting the altered text.)

It is a classic mistake for engineers using crypto to confuse encryption with authentication. If you're trying to find weaknesses in someone's crypto protocol, one of the first things to check is whether the designers of the protocol assumed that by encrypting some data they were preventing that data from being undetectably modified. Encryption doesn't accomplish that, so if they made that mistake, you can attack the system by modifying the ciphertext. Depending on the details of their system, this could lead to a full break of the system, such that you can violate the security properties that they had intended to provide to their users.

Since this is such a common mistake, with such potentially bad consequences, and because fixing it is not that easy (especially due to timing and exception-oracle attacks against authentication schemes), cryptographers have studied how to efficiently and securely integrate both encryption and authentication into one package. The resulting schemes are called “Authenticated Encryption” schemes.

In the years since cryptographers developed some good authenticated encryption schemes, they've started thinking of them as a "drop-in replacement" for normal old unauthenticated encryption schemes, and started suggesting that everyone should use authenticated encryption schemes instead of unauthenticated encryption schemes in all cases. There was a recent move among cryptographers, spearheaded by the estimable Daniel J. Bernstein, to collectively focus on developing new improved authenticated encryption schemes. This would be a sort of community-wide collaboration, now that the community-wide collaboration on secure hash functions—the SHA-3 contest—is coming to an end.

Several modern cryptography libraries, including “Keyczar” and Daniel J. Bernstein's “nacl”, try to make it easy for the programmer to use an authenticated encryption mode and some of them make it difficult or impossible to use an unauthenticated encryption mode.

When Brian Warner and I presented Tahoe-LAFS at the RSA Conference in 2010, I was surprised and delighted when an audience member who approached me afterward turned out to be Prof. Phil Rogaway, renowned cryptographer and author of a very efficient authenticated encryption scheme ("OCB mode"). He said something nice about our presentation and then asked why we didn't use an authenticated encryption mode. Shortly before that conversation he had published a very stimulating paper named “Practice-Oriented Provable Security and the Social Construction of Cryptography”, but I didn't read it until years later. In that fascinating and wide-ranging paper he opines, among many other ideas, that authenticated encryption is one of “the most useful abstraction boundaries”.

So, here's what I wish I had been quick-witted enough to say to him when we met in 2010: authenticated encryption can't satisfy any of my use cases!

Tahoe-LAFS access control semantics

I'm one of the original and current designers of the Tahoe-LAFS secure distributed filesystem. We started out, in 2006, by choosing the access control semantics that we wanted to offer our users and that we knew how to implement. Here's what we chose:

There are two kinds of files: immutable and mutable. When you write a file to the filesystem you can choose which kind of file it will be in the filesystem. Immutable files can't be modified once they have been written. A mutable file can be modified by someone with read-write access to it. A user can have read-write access to a mutable file or read-only access to it, or no access to it at all.

In addition to read-write access and read-only access, we implement a third, more limited, form of access which is "verify-only" access. You can grant someone the ability to check the integrity of your ciphertexts without also granting them the ability to decrypt it.

This is useful in the modern cloudy world, because with it you can delegate the job of auditing and repairing your files to a third party without becoming vulnerable to that party reading your files.

(You can read a one-page summary of the Tahoe-LAFS design here: , a more detailed explanation of the access control semantics here: , and a six-page paper about the way it is implemented with cryptography here: .)

Can't be implemented with authenticated encryption!

This seems like a small, useful set of concepts which users can understand and employ. It doesn't do everything that everyone wants, but I think that it has a certain elegance, and also it has stood the test of time and has served many users well.

Now, here are three consequences of the above design:

1. I can authorize you to check the integrity of a file (ciphertext) without authorizing you to read it.

2. I can authorize you to check the integrity of a file without authorizing you to change its contents.

These two are necessary for the use case mentioned above: delegating the job of monitoring and repairing your data to some third party who is not allowed to read your data.

3. I can authorize you to read a file without authorizing you to change its contents.

This one is necessary to implement both the immutability property of immutable files (nobody can change the contents, although verifiers and readers can check the integrity of the contents), and the authenticity property of mutable files (readers or verifiers can't change the contents, although they can verify the correctness of the contents).

As far as I can tell, authenticated encryption cannot be used to implement these properties.

What does this imply for other users of cryptography?

I'm not sure if the Tahoe-LAFS design is sort of the odd duck, and all the rest of the world should go ahead and upgrade from unauthenticated encryption to authenticated encryption, or if this mismatch is a warning sign. Maybe authenticated encryption isn't the most useful abstraction boundary after all.

Maybe we should have a conversation about which abstractions benefit our users. I think it helps to work “top-down”, from use cases (e.g. one-to-one chat, group chat, file-sharing, web hosting, live file-editing collaboration, streaming video, voice, etc.) to desired semantics, and then to the security properties of protocols. So far I think the enthusiasm for authenticated encryption has been somewhat “bottom-up”—after we all witnessed the repeated mistake of relying on encryption for authentication, we invented a way to prevent that, and then started thinking that we should apply the solution to all uses.

[*] Except they get to learn the length of it, depending on your padding. And of course they get to learn from where and to where it was transmitted, and when, depending on how your comms work. That's called "traffic analysis" and it is often the most valuable information to the attacker anyway.
Wait while more posts are being loaded