search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.01k stars 17.68k forks source link

proposal: x/crypto: deprecate unused, legacy and problematic packages #30141

Closed FiloSottile closed 5 years ago

FiloSottile commented 5 years ago

x/crypto is meant to follow the same philosophy as the rest of the Go cryptography standard libraries: safe, useful subsets of widely used and robust primitives and protocols. Some packages in x/crypto don't clear that bar anymore, and I propose we freeze and deprecate (but not remove) them.

The intended outcomes are

All open and future issues and CLs that are not security relevant will be closed linking to this issue.

/cc @agl with whom we discussed this at RWC, and @golang/proposal-review for approval

Why

There are different reasons for deprecating different packages, and I give a short explanation for each of them below, but here's a summary.

What packages

I was also hoping to kill pkcs12/ because it's a legacy file format that relies on primitives even worse than the ones listed above, and the package only does decoding while a better fork on GitHub also does encoding, but it has way too many users so that's only been frozen instead.

davecgh commented 5 years ago

I would prefer to see ripemd160 maintained as it is used by more cryptocurrencies than just Bitcoin. Honestly, Bitcoin is a pretty big deal on its own and would be enough reason to maintain it in my opinion.

Additionally, I performed a quick survey via godoc.org importers and it shows that the ripemd160 package is imported by at least 511 packages at the current time, including many widely known pieces of software such as Btcsuite, Discord, Decred, Ethereum, and Ripple.

FiloSottile commented 5 years ago

@davecgh I am not aware of any reasons to pick RIPEMD-160 for a new design, so the fact that cryptocurrencies inherited it from the Bitcoin paper is not a good enough reason not to deprecate it.

I don't expect it will require any maintenance anyway—it's a hash function, the package is almost certainly fine as is—but deprecating it will send the message to users not to look there if they just need a hash function, and communicates that we would for example not take an optimized assembly implementation for it.

aksdb commented 5 years ago

Just picking two examples to illustrate my opinion: md4 is used in the NTLM protocol. pkcs12 is used to store certificates in a lot of real world applications.

Both are dated, one is a PITA. Yet I think x/crypto should not be reduced to state of the art ciphers/protocols since we are not always developing self contained systems where we can safely choose the best available tech, we also have to connect to legacy systems or simply not-that-well-developed third-party systems.

Also I think that especially the pretty self contained and matured algorithms like MD4 don't suffer much from "being unmaintained". I mean: what would you maintain? The algorithm is stable (although "broken"). We cannot do anything about attacks on the algorithm (apart from refraining from future use).

I understand your point with OpenPGP. Though it might also be an option to try and get one of the forks to be reintegrated and actually maintain that.

If a living protocol (that still receives updates; has a moving spec) rots ... yeah, throw it out. The sophisticated implementations however, that are simply not "maintained" because there is nothing to maintain there ... I would like to keep them.

nadimkobeissi commented 5 years ago
  • otr/ — a messaging security protocol from 2000's, mostly obsoleted by the Signal double ratchet and other messaging protocols like OMEMO and MLP, and a very rarely used package

The reasons given for obsoleting the otr package are perfectly sensible, but if it's not too much of a burden I would argue for nevertheless keeping this package: this is because in the XMPP world, the OTR protocol is still used as the standard secure messaging protocol and Signal has virtually no adoption there.

Aside from this argument I admittedly have nothing else with which to claim that keeping otr is relevant.

tredoe commented 5 years ago
jdevelop commented 5 years ago

I'd rather keep openpgp (and would consider making it compatible with GnuPg2 ).

Still the problems there are quite surprising

Would be cool to have someone to take a look.

charles-dyfis-net commented 5 years ago

I'd similarly be very disappointed to see openpgp removed. Frankly, the implementation even as it exists is much higher-quality than the upstream GnuPG one, incomplete as it may be; removing it would thus be a loss to the community as a whole.

