Public-key encryption in Chrome?

[Mehrdad Niknami]

Hi all,

I was wondering, what are the best way(s) to perform public-key
encryption/decryption in Chrome (outside the context of SSL)?
I'm working on a feature with which I will need to encrypt and decrypt
data sent to/from a server, but it is unrelated to SSL or any network-
layer protocol.
(I tried looking at OpenSSL, but it doesn't seem to compile well.)

Thanks!

[Albert Bodenhamer]

To add a bit more color:

Mehrdad is working on an intern project to allow documents submitted to Cloud Print to be encrypted before submission and then decrypted at the printer so that they pass through GCP in an encrypted state.  The goal is to allow users who might be concerned about sensitive documents passing through Google's servers to use Cloud Print.  The initial proof-of-concept is to submit an encrypted job from Chrome and then to decrypt it in the GCP connector in order to print it.  Public key seems to make the most sense for this use-case.

Thanks.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

--
Albert Bodenhamer | Software Engineer | abodenha@chromium.org 

[Adam Langley]

On Tue, May 29, 2012 at 2:45 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:
> I was wondering, what are the best way(s) to perform public-key
> encryption/decryption in Chrome (outside the context of SSL)?
> I'm working on a feature with which I will need to encrypt and decrypt
> data sent to/from a server, but it is unrelated to SSL or any network-
> layer protocol.

See src/crypto/*.h, i.e. rsa_private_key.h.


Cheers

AGL

[Adam Langley]

On Tue, May 29, 2012 at 2:51 PM, Albert Bodenhamer
<abod...@chromium.org> wrote:
> Mehrdad is working on an intern project to allow documents submitted to
> Cloud Print to be encrypted before submission and then decrypted at the
> printer so that they pass through GCP in an encrypted state.

Mehrdad, please make sure to write up your proposed design and run it
by wtc, rsleevi and myself. Making crypto protocols by mixing together
crypto primitives has a long history of leading to devastating design
flaws.


Cheers

AGL

[Albert Bodenhamer]

See src/crypto/*.h, i.e. rsa_private_key.h.

We found that.  It looks like it has code for creating/managing keys but everything we're finding to actually encrypt things is expecting symmetric keys.

Thanks.

Absolutely.  We're still figuring out what pieces we have to work with and putting together rough ideas.  We'll put together a DD and do a full security review before we actually build anything.

 

Cheers

AGL

[Adam Langley]

On Tue, May 29, 2012 at 3:38 PM, Albert Bodenhamer
<abod...@chromium.org> wrote:
> We found that.  It looks like it has code for creating/managing keys but
> everything we're finding to actually encrypt things is expecting symmetric
> keys.

It's quite possible that everything that we currently have does
signatures rather than encryption. But, for example,
signature_verifier* demonstrates the code that would be needed.


Cheers

AGL

[Mehrdad Niknami]

Thanks for the heads up, we'll make sure to get a full review.

Regarding signature_verifier: thanks, I'll take a look at it.
Hopefully it has some information available for figuring out how to
get encryption working.

Mehrdad

[Mehrdad Niknami]

Yup, I was looking at that earlier today... but I can't find any
encryption functionality, only directly key-related functionality.

[Ryan Sleevi]

On Tue, May 29, 2012 at 3:40 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:

Yup, I was looking at that earlier today... but I can't find any
encryption functionality, only directly key-related functionality.

Hi Mehrdad,

It's generally very bad practice (security and performance) to directly encrypt any sizable data with a private key. What people typically refer to by "public/private key encryption" is actually a form of key wrapping. A cryptographically strong, random number is generated to be used as a symmetric key. This symmetric key is then encrypted with the peer's public key, a process known as key wrapping. Only people which possess the private key can unwrap the wrapped/encrypted symmetric key.

At this time, there is no code for key wrapping within crypto/, because that has not been needed. Currently, the only supported public/private operations are signing data with a private key (crypto::SignatureCreator), which can be verified by anyone with the public key (crypto::SignatureVerifier). We do support symmetric encryption (crypto::Encryptor) and key generation. We also have code for ephemeral key derivation (crypto::P224EncryptedKeyExchange) as an alternative means of deriving a shared symmetric key, as well as PBKDF2-based symmetric key password derivation (crypto::SymmetricKey::DeriveFromPassword).

Before worrying about how to implement public/private key wrapping (which isn't that much of a big deal), a design document would be useful to help determine the threat modelling and what the appropriate crypto primitives are. For example, key wrapping may be completely inappropriate if there isn't a secure means to exchange key pairs - a bootstrapping problem not easily solved.

You may find that it's easier from an implementation point to first start with either the EKE/SPAKE method or the PBKDF2 method, both of which allow you to take a password and expand it into keying material. However, again, please write up a design doc first :-)

 

On May 29, 11:51 am, Adam Langley <a...@chromium.org> wrote:
> On Tue, May 29, 2012 at 2:45 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:
> > I was wondering, what are the best way(s) to perform public-key
> > encryption/decryption in Chrome (outside the context of SSL)?
> > I'm working on a feature with which I will need to encrypt and decrypt
> > data sent to/from a server, but it is unrelated to SSL or any network-
> > layer protocol.
>
> See src/crypto/*.h, i.e. rsa_private_key.h.
>
> Cheers
>
> AGL

[Mehrdad Niknami]

Wow thanks for the detailed reply! That explains sense; I'll try to
figure out those design issues first then.

Thanks again,
Mehrdad

[Mehrdad Niknami]

Sorry, that was supposed to say "that makes sense", typo. :-)

One question:
If there is no way to currently wrap key pairs, then how does Chrome
send encrypted data to a secure server?
i.e. Wouldn't it need to create a symmetric key using the server's
public key, in order to be able to send over encrypted data? Or is
there a different mechanism involved that creates a symmetric key
without using public key encryption?

Thanks,
Mehrdad

[Ryan Sleevi]

On Tue, May 29, 2012 at 4:23 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:

Sorry, that was supposed to say "that makes sense", typo. :-)

One question:
If there is no way to currently wrap key pairs, then how does Chrome
send encrypted data to a secure server?
i.e. Wouldn't it need to create a symmetric key using the server's
public key, in order to be able to send over encrypted data? Or is
there a different mechanism involved that creates a symmetric key
without using public key encryption?

Thanks,
Mehrdad

Depends :-)

You specifically asked outside of the context of SSL; generally, Chrome uses SSL for any secure exchanges. SSL with RSA key pairs generally works via key-wrapping, although depending on the ciphersuite may use key derivation (ECDH/DH), with RSA being used to authenticate the messages. That's probably another story for another day though :-)

There are several other pieces in Chrome that build on the primitives found within crypto/, but they've generally not need key wrapping as much as password-based key derivation (PBKDF or SPAKE), neither of which require key pairs. For example, Sync uses Nigori ( http://www.links.org/files/nigori-protocol.html , http://code.google.com/searchframe#OAMlx_jo-ck/src/sync/util/nigori.h&type=cs&l=19 ), which uses PBKDF2 as one of the basic primitives to build a full protocol on top of.

However, simply because others do it via X doesn't mean that it's appropriate for your solution to do X. If your not sure as far as what primitives to use or which might be appropriate, putting together a document with the security needs, anticipated threats, and UX concerns is a good way to get closer to the right set.

Like Adam said, combining the wrong primitives can be disastrous to security, so early design reviews are the best way to make solid progress.