3 ms·

This is wandering all over the place... >...the goal was to modernize the cryptography in use, to make it more secure and more efficient. Where was this goal

This is wandering all over the place... >...the goal was to modernize the cryptography in use, to make it more secure and more efficient. Where was this goal written down? 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. I really really want an actual standard. Not a whole bunch of pointless incompatibility. There were no downgrade attacks demonstrated as part of EFAIL. In fact, the researchers were not able to compromise the current OpenPGP OCFB-MDC authenticated encryption mode at all. They were reduced to listing implementations that did not handle HTML link injection in the way that they preferred. >...the security of AEAD modes shouldn't depend on the security of CFB mode. 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.

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 ago
  I 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.

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 ago
I 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.