Admittedly, I'm one of those folks with a private fork, but I have approval from my employer's legal team to submit our changes upstream; if getting off my arse and doing so is the cost of keeping it in-tree (and thus being sure that the existing functionality continues to work with future versions of Go), I'm happy to do so.

bradfitz commented 5 years ago

@tredoe @charles-dyfis-net, this issue is about freezing+deprecating them, not removing them.

dominikh commented 5 years ago

@bradfitz To be fair, deprecating them has almost the same effect as removing them; people will look elsewhere for alternatives that aren't marked as deprecated. Which I imagine is the intended effect. Unfortunately, the alternatives may not always be of higher quality. For example, I'd much rather see people use x/crypto/md4 over some other, random md4 implementation.

I don't think the "these algorithms are broken" holds as an argument. A lot of legacy still relies on them, unfortunately. As such, we should rather look at the cost of not deprecating a package. One can of course argue that another well-organized party that isn't Go should maintain legacy packages.

Have we explored why these packages made it into x/crypto in the first place?

bradfitz commented 5 years ago

To be fair, deprecating them has almost the same effect as removing them

I disagree. The effects are quite different: removing them breaks users, and deprecating them does not. Deprecating them is just adding a comment saying, "Yo, new applications shouldn't use this, and also we're not adding new features so don't send PRs."

people will look elsewhere for alternatives that aren't marked as deprecated. Which I imagine is the intended effect.

Sounds like the intended effect is reducing maintenance cost by not accepting changes to add features or optimize the performance.

aksdb commented 5 years ago

I think the "deprecated" marker would move the same thinking you have here down the line. Your argument for deprecation (or removal) is that the code is old and the algorithms should not be used. While the code is actually most likely still fine and just doesn't need any maintenance (if it does, someone will report it and or create a PR). If it's marked "deprecated" it will lead to managers/decision makers/etc. thinking "oh, that code is not maintained, we cannot use it. go find something else". I had discussions like that myself. A library for a microcontroller we were working with was over 7 years old and did not have a single change. It took a considerate amount of time to convince my superior that this did not matter since a) the code was well documented b) had good test coverage c) the microcontroller in question was that old as well - there was simply nothing that could have changed in the meantime. The same holds for the algorithms in question. MD4, cast5, blowfish, twofish, etc. will not change. They may not be a good choice for cryptographic strength ... but they may still be the right choice to implement a specific interface. And then it's better to have a central source that does not imply "we will get rid of this soon" instead of a bunch of third party sources.

dominikh commented 5 years ago

If it's marked "deprecated" it will lead to managers/decision makers/etc. thinking "oh, that code is not maintained, we cannot use it. go find something else".

Case in point: https://github.com/dominikh/go-tools/issues/413

Everywhere in the standard library, deprecated means "stop using this, move to an alternative".

FiloSottile commented 5 years ago

Remember that deprecation comes with a message, so we can explain the reasons and implications for each package individually, and I'll make sure to provide as much context as possible.

There will be packages that say "this algorithm is broken [or superfluous] because X and should not be used except for compatibility with legacy systems". This does not call for an alternative implementation, but it warns people off using it, and recommends moving to non-broken things.

Other packages will say "this implementation is incomplete and unmantained, consider an alternative protocol like X, or a community maintained package". This hopefully leads to a centralized target for maintenance efforts which does not involve our resources.

I am replying to a few points individually below, before commenting please check if your point was already made above, to prevent this from becoming a giant thread nobody reads or feels like participating in.

I think that especially the pretty self contained and matured algorithms like MD4 don't suffer much from "being unmaintained".

Indeed, deprecating them comes at near-zero cost because there are not going to be new features and bug fixes. But the message to developers about not using them is important.

in the XMPP world, the OTR protocol is still used as the standard secure messaging protocol and Signal has virtually no adoption there

Ack, but I'm afraid that's not enough to justify the Go project maintaining an implementation. I would probably not even accept a Signal protocol implementation in x/crypto.

blowfish can not be compared with AES since the former has a fixed block size of 64 bits;

Good point! That makes it fundamentally vulnerable to Sweet32, updated the proposal.

The fact of that a algorithm been used into a public or known project doesn't mean that it doesn't been used at private projects.

I use usage in public projects as an indicator of popularity and therefore usefulness to the ecosystem, not as proof that nobody uses the package at all, and that's one part of the tradeoff decision on whether it's worth the resources to maintain.

Twofish and also Serpent have greater security than Rijndael

AES-256 is secure enough for Top Secret data in NSA's Suite B, I don't feel the need to carry anything else to fill a security gap.

The block mode XTS is a block mode very safe, only recommended for full-disk encryption.

XTS is quite bad in fact. See also a better tweakable cipher.

Admittedly, I'm one of those folks with a private fork [of openpgp], but I have approval from my employer's legal team to submit our changes upstream

Almost half of all issues open against x/crypto packages are for x/crypto/openpgp, and a good chunk of all CLs are for it as well. I'm not blaming the community for not contributing back here, I blame the protocol for requiring too much maintenance to properly implement. It just doesn't make sense for us to put in the effort to do the review and design work to bring this package to a state in which we are happy about it. Hopefully the community will centralize on a fork.

I'd much rather see people use x/crypto/md4 over some other, random md4 implementation.

MD4 is a bad example, because it's literally as broken as a hash function can be. Go is a memory-safe language, so a random implementation off the street can't introduce an RCE without really trying, and the next worse thing a hash function from the last 20 years can have is a collision, and well, I might still have some Python to generate one on a laptop.

I don't think the "these algorithms are broken" holds as an argument. A lot of legacy still relies on them, unfortunately. As such, we should rather look at the cost of not deprecating a package.

The cost includes developers being misled into thinking that a primitive or protocol can serve their needs because it's in x/crypto, diluting the safety properties of using the standard library.

Have we explored why these packages made it into x/crypto in the first place?

Some to support OpenPGP, some have always been there from before there was a conscious effort to limit what was in x/crypto, some were reasonable at the time and aren't anymore, some were a mistake.

Everywhere in the standard library, deprecated means "stop using this, move to an alternative".

If you are using any of the above, I would like you to stop using it and move to an alternative. Sometimes an alternative implementation, sometimes an alternative algorithm. If you know you can't because of legacy compatibility reasons, at least I made you aware of it, and made sure the question got asked at review time, and the answer hopefully documented.

tarcieri commented 5 years ago

Having seen cryptography mismanaged in the standard libraries of many other languages I use, this seems like a great move to me, and a breath of fresh air by comparison. Cryptography in the standard library should be held to a high bar, and I'm glad to see that bar enforced.

In languages with a "batteries included" standard library like Go's, the ecosystem is largely shaped by what's available in the standard library. Go has pretty much the best cryptography ever seen in a language's standard library with a few exceptions, and this proposal covers most of the exceptions.

For implementations of legacy protocols, I think users are almost certainly better off with something out-of-tree. This not only discourages accidental use in new projects, but also provides greater agility in the event of a security incident, as the response does not involve a new release of the language/standard library. Deprecating these algorithms from the standard library isn't a value judgment on their overall utility, just a signal that people should move to out-of-tree implementations. The remaining concern there is that they will lose the reluctant maintainers these algorithm implementations previously had. If the algorithms are truly useful and important, I think you can find new maintainers, and ones who aren't reluctant. Otherwise, it's entirely possible they're not as useful as they're claimed to be.

The remaining arguments seem to fall into a category I call "unusual requirements". For things like symmetric ciphers and hash functions, there are huge reasons to prefer algorithms like AES and SHA-2 over things like Serpent, Twofish, or RIPEMD-160, namely AES has hardware acceleration through a number of different platform-specific instructions like AES-NI which provide better performance and sidechannel resistance. In the case of RIPEMD-160 it has only 80-bits preimage resistance which is considered rather weak by today's standards. The specific security and performance requirements (much less threat model) weren't stated in any of these cases, but in my opinion as a cryptography professional specializing in symmetric encryption I think the claims made by people alleging they selected these algorithms due to "unusual requirements" are, to put it bluntly, factually inaccurate.

