4 ms·
> Where was this goal written down? https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ > Anyw
by twiss 3y ago
> Where was this goal written down?
https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/
> Anyway, as a user, I want secure. I don't care that much about efficiency. I absolutely don't care that someone thinks some methods are more "modern" than others.
There are plenty of security improvements in the crypto refresh, see https://proton.me/blog/openpgp-crypto-refresh https://proton.me/blog/openpgp-crypto-refresh.
Also, I don't want to be rude here but the OpenPGP Working Group is not obligated to do only what you want and nothing else. A charter was agreed upon, and followed.
> I really really want an actual standard. Not a whole bunch of pointless incompatibility.
A new RFC is about to be released, updating the standard. It shouldn't cause any incompatibility, as I've tried to explain three different ways.
> OCFB-MDC is an athenticated encryption mode. A particularly simple and straightforward one. No other modes are required. That is the point I am trying to make here.
But is it secure? We don't really know because there's no security proof. It also uses SHA-1, which might be fine or might not be.
The maintainers of all OpenPGP implementations (including GnuPG) saw value in adopting AEAD modes. Clearly there was some disagreement in which modes should be used and how. None of this should be cause to fork the standard entirely, though. And it also shouldn't be cause to give up entirely and throw away everything except RFC4880.
For those that want to implement and use AEAD, they can. Those that don't want to, don't have to. Again, none of this should cause incompatibilities, so there's no real reason to even argue about it on the internet and blame the crypto refresh for doing so :) For you as a user, it should be invisible. If it isn't, then the implementation is doing something wrong, not the spec.
- upofadown 3y agoI note that there is nothing about efficiency in that charter. >But is it secure? No reasonable person would think otherwise. It has withstood scrutiny for 20+ years. >We don't really know because there's no security proof. Why would we need a separate proof? The principles behind this sort of construct are pretty well known by now. See: * https://cseweb.ucsd.edu/~mihir/papers/enc-red.pdf https://cseweb.ucsd.edu/~mihir/papers/enc-red.pdf >It also uses SHA-1, which might be fine or might not be. Yeah it is for this sort of approach. That is not in question. At any rate, no one has any obligation to prove that OCFB-MDC is secure. It falls to those who that it be superseded to prove that there is something wrong with it. You (or I) can't legitimately suggest that something be replaced simply because you (or I) don't understand how it works. >For you as a user, it should be invisible. A significant portion of the article explains why it is not invisible, as in problems being caused right now with a list of examples and everything.