Skip to content

Latest commit

 

History

History
67 lines (49 loc) · 2.96 KB

README.md

File metadata and controls

67 lines (49 loc) · 2.96 KB

0020: Encryption Primitives

  • Author: Kyle Den Hartog
  • Start Date: July 6th, 2018

Status

  • Status: ADOPTED
  • Status Date: (date of first submission or last status change)
  • Status Note: (explanation of current status; if adopted, links to impls or derivative ideas; if superseded, link to replacement)

Summary

This HIPE describes two important crypto primitives that underpin Indy's secure communications strategy: anon_crypt and auth_crypt.

Motivation

anon_crypt is an API level call that will be available within Hyperledger Indy in order to meet the following requirements:

  • Encrypt a payload
  • verify the integrity of the message with an HMAC

auth_crypt is an API level call that will be available within Hyperledger Indy in order to meet the following requirements:

  • Encrypt a payload
  • verify the integrity of the message with an HMAC
  • verify the sender of the message in a repudiable way

Tutorial

anon_crypt

anon_crypt currently follows this pattern:

  1. generate random ed25519 keys pair
  2. get the ed25519 public key of receiver
  3. call DH(random_priv_key, receiver_pub_key, random_nonce) to produce SYMMETRIC key
  4. encrypt the message with SYMMETRIC key
  5. add MAC
  6. Return tuple (encrypted message, MAC, random_pub_key, random_nonce)

auth_crypt

auth_crypt currently follows this pattern:

  1. get sender ed25519 key pair
  2. get the ed25519 public key of receiver
  3. call DH(sender_priv_key, receiver_pub_key, random_nonce) to produce SYMMETRIC key
  4. encrypt the message with SYMMETRIC key
  5. add MAC
  6. Get tuple (encrypted message, MAC, random_nonce)
  7. Add sender public key and anon_crypt the whole message

Drawbacks

Perfect Forward secrecy is currently not implemented with auth_crypt because it relies upon a non-ephemeral Diffie-Hellman key exchange to generate the symmetrical key.

Rationale and alternatives

anon_crypt is built from a reputable library that handles the crypto primitives for us. This means it's more likely to be a secure implementation of cryptography.

An alternative solution for auth_crypt, that would be more restrictive but easier to understand, would be to perform a non-repudiable signature on the message before encrypting and adding the signature field to the plaintext of the message before encryption. The downsides to this is that it provides more data than is necessary for the general usecase, so repudiable authentication was the better choice. This allows for a person to add a non-repudiable signature optionally as well.

Prior art

anon_crypt has been built from Libsodium's sealed_box. auth_crypt has been built from Libsodium's crypto_box with some minor tweaks.

Unresolved questions

None; this is already implemented. This HIPE is being submitted to describe what we have.