analogist

Ah yes, enforcing the law, which, “in its majestic equality, forbids rich and poor alike to sleep under bridges, to beg in the streets, and to steal their bread.”

So you think there is no difference in guilt between being a war criminal’s arm dealer and being a war criminal’s grocer?

> PS: your mention of that Twitter account is creepy.

With no context, I agree. But I'm not exactly stalking engineers here - there was literally a direct link to that twitter from the Fastmail updates mailing list that went out, when customers were notified of the NYI datacenter move. Made me do a double take.

Hi Bron. I'm a customer of both Fastmail and GSuite, and I have enjoyed your service for a few years now. I still use Fastmail for some things, like sieve, and very much will continue paying just for the ongoing development of open-standard email like JMAP. But there are definitely a few things that I can't shake when I learned about them that very much pertains to the security mindset that prevents me from moving my primary emails onto Fastmail.

Security paradigms have been steadily moving beyond a hard-boundary-soft-center, to a defense-in-depth, distrust-your-own-services model. I was alarmed to learn last year, for example, that you use OpenVPN with fixed symmetric keys (--secret) rather than TLS with any forward secrecy (--tls-auth) for VPN between your NYI and AMS datacenters. https://blog.fastmail.com/2016/12/19/secure-datacentre-inter...

Presumably, running datalinks like this means you would have to have perfect trust in your long term key management and rotation. Is that something you plan on improving in the future?

Similarly -- I stumbled on this entirely by accident after your blog post about moving datacenters -- that your head of security ops & infrastructure tweeted "I will probably root my phone soon because Samsung's emoji set is worse than not having convenient OTA updates" https://twitter.com/robn/status/919194089920311296

I don't want to conflate anything -- a tweet on an engineer's own time about their personal devices isn't by itself a security problem. But it does reflect on the security mindset. If you had a BYOD policy, and this phone did end up being flashed to Lineage and be 3 patch levels behind (esp with Android's track record of RCE-via-media CVEs), this could definitely become a weakness on your entire infrastructure, and thereby on all of us as customers.

This is the type of thing I couldn't shake after learning about it. Of course, trust has to be placed somewhere. You have to be able to place trust on your ops and your infrastructure, but that's also a process, not a checkbox. People and devices can be trusted a little less in the overall security system, to provide redundant security. Could you clarify your position on how your staff is trained about the human weak points, security as a lifestyle if you're security and ops, and how your security mindset incorporates defense in depth?

> I’m not willing to stick my neck out

> empathy gap

Maybe if you were more open to helping them with threats to their livelihood, dignity, and well-being, they’d be more open to helping you with yours?

I don’t know, just a thought.

@bascule addresses deterministic password managers as a category here:

https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

Certainly you’ve considered these points, and I’m interested in hearing your responses to these points if you’re using this scheme yourself and want others to use it.

I’m particularly interested in point 4 where, unlike traditional password managers like 1Password and Lastpass, where you need both the password and some form of data access, the leakage of my master password (say by a shoulder surfing security camera at any time) literally means every credential can be derived from scratch at any time.

This is so obvious that the first thing I would do is look to see if they've addressed it in some way, instead of assuming incompetence.

If you have gone through the process of being charitable-first, instead of dismissive-first, then you would notice that they have explicitly spent engineering hours on this exact problem by using an SRP-based session key exchange for mutual authentication (and additional session encryption, in addition to TLS). [1] [2]

It's not easy to engineer for both security and usability, so I especially appreciate it when someone spends the time to accomplish both.

[1] https://blog.agilebits.com/2015/11/11/how-1password-for-team... [2] https://1password.com/files/1Password%20for%20Teams%20White%...

Because they don't transmit your encryption password.

Authentication is not done by sending them your encryption password, but instead the derivation of an SRP static secret (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...) from your password (PBKDF, XOR'd with HKDF of the entropy-boosting pepper that they call the "Secret Key"), and performing a session key exchange handshake, basically like a (non-ephemeral) Diffie Hellman. They then encrypt all future communications (inside of TLS) with the transient session key.

This gets you three things in one swoop:

- Authentication of user

- Authentication of the server (if the remote server doesn't have the stored RSA counterpart of your derived SRP static secret, the exchange can't complete)

- An additional encrypted tunnel independent of TLS, so transport security isn't reliant solely on TLS (Cloudbleed, etc). (The contents being moved around are encrypted yet again)

And:

- User doesn't have to remember a separate password.

- The password and pepper never touch the network, only (non-reversible) session tokens do.

- Having access to traffic inside of TLS (corporate or malicious TLS endpoint interception, for example) still gets you nothing.

There are valid criticisms of 1Password, but you're literally criticizing them for something they've gone out of the way explicitly spent engineering hours solving in a way that not many services have even bothered thinking about.

That's pretty much correct, yeah. Due to exponentiation, length is almost everything in password security. Which means there's going to be a bunch of lengths at which brute force cracking is trivial, and then a very sharp rise in complexity, after which brute force cracking quickly becomes astronomical, and then absolutely impossible.

If you look at the current cracking benchmarks of GPUs (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...), there is an easily quantifiable difference between bcrypt and MD5: 21 bits. (https://www.wolframalpha.com/input/?i=log2(200*%5E9)-log2(10...)

That means under current GPU architecture, bcrypt is basically like "adding 3-4 characters (or 1.5 diceware words)" for free to your password. Can you basically just add 3-4 characters to your password? Sure, but not without user friction, and certainly you can't think that way as the developer of the system, because you're trying to give a small leg up to even the most vulnerable by salting and bcrypt/PBKDF2/Argon hashing.

What about theoretical limits? Well, there is another way to approach this: Landauer's principle (https://en.wikipedia.org/wiki/Landauer%27s_principle), which considers the theoretical minimum energy of a bit flip of information - so this even covers future computing technologies. Even if you used up all available mass-energy in the entire sun, it is only theoretically possible to perform 2^225.2 operations (https://security.stackexchange.com/questions/6141/amount-of-...). 225 bits of entropy is roughly a 35-character (printable ASCII) password.

(Note that you can't do this with MD5 - it has only a 128-bit hash space, before preimage attacks, the best of which lowers it to 123 bits).

So the lesson is: use slow hashes to give some protection to the vulnerable and people whose password complexity is "on the edge". Use a password manager so that the rest of your passwords can be comfortably > 128 bits in complexity, without reuse. And then forget about passwords because after that, every other part of the security system becomes more important.

Wow. This is yet another example of the fatal combination of Rolling Your Own Crypto + Using OpenSSL Directly And Blowing Your Own Foot Off Because It Lets You.

  var cipher = crypto.createCipher('aes-256-ctr', key.toString('hex'))

Besides the completely fatal error of using derived and non-unique IVs (fatal as in, if you encrypt more than 1 item with it, it is exactly as good as plaintext because any two items encrypted with the same key+iv in CTR mode cancels out to plaintext), isn't using hex encoding vastly constraining the possible complexity-per-byte of the key?

A single hard-coded salt for key derivation:

  const key = crypto.pbkdf2Sync(auth, '0945jv209j252x5', 100000, 512, 'sha512');

Again, the salt is only lowercase alphanumeric. This makes this 120-bit salt really just a 77-bit salt. But since it's hard-coded and not randomly generated, it's a 0-bit salt.

Can everyone who is developing crypto apps Just Use NaCl/Libsodium?

Even conventional VPN is not enough. The Great Firewall of China (https://en.wikipedia.org/wiki/Great_Firewall) is a mix of DNS poisoning, deep packet inspection, and traffic and usage analysis based on real time ML. It is very smart and adaptive, and will block most mainstream VPN services, including IPSEC, standard OpenVPN, SSH tunnels, (of course) SOCKS and http proxies.

Besides blocking entire sections of the net outright (like Google address blocks), poisoning controversial domains, etc, even if it can't directly inspect the traffic due to good encryption (say in the instance of OpenVPN or IPSEC), it will slowly degrade and eventually null-route your traffic over the course of minutes, depending on its judgement of the likelihood (based on packet structure and history) that your activity isn't "normal" usage.

Currently the only functional ways of getting around the GFW is VPN through stunnel (TCP OpenVPN traffic re-wrapped in TLS, thus pretending to be https traffic, and incurring triple TCP performance penalties), similar convoluted protocols like Shadowsocks, obfsproxy, and other China specific tools.

Summary link by OSTIF, which includes a quick synopsis of both audits, and link to full report on OpenVPN 2.4 by OSTIF:

https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...

Matthew Green/Cryptography Engineering audit direct link, which focuses more heavily on the protocol design, as well as a 2.2->2.4 changelog audit:

https://www.privateinternetaccess.com/blog/2017/05/openvpn-2...

So you would be fine with your local restaurant "denying service" and locking the doors only when the food safety inspectors show up?

That seems to be pretty weak evidence of verification not being through TLS. There could easily be an additional connectivity check that is http-based (that was blocked by the captive portal) before proceeding onto a standard TLS handshake.

As 'klodolph mentions, there's a lot of layers of verification for software updates. Before install proceeds, the verification requires a cryptographic signature from an Apple authorization server in response to submitted device ID + hashes of the package to be installed. Then at boot time, the signature is verified again by the standard boot process (burnt-into-silicon Apple root CA pubkey verifies the bootloader integrity, which then verifies the iOS kernel integrity, which then re-hashes the update package and re-verifies the signatures to make sure there's not a rootkit or MITM interfering with hashing and verification). Only then is an update actually allowed to be installed.

I think a recurrent concern is OpenVPN's reliance on TLS, and its codebase complexity as a result of being built on OpenSSL--but with far less attention and resources and vuln hunting compared to say, actual browsers. Complexity + lack of auditing person-hours is never a good combo. (See https://twitter.com/tqbf/status/806646188158152705)

Matt Green's audit of OpenVPN, when completed, may lead to more light on the matter. Otherwise, we're just relying on informed intuitions.

I'm no expert, but intuitively it would seem that encryption-inside-encryption would be snake oil when they're meant to guard against the same layer/attack vector/threat model: for example, if you nest Serpent inside AES for a single local file encryption operation (ahem, TrueCrypt), that seems very gimmicky.

But if the encryption are supposed to protect separate and independent OSI layers or operation steps, then it would seem to me it's fully valid - specifically, in this case: - TLS dissolves inside HTTP-HTTPd endpoints or any reverse proxies, if used - additional SRP-negotiated AES dissolves inside client to the process doing key handling - final "actual" key encryption, handling at-rest encryption, and to make sure it's zero-knowledge to the storage handler

They seem to me to be guarding information leakage against very different parts of the key mangement process (storage, manipulation, http transport), and that doesn't seem to be snake oil to me.

Inside of TLS, 1Password uses an additional SRP handshake that negotiates a static secret (like a DHE), which 1Password uses to both authenticate the user and set up an additional AES-GCM transport encryption.

So even a full memory dump of what's transported in TLS should, as long as it's properly implemented, only reveal an SRP authentication session and subsequently symmetrically encrypted data.

(And inside that SRP-negotiated encryption should only be more symmetrically encrypted vault items, and RSA-encrypted vault keys. If properly implemented even complete TLS breaks do not break 1Password at all, even the cloud version. Properly implemented being the key words of course.)

As a neuroengineer working in the field, this is quite accurate. Understanding the compute architecture goes a loooong way - after all, acoustic RSA key extraction (https://www.tau.ac.il/~tromer/acoustic/) is possible. Whereas we're not exactly even sure how the brain is supposed to theoretically compute, other than that it's tremendously parallelized to a degree we don't quite fathom. The electronics explosion has primarily come out of computational motifs that rely on the lightspeed resolution of semiconductor gates and heavily rely on sequential processing, but the brain doesn't work this way AT ALL.

An important concept here is the 100-steps-rule (https://www.teco.edu/~albrecht/neuro/html/node7.html) - neurons are SLOW! You can out-jog most non-myelinated neural signals, and the vast majority of sensory and motor computations finish in the order of 100 "clock cycles".

Write me a computer vision algorithm that has enough parallelism to complete in 100 cycles, and we can talk about understanding the biological brain compute structure and true brain-computer interfaces.

Isn't that's just a description of all TLS? ECDHE/DHE key exchange is essentially employed on any non-poorly configured modern https site, TLS 1.0-1.3draft.

What can a technologist do about climate change? (2015)

http://worrydream.com/ClimateChange/

TL;DR: better energy production/transportation methods, data-driven tools for finding bottle necks in production systems, information distribution for infrastructure and coordination and energy demand, making better tools to collect, analyze, present, and change minds.

Basically the same talent and sweat we put into getting 1% more click through rate to put on the slide deck for the next VC funding pitch, except, you know, put towards not having our grandkids die. You know, that kind of stuff.

"If any 'founders' out there want to 'disrupt' our 401 ppm atmospheric CO2, or 'moonshot' ocean acidification, that would be cool"

"minimum viable planet"

I'm not sure where all the aggression and distrust comes from, but if you had done a a simple search, you would easily see that your points are false.

1) a) Every single line shown are thin lines except for the 6 lowest average-ice years, which is clearly marked in the legend (2006-7, 11-12, 16-17). That makes for 34 thin lines and 6 thick lines. b) Also, why would that visual distinction be misleading again? All it would emphasize are when the low-ice time periods are - in the recent decades. It's not like there was a low-ice period in 1979 or something that the author intentionally made thin.

2) It is not visually possible to pick 40 colors that are distinct enough in color space that you can consistently tell at a glance (i.e. when you look away and only compare the next color from memory). Go ahead and try it. Visual perception researchers have tried (http://vis.stanford.edu/color-names/) and the best you're going to get is maybe 12 (http://colorbrewer2.org/)

3) This is so wrong, it's not even wrong: a) the data only existed starting in 1978, because the Nimbus 7 launched in 1978, so this is the whole available data (http://psc.apl.washington.edu/zhang/Global_seaice/). b) Global sea ice isn't in perfect lockstep with temperature, but larger temperature trends and currents and other factors, so talking about a handful of warmer or colder years doesn't even make sense. c) Even if it were, I still don't know what you're talking about. See the NASA land-ocean temperature index (http://climate.nasa.gov/vital-signs/global-temperature/). You could have started in 1977, or 76, or 75... you'd have to go all the way back to 1945 to find a warmer year, and that would be missing the whole point of the overwhelming trend.

I'd be very careful to make sure that I'm not the one doing the public a disservice when I openly accuse people of manipulating data. I wish everyone showed a similar courtesy.

The symmetric algorithm aside, if we just look at the key derivation, the --s2k* parameters go up to 65011712 rounds of SHA512. If you maxed out the --s2k* settings, its difference from the 1.4.12 default of 65536 rounds of SHA1 is not staggering, but not trivial either: 10 extra bits from the additional rounds and an additional 3-4 bits from straight SHA1 to straight SHA512, on modern GPUs (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...).

An additional 13 bits of safety margin basically gives you an extra Diceware word (log2(7776)), which, I agree, isn't a magical solution at all, but would to me cross the threshold of "it has some actual impact".

Of course, having much better usability for the average user, or just breaking OpenPGP compatibility so there are clean modern robust constructions like NaCl/libsodium running underneath are way better ways to get at good security margins, but here we are.

As of Kernel 4.8, Ted Ts'o has already switched /dev/urandom over to ChaCha20 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), so I would say a good CSPRNG's already done.