Categories

[Little Brosers] Crypto thoughts #1

[Little Brosers] Crypto thoughts

Please read the description of Little brosers to understand this post.

Whereas my teammates focused on merkle trees or android, I worked a little bit on encryption.

Goals

  • End to end encryption
  • authentication of both sides

Contraints

  • There is no handshake possible between two people before sending a message
  • Small key size (less BLE transfer => more battery life) (bye bye PGP)
  • Fast (actually low power consuming ) signature verification
  • each mobile app and drop must be able to verify each message, because we will have small memories in our drops, and thus we must be able to refuse every message which is not properly signed (or a denial of service would be too easy)

So we must encrypt then sign (It doesn’t work so easily, see later).

Using an existing protocol

Encrypt then sign not a common thing, and I don’t know any existing encryption protocol which does that (if you know one, please let me know).

I would like to use the Signal protocol (like Signal, WhatsApp,…), it features (wikipedia):

  • confidentiality
  • integrity
  • authentication
  • participant consistency
  • destination validation
  • forward secrecy
  • backward secrecy (aka future secrecy)
  • causality preservation
  • message unlinkability
  • message repudiation
  • participation repudiation
  • asynchronicity

I don’t think we could integrate it because of our constraints, and I believe it would be too hard to adapt it, but I will re-think about it.

Home-brewed crypto

It would be 100 times better to use an existing protocol, but I didn’t find one that satisfies our constraints. Hopefully we are in an academic context and we can make mistakes (and we will), so we can try to create our own crypto protocol.

For now, forget about features like forward secrecy.

We can’t encrypt then sign, because someone could re-sign the encrypted part and say it was his message. There are another problems (and sign then encrypt is also not completely safe), see http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html.

A solution is to sign, encrypt and then re-sign the message, the drop will only check the outer signature, whereas a phone will check the two signatures and verify that they are signed by the same person.

The other parts are common: AES with a mode of operation, RSA with a padding scheme (or another asymmetrical encryption algorithm), and a signature algorithm (RSA or ECDSA,  RSA has huge keys but is faster to verify a signature).

For now, the encryption looks like this:

Mode of operation and algorithms could change. I will add the size of keys later (it will be  approximately 128 bits of security).

I don’t think we need to use a MAC because the message is already signed.

For the public key infrastructure, we will use a certification authority which signs user certificates (through https) based on the username uniqueness, and another backend server will distribute the public keys to everybody. (more on that in a future post).

The drop will not have the time, we will talk of the implications and solutions later.

Please let me know if you have any idea of an existing protocol we could use, or any criticisms of our home-brewed crypto.