tl;dr: eliminating junk cryptography from the Go stdlib will help improve the overall security of the ecosystem, so I say go for it.

bradfitz commented 5 years ago

... as the response does not involve a new release of the language/standard library.

@tarcieri, this bug is about x/crypto, which is not the standard library.

tarcieri commented 5 years ago

@bradfitz well don’t I look foolish. Mea culpa

claucece commented 5 years ago

Hey!

Sorry for jumping into the discussion.

  • otr/ — a messaging security protocol from 2000's, mostly obsoleted by the Signal double ratchet and other messaging protocols like OMEMO and MLP, and a very rarely used package

Well, with the upcoming OTRv4 protocol, I don't how true this will still hold. There is a lot of people now interested in using OTRv4 again and implementing it on different clients; so I don't if it will be a shame to loose it here. That said, for the most people who are actually using OTR in golang, they actually use this library instead: https://github.com/coyim/otr3

I also don't know the state of OTR in golang (if it is fully implemented). I can check if needed.

I don't know what MLP means, is that MLS?

Btw, here some useful links around OTRv4, in case someone wants to check its interest/proposal:

Hope this information helps :)

FiloSottile commented 5 years ago

That said, for the most people who are actually using OTR in golang, they actually use this library instead: https://github.com/coyim/otr3

I'm happy to hear there is work on the protocol, and that there is a community package for the previous version. That suggests deprecating the x/crypto one would be good for the ecosystem, letting it focus on modern and maintained implementations.

I don't know what MLP means, is that MLS?

Yes, thanks, fixed.

tredoe commented 5 years ago

blowfish can not be compared with AES since the former has a fixed block size of 64 bits;

Good point! That makes it fundamentally vulnerable to Sweet32, updated the proposal.

Simply because the attack is possible doesn't mean it is particularly easy to carry out. For Sweet32, the attacker needs to be able to monitor traffic passing between the user and a vulnerable website, as well as control JavaScript on a web page loaded by the user's browser. It would take about 38 hours to collect hundreds of gigabytes of data necessary to decrypt the authentication cookie.

https://blog.securityevaluators.com/what-is-sweet32-4a62dca90296

The fact of that a algorithm been used into a public or known project doesn't mean that it doesn't been used at private projects.

I use usage in public projects as an indicator of popularity and therefore usefulness to the ecosystem, not as proof that nobody uses the package at all, and that's one part of the tradeoff decision on whether it's worth the resources to maintain.

Fair point

Twofish and also Serpent have greater security than Rijndael

AES-256 is secure enough for Top Secret data in NSA's Suite B, I don't feel the need to carry anything else to fill a security gap.

Although NSA has categorized this in Suite B, they have also recommended using higher than 128-bit keys for encryption. So, should be also removed or deprecated AES-128?

Besides of that, and althought I wouldn't assume that NSA has cracked AES ciphers, I would assume that most crypto systems that use AES have implementation flaws that the NSA could exploit when they want throught its own data center, because the NSA are actively subverting security on the standard level or in collusion with software developers.

The block mode XTS is a block mode very safe, only recommended for full-disk encryption.

XTS is quite bad in fact. See also a better tweakable cipher.

At the first, in practice, many encrypted filesystems already use encryption that's strictly worse than XTS, and they generally use the same block-based model as full disk encryption for exactly the same performance reasons.

Besides, the title of such article is confusing because many people will only ever encounter XTS when setting up full disk encryption with dm-crypt, where they'll be presented with the choice between XTS and CBC-ESSIV.

And finally, it's also not saying that you shouldn't use XTS for full disk encryption. In fact it seems to say it's probably OK for full disk encryption: "It’s certainly better than ECB, CBC, and CTR for FDE. For the crappy job we ask it to do, XTS is probably up to the task."

DrWhax commented 5 years ago

