Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mattson comments #23

Merged
merged 4 commits into from Jan 23, 2020
Merged

Mattson comments #23

merged 4 commits into from Jan 23, 2020

Conversation

bifurcation
Copy link
Collaborator

No description provided.

Copy link
Contributor

@martinthomson martinthomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typos.

I tend to agree with others about reducing the number of primitives.

draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved
draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved

* Forward secrecy - HPKE ciphertexts are not forward-secure. A given ciphertext
can be decrypted if the recipient's public key is compromised at any time
after the ciphertext is created.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ciphertext also leaks if the public key is compromised before the ciphertext is created, so perhaps:

* Forward secrecy - HPKE ciphertexts are not forward-secure.  A given ciphertext
   can be decrypted if the recipient's public encryption key is compromised.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In mode_auth_psk, the recipient's public key and the psk need to be compromised. Suggestion:

* Forward secrecy - HPKE ciphertexts are not forward-secure. In mode_base
  and mode_auth, a given ciphertext can be decrypted if the recipient's public
  encryption key is compromised. In mode_psk and mode_auth_psk, a given
  ciphertext can be decrypted if the recipient's public encryption key and the
  psk are compromised.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this confuses post-compromise security and forward secrecy. See the recent discussion on the lake list on this point. In short, a PSK mode could have FS, but cannot have PCS.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't think this is true. (I agree with the claim about achieving FS by hash-racheting the PSK.). @blipp's text simply says that if the private key material is compromised, bad things happen. It doesn't rule out FS should that keying material be updated. I think the text is fine as is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not on the lake list, so I don't know what was discussed there (just mentioning such that you can read the following with a grain of salt).

In mode_psk and mode_auth_psk, it's right that if only one of (psk, skR) gets compromised after encrypting the plaintext, the plaintext stays secret. That's some weird kind of forward secrecy assuming that skR and psk are stored sufficiently separated (weird because new ciphertexts are still created with the same key material, there is no key update, no transition to a new epoch, etc). I have a proof for this property within my analysis. I think it's a good idea to mention this in the security considerations section, but maybe it's already implicit with my previous text suggestion.

A protocol building upon HPKE could try to add better properties, but I am not sure if this would be out of scope of this draft?

and mode_auth, a given ciphertext can be decrypted if the recipient's public
encryption key is compromised. In mode_psk and mode_auth_psk, a given
ciphertext can be decrypted if the recipient's public encryption key and the
psk are compromised.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: "PSK" (caps)

draft-irtf-cfrg-hpke.md Outdated Show resolved Hide resolved
@chris-wood chris-wood merged commit d41dbb6 into master Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants