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

Switch to Ed25519+Cv25519 in v1.1 #393

Merged
merged 2 commits into from Jan 28, 2019

Conversation

Projects
None yet
7 participants
@Valodim
Copy link
Contributor

Valodim commented Nov 9, 2018

As discussed at the meeting.

RSA remains a SHOULD. I put a remark about older versions into a note, that seemed like the appropriate place.

@Valodim Valodim requested review from azul , hpk42 and pbrunschwig Nov 9, 2018

@Valodim Valodim added this to the Level 1.1 spec milestone Nov 9, 2018

@azul

azul approved these changes Nov 11, 2018

Copy link
Member

azul left a comment

Looks good to me. Good idea to point out the previous situation in a note.

3072-bit RSA public keys. It MAY support other OpenPGP key formats
found in an Autocrypt header (for example, by passing it agnostically
to an OpenPGP backend for handling).
A Level 1 MUA MUST be capable of processing and handling Ed25519

This comment has been minimized.

@r10s

r10s Nov 11, 2018

Member

shouldn't this read "A Level 1.1 MUA ..."?
EDIT: okay, i recall and understand :) the level is the "level of protection" in general, so, probably this is fine.
however, seeing these two different requirements, both belonging to the same "Level", as a diff below each other, may be a bit confusing. maybe we should add the version number or so, sth. as "level 1, version 1.1".

This comment has been minimized.

@Valodim

Valodim Nov 11, 2018

Author Contributor

Nope. This is still level 1, but version 1.1 of it. Since all implementations are on board with this in practice, and this is mostly an update to the "how" rather than the "what", we thought that there's no point making a whole "level" out of it :)

This comment has been minimized.

@r10s

r10s Nov 12, 2018

Member

yeah, as mentioned, i understand. but still find this confusing ;)
but it's fine for me :)

@pbrunschwig
Copy link
Contributor

pbrunschwig left a comment

Fine with me.

@r10s The Level is an overall concept, whereas the version is the revision of the document.

@hpk42

This comment has been minimized.

Copy link
Contributor

hpk42 commented Nov 12, 2018

@Valodim Valodim requested a review from dkg Nov 12, 2018

configuration. Support for elliptic curve cryptography in deployed
OpenPGP implementations improved since then, and the switch to ECC
was made in version 1.1 (December 2018) due to message size
considerations.

This comment has been minimized.

@hpk42

hpk42 Dec 20, 2018

Contributor

i remain fine with this, good note 👍

@hpk42

hpk42 approved these changes Dec 20, 2018

Copy link
Contributor

hpk42 left a comment

i think this is fine to merge. thanks @Valodim for working this out!

@dkg

This comment has been minimized.

Copy link
Member

dkg commented Dec 20, 2018

The typical way that i'd expect such a change to happen in a protocol doc with wider adoption is to require support for handling the new crypto primitives (when seen from communications peers) in version X+1, and then mandate generation of the new key types in version X+2.

Perhaps we're small enough and we have a wide enough canvas already that we can just jump ahead, though it makes me slightly nervous. PGPy still doesn't support cv25519 and ed25519, for instance, though perhaps its current stagnation is a warning about that library itself. :(

I'm open to the idea, though -- i definitely like the size improvements we're seeing with the ECC keys.

This change should not be merged without updates to the appendix, though -- the example keys and messages should all be re-created using 25519.

@oliverFU

This comment has been minimized.

Copy link
Contributor

oliverFU commented Jan 16, 2019

Hey,

when do you plan to switch?
Our prototype still only supports RSA and I am actually figuring out how easy it is to move to ed25519. We are currently using ObjectivePGP: https://github.com/krzyzanowskim/ObjectivePGP

Best
Oliver

@Valodim

This comment has been minimized.

Copy link
Contributor Author

Valodim commented Jan 22, 2019

I updated the examples. I already double-checked myself, anyone care to double-double-check? Also added a script for generation. It works, but better not look at that too closely ;)

@Valodim Valodim merged commit dbf3ac6 into master Jan 28, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@Valodim Valodim deleted the ecc branch Jan 28, 2019

@Valodim

This comment has been minimized.

Copy link
Contributor Author

Valodim commented Jan 28, 2019

@oliverFU now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment