From 02531c68e0b3bdbc418c7ef3eba4565fbeb46bbb Mon Sep 17 00:00:00 2001 From: Lovesh Harchandani Date: Mon, 2 Apr 2018 20:44:21 -0700 Subject: [PATCH 1/3] fix link Signed-off-by: Lovesh Harchandani --- dkms/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dkms/README.md b/dkms/README.md index a2415c0..0b01a87 100644 --- a/dkms/README.md +++ b/dkms/README.md @@ -31,7 +31,7 @@ in the trustees own agent(s). These methods are not exclusive and should be combined with key rotation and revocation for proper security. -1. [Design and architecture](https://docs.google.com/document/d/1Cwolj9DOzvJ0obGy5qOVShUZyeIjbOT57HeM7FKhVCI/) +1. [Design and architecture](DKMS%20Design%20and%20Architecture%20V3.md) 2. **Public Registry for Agent Authorization Policy**. An identity owner create a policy on the ledger that defines its agents and their authorizations. Agents while acting on the behalf of the identity owner need to prove that they are authorised. [More details](https://docs.google.com/document/d/12Z10n4ZI3RmCZy-wCz7gs5DVqKr8BigC4rHCC-mvh2g/) \ No newline at end of file From 72ed4a8ce023cef72290248c17a3d3e48d7ed42d Mon Sep 17 00:00:00 2001 From: Lovesh Harchandani Date: Tue, 5 Jun 2018 18:05:10 -0600 Subject: [PATCH 2/3] fix typos and add clarification for some content Signed-off-by: Lovesh Harchandani --- janus/message-packaging.md | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/janus/message-packaging.md b/janus/message-packaging.md index a198e46..9e9a208 100644 --- a/janus/message-packaging.md +++ b/janus/message-packaging.md @@ -80,7 +80,7 @@ Notice the annotation method uses a prepended `@` to indicate it is an annotatio ### Signed Message Signing is only done when the use case requires it, for several reasons: 1. Authentication can be accomplished as part of the Public Key Authenticated Encryption (PKAE). -2. The Non-Repudiation offered by signing (DSA, ECDSA, EDDSA) is not always desired, as in the interrim steps of a negotiation. Signatures make a message non-repudiable. +2. The Non-Repudiation offered by signing (DSA, ECDSA, EDDSA) is not always desired, as in the interim steps of a negotiation. Signatures make a message non-repudiable. 3. Signatures are somewhat more expensive to compute and verify than other ways to authenticate, like PKAE. If a signature is required, the original message is encoded as BASE64URL and added to a new object with two other signature fields: @@ -231,7 +231,7 @@ Public Key Authenticated Encryption (PKAE) is a method where an elliptic curve d #### Anoncrypt Messages `anoncrypt` messages use PKAE in conjunction with an ephemeral sender key pair to strongly encrypt a message to an intended recipient. -The anoncrypt function takes the msg and the recipient's verkey as arguments. A nonce is used, but because the ephemeral key is used only once, it is deterministic. +The anoncrypt function takes the msg and the recipient's verkey as arguments. A nonce is needed, but because the ephemeral key is used only once, it acts as a nonce. ``` anoncrypt(msg, recipient_verkey) @@ -255,9 +255,9 @@ Internal message structure: ``` #### Multiplexing Authcrypt Messages -In cases where two different edge agents need to receive the same message, but the message is being sent through a common cloud agent, one solution is simply to send two separate authcrypt messages. +In cases where two different edge agents need to receive the same (`authcrypt`ed) message, but the message is being sent through a common cloud agent, one solution is simply to send two separate authcrypt messages. -If the message is large, this results in encrypting the message twice, and having to send it twice. It may be desireable to encrypt it and send it only once, while maintaining the requirement that both edge agents still be able to authenticate the message to the source. +If the message is large, this results in encrypting the message twice, and having to send it twice. It may be desirable to encrypt it and send it only once, while maintaining the requirement that both edge agents still be able to authenticate the message to the source. This can be done by a process called **Multiplexing**. @@ -279,11 +279,16 @@ Internal message structure (for each recipient): } ``` -The Meta message's internal structure can be the same for each recipient, including using the same ephemeral keypair. However, each message is encrypted _for_ each recipient using X25519 just like any other message. +The Meta message's internal structure can be the same for each recipient, including using the same ephemeral keypair. +However, each message is encrypted _for_ each recipient using X25519 just like any other message. -The sender can then send a collection of Authcrypt Meta messages, one for each recipient, and one Authcrypt Elemental Message. The Cloud Agent can disperse the appropriate Authcrypt Meta message to each recipient, along with the Elemental Message. +The sender can then send a collection of Authcrypt Meta messages, one for each recipient, and one Authcrypt Elemental Message. The Cloud Agent can +disperse the appropriate Authcrypt Meta message to each recipient, along with the Elemental Message. -The recipients decrypt the Authcrypt Meta messages and verify it like any other Authcrypt message. Then it hashes Elemental and verifies it matches the hash in the Meta. Then it decrypts Elemental using the key in Meta. +The recipients decrypt the Authcrypt Meta messages and verify it like any other Authcrypt message. Then it hashes Elemental and verifies it matches the hash `msg_hash` in the Meta. +If the `msg_hash` does not match the hash of the Elemental then it knows that either the sender did not calculate the hash correctly or the Cloud agent tampered the data. + +If the hash matches, it decrypts Elemental using the key `msg_key` in Meta. ##### Encryption To encrypt, the sender calls... @@ -291,9 +296,9 @@ To encrypt, the sender calls... authcrypt(msg, recipient_verkey, sender_ver_key, sender_sig_key) ``` -The authcrypt function... +The `authcrypt` function... 1. Generates a new ephemeral keypair. -1. Signs the ephmeral public key using `sender_sig_key`. +1. Signs the ephemeral public key using `sender_sig_key`. 1. Constructs a JSON object like so: ```json { @@ -312,7 +317,7 @@ To decrypt, the recipient calls... authdecrypt(msg, recipient_private_key) ``` -The authdecrypt function... +The `authdecrypt` function... 1. Removes the appended ephemeral public key 1. Uses the ephemeral public key and its own private key to decrypt the ciphertext. From e042012ebd5135c1a8cff4bea4b759379f5903d2 Mon Sep 17 00:00:00 2001 From: Lovesh Harchandani Date: Tue, 5 Jun 2018 18:08:14 -0600 Subject: [PATCH 3/3] revert link change Signed-off-by: Lovesh Harchandani --- dkms/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dkms/README.md b/dkms/README.md index 0b01a87..a2415c0 100644 --- a/dkms/README.md +++ b/dkms/README.md @@ -31,7 +31,7 @@ in the trustees own agent(s). These methods are not exclusive and should be combined with key rotation and revocation for proper security. -1. [Design and architecture](DKMS%20Design%20and%20Architecture%20V3.md) +1. [Design and architecture](https://docs.google.com/document/d/1Cwolj9DOzvJ0obGy5qOVShUZyeIjbOT57HeM7FKhVCI/) 2. **Public Registry for Agent Authorization Policy**. An identity owner create a policy on the ledger that defines its agents and their authorizations. Agents while acting on the behalf of the identity owner need to prove that they are authorised. [More details](https://docs.google.com/document/d/12Z10n4ZI3RmCZy-wCz7gs5DVqKr8BigC4rHCC-mvh2g/) \ No newline at end of file