Hacker News Reader

Comment by distcs | Hacker News Reader

For me the biggest problem with a setup like this is complete loss of access to my secrets. The crypto functions supported by browsers may change in future. A cipher algorithm used to encrypt my secrets may get deprecated and removed by the browser in future. Then I will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore.

GPG or vim -x might be much better choices for secrets that need to be decrypted many years from now.

View on HN

> For me the biggest problem with a setup like this is complete loss of access to my secrets. The crypto functions supported by browsers may change in future. A cipher algorithm used to encrypt my secrets may get deprecated and removed by the browser in future

These are NIST-recommended algorithms, they'll be around for a while...

Make sure to read this before using vim for anything crypto related!

https://github.com/vim/vim/issues/638

To sum things up, the Vim maintainers are totally ignorant on the topic of cryptography, but what's worse is that they are highly stubborn and refuse to accept their ignorance while ignoring valid criticism from people who do know. This combination of traits does not mix well with cryptography, where doing things correctly is extremely difficult but also extremely important.

I am not totally sure whether this specific issue has been fixed since I last checked this out, but at the time Vim's encryption was totally broken and should not have been used at all.

I am not too familiar with Vim overall, but Emacs file encryption uses GPG to do all of the important stuff, and just provides a nice interface to that. I imagine Vim has something similar available at least as a third party extension. Letting something like GPG or Age handle the important stuff is a much better way of handling this!

I can't for the life of me understand why people haven't just switched to Neovim. Sure fine vim might be what's on your server but for your actual personal development work it's, to me, better in every way.

My main hesitation is that I like being able to drop my vimrc anywhere and have an (almost) identical editor experience, rather than having to maintain one config for vim and one for neovim. Been meaning to try neovim out though!

You can source your .vimrc from neovim if you’re interested. I’ve been separating plugins based on the environment they depend on as well.

All of these crypto functions have many implementations in every popular programming language that return the exact same bits no matter which implementation you use. As long as you have the keys (which is a serious issue) and someone remembers which function was used with which parameters the risk of "will be left with a bunch of HTML files with data that the browsers cannot decrypt anymore." is not even on the same scale as getting hit by lightning but rather on the same scale as getting hit by lightning during clear weather in a deep basement.

I remember a few years ago on Discovery Channel, there was a documentary about people hit by lightning. One was hit by lightning 3 times, all 3 times on forehead, and survived to tell the story on record (you could see his forehead having very clear view of its underlying sanguine vessels as secondary effect).

But one story that particularly stood out was of a woman who was hit by lightning during clear weather, inside the house, through the water pipes - she was cleaning dishes at the time. So your scale might be still too small.

GPG for sure, be very careful with "vim -x" as that's the only implementation of that encryption scheme, not supported in neovim anymore (and I've found security issues in it: https://dgl.cx/2014/10/vim-blowfish, "blowfish2" is just ok, but it's frankly still there to not break people's workflow, I would think very carefully before using it).

Annoyingly this technique uses AES-GCM (which is good!) but OpenSSL's command line tool can't cope with it: https://github.com/openssl/openssl/issues/12220

It would be nice to have a command line tool to extract these files too, then you know the implementation is correct. (Blowing my own trumpet but my very old project https://paste.sh does this.)

The algorithms are well-documented and not difficult to implement (for the purpose of decrypting). The only real risk I would see is for a post-apocalyptic future when that knowledge has somehow become lost or inaccessible. And that’s assuming that any of the secrets would still be relevant then.

Standardized web APIs are very rarely removed. Backwards compatibility is a huge priority for web APIs, and cases where they're broken are rare. It's very hard for me to even think of a web API like this that browsers have ever made incompatible changes to.

The parts of the web that get incompatible changes are generally stuff like nonstandard plugins (Flash being discontinued) and TLS (which isn't relevant if you're keeping some HTML file saved locally). Browsers bend over backwards to keep existing HTML/JS content working.

True, they are deprecated first.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That page supports my point! Most of the things in that list still work in browsers, and the few things that don't still work look like they're all things that never got standardized to begin with.

A neat feature of this would be to have the source of the html include instructions for decrypting the data outside the browser using command line tools for just this scenario.

Looking at the HTML/JS code does tell you how to implement decryption in a different language.

That's because it only uses NIST recommended encryption, which is baked in or available in most languages.

Yes, but making it really easy by giving the exact openssl (or whatever) commands would be super useful if you needed to do it.

> The crypto functions supported by browsers may change in future.

Legacy versions of Firefox should be available in some archive, nevertheless. For additional security, you may use them on an air gapped system to decrypt our secretes. You need to trust the archive, though (as you need to trust the browser, now).

The web is probably among the best platforms you can bet on. Browsers are super slow to deprecate/remove APIs and it'll be pretty easy to install a browser from today in 20 years.

The crypto functions supported by browsers may change in future.

Could those crypto functions built into the browser be replaced with JavaScript implementations?

Yes, they can. There are libraries already doing that. And while slower than the native implementation in the browser they are still good enough for this tool. So fork the sources of this project and implement in JS those API crypto the browser is using and you're clear to go without relying on them.

You encrypt them again with the newer algorithm?

Just download an older version of the browser?

Ok so in similar manner. Please download Microsoft Silverlight now, only from official MS source. No other source is allowed. Go.

Funny thing, here in EU country, there are government apps which stills require MS Silverlight. Nice right?

To be fair that is not a browser. That's a plugin.

Reply on news.ycombinator.com