[feature request] implement Galois/Counter Mode (GCM)

[ghost]

Cipher Block Chaining Mode (CBC) is known to be vulnerable and current practice suggests/cautions to utilize Galois/Counter Mode (GCM) instead.

[perry-mitchell]

Hi @n8v8R - Do you have any source for such claims? I don't believe CBC to be vulnerable to any specific attacks - It's extremely widely used and at specifications inferior to that which we use in buttercup.

On a side note: We initially did use GCM in the early versions, but due to poor device support and browser implementations, we were not able to continue with that. We chose CBC with 256bit keys because:

• It is secure
• It's supported practically everywhere

EDIT: I would prefer to use GCM everywhere, but it would have to be supported on all of our target platforms, as well as having decent performance.

[ghost]

Just look for CBC padding attack/vulnerability.

Padding oracles and the decline of CBC-mode cipher suites
AES Chain Block Cipher vs Galois/Counter Modes of Operation
RH CBC advisory

[perry-mitchell]

While I agree there are issues with CBC, it still reads that they're mostly implementation-based issues. For instance, a quote from one of your articles:

There are still valid uses of CBC mode (such as for encrypting static content)

(Regarding encrypting over TLS, or the preferred use from encrypt-then-mac)

Our encryption processes cannot be initiated from webpages etc., so an attacker really couldn't initiate unwarranted network transmissions of archives. If the whole machine is compromised then all bets are off, like with most software, but for the cases outlined in those articles I could say that they do not apply to our application model.

Not that it's a reason to stick to CBC, but some competitors still use it (and at a much larger scale than us). It seems that Lastpass still use it (seems so from some public repos owned by them). 1password use GCM, so that's interesting.

I'm resisting the notion that there is a need to move to something like GCM primarily because I don't think that archive safety is currently in question. That, and the fact that we'd need to make sure that it can work over every application we provide. We'd need implementations in Objective-C, Java, NodeJS and plain JS for the browser (Chrome, Firefox, Safari, Opera and eventually Edge).

It's a huge amount of work to undertake, so I'd really love to hear specifically that what we're doing is insecure and GCM implementation is possible on our application stack.

Beyond that, thanks for taking a look into this 👍

[ghost]

According to this Enpass Security Whitepaper they are currently deploying CBC as well.

The point I was trying bring across is that CBC has known vulnerabilities which GCM is not yet plagued with. And numerous security advisories suggests to prefer GCM over CBC. But admittedly I am not a guru on encryption, not even expert, call a perhaps observer.

That said it seems that the additional https transport vector in web transmission is a certain enabler for CBC attacks and thus static content might be less prone. Not sure how much computing power and code knowledge is required to stage an attack on static CBC encrypted content.

Whether CBC or CGM will probably not matter to the majority of your (potential) user base and thus likely not provide an edge over the competition, at least not today. For me it would eventually, but within the mix of the app's usability (reason for switching from Enpass).
I fully appreciate and understand your reasoning thus.

Feel at liberty to close this "issue" and perhaps revisit it at a later stage.

N.B. To my understanding your code has not undergone a 3rd party security audit to scrutinize the implementation of the encryption features?

[perry-mitchell]

The point I was trying bring across is that CBC has known vulnerabilities which GCM is not yet plagued with. And numerous security advisories suggests to prefer GCM over CBC.

I definitely agree with this.

Not sure how much computing power and code knowledge is required to stage an attack on static CBC encrypted content.

That's what this boils down to I guess.. How likely is it that our statically encrypted CBC content could be compromised using a known or new attack on the CBC method.. Definitely happy to be shown hard evidence that what we're doing in the core (and subsequently iocane, the encryption library) is wrong and that we should change - Hoping that's not the case but I'm also far from being any kind of expert on the matter.

Whether CBC or CGM will probably not matter to the majority of your (potential) user base and thus likely not provide an edge over the competition, at least not today

Of course if it were known that we were risking even one of our users' archives with some faulty or deprecated use of encryption I'd absolutely vote for an upgrade. I definitely appreciate the insight.

app's usability (reason for switching from Enpass)

Great to hear!

Feel at liberty to close this "issue" and perhaps revisit it at a later stage.

Visibility is perhaps better if left open - I don't want to close the conversation on this topic. Like I mentioned earlier, GCM was the targeted implementation earlier - Ultimately it makes sense to end up there. The only item needing discussion in my opinion is when 😊.

[perry-mitchell]

TLDR; (for newcomers)

Setting up GCM would be ideal, but there's some huge items to tackle before that would be possible:

• iocane would need GCM support
• This library (core) would need to maintain CBC support and implement GCM support in parallel (preferring CBC to begin with)
• All other libraries and apps would need to have the same done (CBC + GCM support (read & write), but prefer CBC)
• After some time of being live (user adoption of new versions), we could switch to using GCM as a preference (supporting both still)
• After an even longer time, we could drop support for CBC

If anyone wants to start that ball rolling, we'd love the help of course. Please make sure you discuss with @sallar or myself before starting, however 😁

[lukechilds]

Just found this issue, I'm not sure Buttercup is a good candidate for GCM. Reasoning here:

perry-mitchell/iocane#28 (comment)