I would agree that getting rid of otr(which I believe is v2?) from x/crypto makes sense, there's an otrv3 implementation(https://github.com/coyim/otr3) in Golang and a partial implementation of otrv4 in Golang(https://github.com/otrv4/otr4) underway.

As we've been discussing internally in some calls with Ian Goldberg, we'd like to get rid of v2 in favor of v3 and especially v4, so, keeping the otrv2 implementation in x/crypto doesn't make much sense.

claucece commented 5 years ago

Yes, I agree with @FiloSottile and @DrWhax . We will surely develop OTRv4 in golang, and it will maintained; so deprecating the old version in golang libs (which might be in between v2 and v3) makes sense. In the future, if wanted, we can implement OTRv4 in golang libs itself. Thanks!

gtank commented 5 years ago

I can confirm that well-meaning but uninformed developers choose equally randomly among the options in crypto/ and x/crypto, and therefore I strongly support the proposal. In fact, I gave a GopherCon talk once about exactly this problem.

Deprecating an algorithm in x/crypto isn't the same as banishing it from the Earth, it just means Go's very few crypto reviewers will have more time to focus on things that are/should be widely used.

rsc commented 5 years ago

This proposal should be put on hold for now.

We shouldn't remove anything from x/ until (1) modules are enabled by default and (2) we have started tagging versions. Once we have started tagging versions, we can discuss removing things; modules will mean users don't automatically get the latest copy, and the tagged version will make it easy to record that what exactly they depend on.

mvdan commented 5 years ago

@rsc perhaps I'm missing something, but it appears that removal isn't part of the proposed plan here:

and I propose we freeze and deprecate (but not remove) them

rsc commented 5 years ago

@bradfitz and @andybons point out that I misunderstood and that this proposal is only about marking things deprecated, not removing them. Sorry.

rsc commented 5 years ago

Taking md4 as an example, obviously that should be marked as completely broken and something no one should use except under extreme duress. It's funny that crypto/md5 says

r$ go doc md5
package md5 // import "crypto/md5"

Package md5 implements the MD5 hash algorithm as defined in RFC 1321.

MD5 is cryptographically broken and should not be used for secure
applications.

but md4 does not. Obviously it should. Adding that kind of documentation note doesn't require a proposal.

Similarly, x/net/websocket says:

r$ go doc golang.org/x/net/websocket
package websocket // import "golang.org/x/net/websocket"

Package websocket implements a client and server for the WebSocket protocol
as specified in RFC 6455.

This package currently lacks some features found in an alternative and more
actively maintained WebSocket package:

    https://godoc.org/github.com/gorilla/websocket

That's another very clear message that seems fine.

But it seems like a few are not quite in that camp. OpenPGP for example, isn't cryptographically broken, right? I'm less sure about marking that package as deprecated. Is there an established fork that we should point to instead? Or should we invite them to own x/crypto/openpgp?

FiloSottile commented 5 years ago

@rsc I want to send a stronger message than just adding a line to some package-level docs that nobody will pay attention to (at the very least for existing dependencies). I want developers to make an active, hopefully justified, choice to ignore a tooling-provided flag.

If you need some WebSocket feature you'll know, and if it's not in golang.org/x/net/websocket, you might look at the docs and learn where to go look for it. If you are using a bad hash, it will look and feel like a perfectly good hash.

But it seems like a few are not quite in that camp. OpenPGP for example, isn't cryptographically broken, right? I'm less sure about marking that package as deprecated. Is there an established fork that we should point to instead? Or should we invite them to own x/crypto/openpgp?

OpenPGP is legacy, brittle, and very high maintenance to implement. I discourage any new system from using it, and I don't think it's worth any of our limited resources to maintain. If it were only for lack of resources, I would be seeking an owner for x/crypto/openpgp, but given that it's not something people should be encouraged to use, I don't think that would be a service to our users.

I expand on this in the "Why" section above, under the "openpgp/" bullet, and at https://github.com/golang/go/issues/30141#issuecomment-462067035.

