Re: AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME
On Thu, 17 May 2018 13:11, roman.fied...@ait.ac.at said: > How could that work together with the memory based "wipe" approach, you > envisioned in your message > https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last > paragraph? Tha is a different layer. Basically a part of a MUA. That feature would be a safenet in case the actual MUA part does not check return codes from GPGME. GPGME has several types of data objects - Memory based - File based - File descriptor based - Callback based For the first two we can clear the memory or delete the file in case of an error and before we return to the caller. It is actually a bit complicate to implement because gpgme allows for synchornous and asynchronous operation and for the latter we have not yet a way to associate the data object with context. > Would that imply, that using e.g. "--output /proc/self/3" would > implicitly change the security behavior of gpg, e.g. by switching from > "output before validation" model to "validation before output" model No, gpg has no idea about this. It only aware whether it is working on a named file or on a file descriptor (which also includes a pipe) Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp1ymasZ4luL.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Efail or OpenPGP is safer than S/MIME
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > On 17 May 2018, at 11:50, Patrick Brunschwig > wrote: > > > >> On 17.05.18 10:07, Werner Koch wrote: > >> On Thu, 17 May 2018 08:59, patr...@enigmail.net said: > >> > >>> Within 12 hours after the release I got 5 bug reports/support requests > >> > >> Kudos to Enigmail for acting as our guinea pig. I implemented the same > >> thing in GPGME this morning (see my mail to enigmail users). > >> > >> What shall we do now? Provide a separate tool to decrypt and clean HTML > >> messages or add a tool to Enigmail to do just this? > > > > Good question... Thunderbird is working on fixing the HTML display > > issue. But I think we should really start enforcing users to enable MDC. > > I therefore would prefer keeping the barrier high. In any case, this is > > nothing that I could implement with a week or two. > > I agree, while it would be easy for the users to have a magic button in > enigmail, this isn’t something we should be encouraging users to use on a > regular basis. > > IMO a better solution would be a standalone tool that you could point at a > local Maildir and tell it to clean and re-encrypt anything it finds that is > bad (for > a given value of “bad”), and save it to a new Maildir, perhaps with an > attachment explaining what was done. This would of course invalidate any > signatures on the re-encrypted data, but that’s OK for the use case. It should > not be an in-place update, nor should it work over e.g. IMAP because that > would a) encourage people to run it in a cronjob and b) destroy the originals, > which may be a deal breaker for archival purposes. Sounds nice. Maybe if you combine it with the suggestions from https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060362.html (and perhaps improve my proposal, as a first guess usually cannot be the best), you could kill two birds with one stone. Hence you also could have a shorter path to get rid of old ciphers, MDCs and other backward compatibility stuff, thus increasing security and speeding up development. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME
> Von: Werner Koch [mailto:w...@gnupg.org] > > On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said: > > > In my opinion it is hard to find such a "one size fits all" > > solution. Like Werner's example: disabling decryption streaming > > The goal of the MDC is to assure that the message has been received > exactly as the sender set it. Thus there is just a binary decision: > Okay or Fail. Everything is like you have been dropped at boot time > into manual fsck mode - you can do something about it or you just > irginore things and restore the partition. How could that work together with the memory based "wipe" approach, you envisioned in your message https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last paragraph? If I understand your approach correctly, it will imply that at least one do-not-apply-one-size-fits-all switch has to be present, thus contradicting one of your statements. Or did I get something wrong in my argument? The decision output (fail/ok) in the end might be binary for both use-cases but the internal logic (process model) for validation/output will be different. > > streaming of backups (decryption&output before final validation). So > > you need something on the interface to support that non-standard > > behavior, deviate from the default. > > It is already there. If you use "--output FILE" the file is either > created or not. Your choice. Would that imply, that using e.g. "--output /proc/self/3" would implicitly change the security behavior of gpg, e.g. by switching from "output before validation" model to "validation before output" model (again compare your message, cited above)? Implicit feedback from selected output mode on security related MDC-check behavior would seem dangerous to me. Somehow rings an alarm bell, if that should be the proposed solution. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: AW: Efail or OpenPGP is safer than S/MIME
On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said: > In my opinion it is hard to find such a "one size fits all" > solution. Like Werner's example: disabling decryption streaming The goal of the MDC is to assure that the message has been received exactly as the sender set it. Thus there is just a binary decision: Okay or Fail. Everything is like you have been dropped at boot time into manual fsck mode - you can do something about it or you just irginore things and restore the partition. > streaming of backups (decryption&output before final validation). So > you need something on the interface to support that non-standard > behavior, deviate from the default. It is already there. If you use "--output FILE" the file is either created or not. Your choice. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpNMq8eJWffx.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: AW: Efail or OpenPGP is safer than S/MIME
> Von: Andrew Gallagher [mailto:andr...@andrewg.com] > > > On 16 May 2018, at 13:44, Fiedler Roman > wrote: > > > > I am not sure, if gpg could support > > implementation/testing/life-cycle-efforts > to establish all those parameters and different process models for most of the > decryption processes gpg users envision to use gpg for. > > Why do we need a plethora of configuration parameters to selectively turn > off various parts of a security protocol? Why should we even encourage such > a thing? With security, either everything seems to be ok, or it’s broken in > such > a way that it’s potentially an utter disaster. And quite probably both > simultaneously. In my opinion it is hard to find such a "one size fits all" solution. Like Werner's example: disabling decryption streaming operation might increase security for some use-cases (validation before decryption&output) but might make others impossible, like streaming of backups (decryption&output before final validation). So you need something on the interface to support that non-standard behavior, deviate from the default. > The only reasonable use case for selective disabling of security protocol > features is for backwards compatibility. That doesn’t require fine grained > control, just a version number. And even then, it opens up the possibility for > user error. Yes, another example for different use-cases and hence different process model requirements in software. > I’m going to preemptively quote RJH here before he gets around to it. Use the > defaults! ;-) Then why are there already so many command line options for decryption/validation gpg not just one: "--insecure"? From my point of view, monopolists might be able to push one set of defaults but the open source software ecosystem might work differently: those projects survive, that enable that many use-cases per development effort, so that they find sufficient developers/funds to support development. If they drift off, the project will fork/another project might take over. So gpg has to watch out for the optimum point between following extremes: 1) Only supporting one standard use-case with default settings (thus increasing security but loosing users) 2) Supporting many use-cases via different gpg-internal decryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters) 3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that other party just does not do it right - e.g. ignores a warning like with Efail) Assuming, that the ideal point would be somewhere in between, supporting only a single FAIL status like old-style shell commands might not be sufficient to attract sufficient users from world 1, 2, 3 above. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: Efail or OpenPGP is safer than S/MIME
> I’m going to preemptively quote RJH here before he gets around to it. Use the > defaults! ;-) :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: Efail or OpenPGP is safer than S/MIME
> On 16 May 2018, at 13:44, Fiedler Roman wrote: > > I am not sure, if gpg could support implementation/testing/life-cycle-efforts > to establish all those parameters and different process models for most of > the decryption processes gpg users envision to use gpg for. Why do we need a plethora of configuration parameters to selectively turn off various parts of a security protocol? Why should we even encourage such a thing? With security, either everything seems to be ok, or it’s broken in such a way that it’s potentially an utter disaster. And quite probably both simultaneously. The only reasonable use case for selective disabling of security protocol features is for backwards compatibility. That doesn’t require fine grained control, just a version number. And even then, it opens up the possibility for user error. I’m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-) A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: Efail or OpenPGP is safer than S/MIME
> Von: Werner Koch [mailto:w...@gnupg.org] > > On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said: > > > The status line format should be designed to support those variants to > > allow a "logical consistency check" of the communication with GnuPG > > There is a > > DECRYPTION_FAILED > > and that is all what it takes. But this is only a single status code for a very complex decryption/validation process (considering cipher methods, signature methods, local time, trust DBs, signatures, number of messages, ...). When relying on that single code, gpg would need configuration parameters to configure each step of the whole decryption/validation process in a very fine-grained way, so that gpg will know in the end, if it should issue the FAILED or not. I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for. > If the integrity check fails there > should be no easy way to circumvent this. RFC-5083 states this cleary: > >The recipient MUST verify the integrity of the received content >before releasing any information, especially the plaintext of the >content. If the integrity verification fails, the receiver MUST >destroy all of the plaintext of the content. > > Unfortunately this can't be done by tools prepared to process huge > amounts of data. And in contrast to the Efail claims this is an > important feature. How would you else do your ZFS backups without > having a way to stream the data to the backup system. This is just the example of two different, complex decryption/validation processes, that should be supported both. As the definition of the "process" also has implications, what a valid "integrity check" is (see also the discussion about historic messages), I believe, that this is hard to be done by breaking it down to a single 0/1 decision for gpg (which might not know the constraints of the current process in detail). Otherwise a "--allow-non-rfc-5083-streaming-mode" flag should already exist to tell gpg more about the decryption process constraints (to distinguish between the two different process models, that should be implemented already, just for your RFC-citation from above). > ... LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: Efail or OpenPGP is safer than S/MIME
On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said: > The status line format should be designed to support those variants to > allow a "logical consistency check" of the communication with GnuPG There is a DECRYPTION_FAILED and that is all what it takes. If the integrity check fails there should be no easy way to circumvent this. RFC-5083 states this cleary: The recipient MUST verify the integrity of the received content before releasing any information, especially the plaintext of the content. If the integrity verification fails, the receiver MUST destroy all of the plaintext of the content. Unfortunately this can't be done by tools prepared to process huge amounts of data. And in contrast to the Efail claims this is an important feature. How would you else do your ZFS backups without having a way to stream the data to the backup system. For failsafe reasons I consider to wipe the plaintext data in GPGME's interface on decryption failure. That can only be done when memory based data or file based objects are used. But I guess that many MUAs use the memory data approach. Such a failsafe protection would avoid an attack even if the error code returned by GPGME is not checked. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpdsLAun8Nqs.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Efail or OpenPGP is safer than S/MIME
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > > On 14 May 2018, at 18:32, Werner Koch wrote: > > > > On Mon, 14 May 2018 15:44, andr...@andrewg.com said: > > > >> This all exposes one of the difficulties with trying to manage security > >> software in a decentralised ecosystem. We end up in arguments over > whose > > > > That is actually easy compared to a system which is also designed to > > protect data at rest. Some users may want to restore their 2 year old > > backup to fix a problem with garbled tapes; some may want to read the > > real documents about WMD from 2003; some may even want to be able to > > decrypt their old love letters at the time of their silver wedding. > > Indeed. This is why data must be treated as a living object. If tape drive > technology moves on, the data must be moved on. Same with file formats, > encryption systems and dying raid arrays. Librarians and archaeologists > understand the process of care and feeding for physical artefacts. Digital > artefacts are no exception. So true. By applying such procedures, the long-term costs for providing data access would not only be on the gnupg developers' side (for providing loads of backward compatibility switches in highly security critical context) but also on those users wanting to keep the data for a long time. To improve awareness on user side and also reduce their archival costs, might a "gnupg --archive" function help? It decrypts a message the same way a normal "--decrypt" would do but then reencrypts the old encrypted message plus the decrypted content and a full decryption process audit log using an "archive key". With such a function, gnupg might have it easier to argue running a more rigid scheme for retiring old features, e.g. that first normal decryption will fail (warning about deprecation, recommending sender upgrade or --archive use) and then after some years grace period removing the code completely? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Efail or OpenPGP is safer than S/MIME
> Von: MFPA [mailto:2017-r3sgs86x8e-lists-gro...@riseup.net] > > Hi > > On Monday 14 May 2018 at 1:33:03 PM, in > local>, > Fiedler Roman wrote:- > > > This would also prevent many other programming > > errors: e.g. if gpg > > claims to have processed 2 signed messages, a client > > has to verify, > > that it also received two "GOOD_SIG" messages. > > What if a message has more than one signature? The status line format should be designed to support those variants to allow a "logical consistency check" of the communication with GnuPG like a message digest allows consistency checking for a cryptographic message. I guess it would be ease for the GnuPG-hardcore developers to define, which fields are required to perform a thorough consistency check. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Efail or OpenPGP is safer than S/MIME
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > On 14/05/18 12:25, Robert J. Hansen wrote: > > The problem is that gpg doesn't say anything. I would expect a > > DECRYPTION_FAILED message here: > > So perhaps the solution is to throw a big warning and prompt when an > integrity check failure is thrown by gnupg? That would mitigate the > current issue, but allow for reading pre-MDC emails as per Werner's > earlier link. > > The problem here is that an integrity failure is a serious error when it > occurs in a context where oracle behaviour is possible (such as email), > but it's much less serious when used outside that context. Just because > gnupg says it's only a warning-level offence doesn't mean enigmail > should agree... In my opinion, the problem is related to the general gnupg interface design. An optional error or warning is always somehow problematic in interfaces: 1) you have to read and understand the complete documentation to know of any message that may occur 2) if it is not here, you simply do not know, if everything is right, if you just missed the message or an attacker managed to "suppress" it somehow. Makes it easier on the attacker - like here In my opinion, gnupg would do itself a favour by avoiding optional messages - without any other reference to it. With such a protocol I would expect gnupg to end somehow like ... [END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, , Warnings: 1, Errors: 0 ... (put here everything you deem important and document it) This would also prevent many other programming errors: e.g. if gpg claims to have processed 2 signed messages, a client has to verify, that it also received two "GOOD_SIG" messages. If just any of the numbers do not match, any good mail client should bail out immediately, e.g. if warn=1 but the client did not understand the warning. LG R PS: A end message as single line sorted JSON dictionary might make parsing less error prone and increase the number of developers really parsing and using them. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users