bradfitz commented 5 years ago

I want to send a stronger message than just adding a line to some package-level docs that nobody will pay attention to (at the very least for existing dependencies). I want developers to make an active, hopefully justified, choice to ignore a tooling-provided flag.

Wait, I thought this whole bug was just about adding a "Deprecated: ..." comment, but you refer to an "active choice".

Are you speaking of existing or hypothetical future tooling which would prevent use of deprecated things?

dgryski commented 5 years ago

@bradfitz The "tooling" is staticcheck. There's an open issue for packages (which @dominikh linked in https://github.com/golang/go/issues/30141#issuecomment-462066837 above) but it already warns on the use of deprecated symbols.

FiloSottile commented 5 years ago

Wait, I thought this whole bug was just about adding a "Deprecated: ..." comment, but you refer to an "active choice".

I consider ignoring or silencing a new linting warning an active choice, as opposed to simply not re-reading the package docs for something you already use.

hazcod commented 5 years ago

Not everyone uses tooling like staticcheck tough.

claucece commented 5 years ago

I just wanted to briefly pointed out that while it is true that there are vulnerabilities surrounding PGP (specifically, the CBC/CFB Gadget Attack -although, the current draft of OpenPGP RFC4880 (bis05) reflect the recommendation of the authors to deprecate the SE packet type and that modified ciphertexts should not be displayed-, as Direct Exfiltration is more around abusing vulnerabilities in Apple Mail, iOS Mail and Mozilla Thunderbird), some libraries might depend on this pgp to work. Take the case of gopass, which is widely used. I agree on that if this is an unmaintained package, it should be good to deprecate it; but maybe giving a solution to projects that use it will be in place.

  • the protocol predates modern cryptography engineering, which is still causing severe vulnerabilities, and any new project should rely on alternative modern solutions

I'm not aware of any alternative modern solutions to pgp that are widely deployed.

I think that deprecating is a right approach; but maybe with giving alternatives as well :)

My two cents :)

gtank commented 5 years ago

I don't think there is a direct modern alternative to PGP, because the modern alternative is to use more specific solutions to your problem. For example, here's two common uses of PGP and some modern, maintained alternatives:

This is the wrong place to be litigating the future of PGP, so I'm going to stop doing it. If you're the maintainer of a widely used Go package that depends on x/crypto/openpgp, feel free to message me off-thread! I will be happy to look at your use case to see if we can think of something that will get you away from it.

mimoo commented 5 years ago

It's sad but there isn't much alternatives to PGP out there. I personally use this tiny script I made to encrypt content to people and give them the key in another channel.

FiloSottile commented 5 years ago

Polite nudge not to litigate the state of PGP in this issue. Only comment if you think your remark has not been made above, and it might change the decision to deprecate even if there are multiple reasons to deprecate openpgp/.

ddevault commented 5 years ago

I intend to add OpenPGP support to my email client, written in Go, and had considered using this library for that purpose. The remarks in this thread about the dangers and obsolecene of PGP are obscenely exagerrated.

Mikotochan commented 5 years ago

Efail has nothing to do with the openpgp and a lot to do with programs that used the GPG api incorrectly.

tarcieri commented 5 years ago

The OpenPGP specification predates authenticated encryption, and retroactively added bespoke authentication schemes. There have been attempts to modernize OpenPGP by adding support for authenticated encryption modes, however these proposals never made it to the RFC stage.

The lack of authenticated encryption is the root cause of Efail's CBC/CFB gadget attack as CBC and CFB are both unauthenticated encryption modes. The recommended protocol changes to avoid similar attacks in the future were as follows (emphasis mine):

How did EFAIL influence the developments in the current standards?

There is an ongoing work on two new email security standards. Both considered countermeasures presented in our paper. The S/MIME standard draft references our EFAIL paper and recommends the usage of authenticated encryption with AES-GCM. Furthermore, it warns that different parts in multipart/mixed emails should be treated as being of different origins. The OpenPGP standard draft deprecates Symmetrically Encrypted (SE) data packets which are not protected by MDCs. It proposes AEAD protected data packets and mentions that the implementation should not allow users to access erroneous data.

regarding @Mikotochan's comment:

...used the GPG api incorrectly.

Blaming the users of cryptographic APIs for their failure to use them correctly has shown itself to be a particularly bad strategy for developing secure software. The alternative many developers of cryptographic libraries have pursued as a result is designing hard-to-misuse (a.k.a. "misuse resistant") APIs.

That seems to be the direction @FiloSottile would like to go with x/crypto.

ddevault commented 5 years ago

x/crypto doesn't implement the GPG API. It implements PGP.

tarcieri commented 5 years ago

@ddevault as I just mentioned, it implements OpenPGP. Do you have a specific concern about what I just said regarding the deficiencies of the OpenPGP protocol?

ddevault commented 5 years ago

Yes. You quoted:

...used the GPG api incorrectly.

The GPG API is a porcelain CLI tool. OpenPGP is a standard. By my measure x/crypto is already doing a damn good job of avoiding the problems which led to EFAIL: shitty usage of the GPG command line tool by applications.

tarcieri commented 5 years ago

The GPG API is a porcelain CLI tool. OpenPGP is a standard.

That is why I specifically asked you:

Do you have a specific concern about what I just said regarding the deficiencies of the OpenPGP protocol?

It would appear you are the one colluding the CLI tool with the protocol. So I'll ask you again: is there something about my analysis of the OpenPGP protocol you take issue with?

ddevault commented 5 years ago

You're conflating EFAIL, GPG, and OpenPGP into a single incoherent argument. I'm trying to disentangle it.

tarcieri commented 5 years ago

If your problem is collusion of terms, could you please respond to my questions about the OpenPGP protocol without colluding terms yourself?

ddevault commented 5 years ago

As far as I can tell, you haven't actually said anything at all about OpenPGP.

tarcieri commented 5 years ago

I will quote https://efail.de/ again:

How did EFAIL influence the developments in the current standards?

[...] The OpenPGP standard draft deprecates Symmetrically Encrypted (SE) data packets which are not protected by MDCs. It proposes AEAD protected data packets and mentions that the implementation should not allow users to access erroneous data.

The larger point is that Efail was recognized by the relevant authors of the OpenPGP and S/MIME standards as a protocol-level failure, which there is ongoing work to address.

ddevault commented 5 years ago

"EFAIL" is an alarmist puff piece written by morons to slander PGP and inflate their egos. The standards don't need to change to fix the problems it mentions. The proposals help... marginally. The problem is not and was never with OpenPGP, it's with poorly written email clients (e.g. all email clients).

ghost commented 5 years ago

I know this is a discussion and note a vote, but if I could vote on this, I'd vote to not deprecate OpenPGP. It has RFCs (2440, 4880) and is widely deployed in corporations and security firms. I use it a lot (in and out of Go) to encrypt files to multiple keys and it works well. I do agree with you that it is complicated and I can imagine it is hard to maintain (I've opened issues that your guys have fixed)... Thanks for doing that!

I don't feel as strongly about the other algos/methods, but I like blowfish a lot, too, it's pretty decent. And if you care at all about Windows Active Directory, then you need MD4 which is the heart of NTLM hashes and still widely used in corporate environments. I know, it's a weak hash, but that's the reality we have to deal with as developers in the trenches where Go is a god send.

Thanks for the consideration.

ianlancetaylor commented 5 years ago

Please keep the conversation polite and respectful. Thanks.

Mikotochan commented 5 years ago

@tarcieri You could argue that the reason that programs used the GPG api is that the GPG api is crap, but this is absolutely irrelevant to the issue at hand which concerns OpenPGP as a standard. I also never blamed anyone, so please do not put words in my mouth.

The OpenPGP standard right now supports something called MDS (Modification Detection Code) which prevents the attack described in Efail, even though it uses CFB.