maxtaco

Great point. The fact that street parking is roughly free in NYC both encourages drivers to drive and causes unnecessary bottlenecks on congested major thoroughfares. Take, for instance, 86th Street. One lane taken up by parked cars, plus just one double-parked truck means most crosstown traffic along that latitude and in that direction (including packed busses) must single-flight. That the city chooses to keep commuters stuck in traffic to accommodate disused cars is a pessimal allocation of precious street area.

Thank you for taking the time to read the report!

Keybase affiliate here.

Correct: forward secrecy isn't on by default. We think there's a trade-off here. With forward secrecy, your old messages won't be visible on a new device, but users want this since Slack (and others) make it seem natural. However, you can opt-in to forward security on a per-message or per-conversation basis.

The report says "device and server compromise." Decryption keys never leave the user's client. What they mean is if: (1) the server's stored data is compromised; (2) your phone is also compromised; and (3) the messages weren't marked ephemeral; then the attacker might be able to read past messages, even if the user tried to delete them (i.e., did Keybase really delete the ciphertexts?). This line of reasoning is correct and one of the primary motivations for key ratchets. I don't think the report is claiming that users need to trust Keybase's server in general. They do need to trust Keybase to delete messages that are marked deleted, which would mitigate the attack above if conditions 1 through 3 are met.

From the anonize paper [1]: “Our system is constructed in two steps. We first provide an abstract implementation of secure ad-hoc surveys from generic primitives, such as commitment schemes, signatures schemes, pseudo-random functions (PRF) and generic non-interactive zero-knowledge (NIZK) arguments for NP.”

[1] https://eprint.iacr.org/2015/681.pdf

Seems like it's safe for 2^(64) blocks. That should suffice.

https://security.stackexchange.com/questions/27776/block-cha...

We are still very early stages here, but we really like the Anonize system (https://eprint.iacr.org/2015/681.pdf)

Agreed we could have used either of those. We needed a PRF keyed by the Game ID (so the revealed secrets of this game can't be replayed in the next). Blake2b and SHA3 would also have worked fine.

In theory you are right, but in practice, flips take fewer than 10 blocks of AES output, so the sequence should look random unless AES is very broken.

Edit (and meta-edit): I changed the wording in the FAQ accordingly.

Thanks for the mention! We designed Keybase with these exact attacks in mind.

The problem is that if you assume your encrypted traffic is being collected and stored today, and you want it to stay secret indefinitely, and you anticipate quantum computers will break discrete-log-based crypto in 20 years, then you need to deploy a post-quantum cryptosystem today.

We at keybase developed a PGP replacement called Saltpack. It uses only modern crypto, with all the features you would expect like authenticated encryption and branch-free secret key operations (via the NaCl library). We have a better armoring format that won’t get mangled in modern markdown contexts. It is also integrated with our CLI and in the upcoming release we support encrypting for teams.

https://saltpack.org

Thanks!

Cool! I would store this file on keybase’s KBFS so it’s available on all of your machines.

OKWS author here. I have to take some issue, we made a lot of improvements to the infrastructure over the years. The Tame system for instance was a big one. [1]

[1] https://www.usenix.org/legacy/events/usenix07/tech/full_pape...

Should drop in the next release.

It would be great to see it deployed, but it solves only (1), and even so, not completely. I couldn't find it in the doc, is there a story for revocations? Part of our concern about the PGP story is that malicious servers can suppress revocations. In Keybase's architecture, we've committed to an append-only data structure, which makes it impossible to withhold revocations without being detected. In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain. (BTW, that draft cites Keybase as a motivation for their approach :) )

Looks like you also got a PUK, but after a delay. Signature here: https://keybase.io/tanderson/sigchain#9b066b9a96f8d041cf7b55...

Exactly. Sorry for the doc bug there. s/master key/PUK/g, now fixed on the site. An earlier internal name for PUKs was "master keys" but we've since changed.

In case anyone's curious, all Keybase users are now getting "per user keys" (PUKs). It's a key whose secret key is encrypted for each of your devices, and whose public key is advertised publicly in your sigchain. New users get a PUK right away, and older users run a background thread to make one. wilg's thread missed a window and would have rerun in 50 minutes, but he solved the problem by starting up a different device.

In turn, all team crypto operations happen for PUKs (and not device keys) so it's necessary to have a PUK before you can use teams. These details are mainly hidden from users, except for bugs (as above, but we'll fix it soon). This is a change from previous designs, but the advantage is that when a user adds a new device, she'll get instant access to all teams, when the PUK's secret key is encrypted for the new device. Whenever a user deletes a device, there's a rekey cascade --- the user's PUK is rotated, and so are all teams the user is a member of.

More info here: https://keybase.io/docs/teams/puk

PGP V4 key fingerprints still use SHA-1 exclusively. There hasn't been an update to this part of the RFC as far as I know [1]. Collisions where both preimages are of the attacker's choosing matter less in this context, but who knows what clever attacks people can come up with.

[1] https://tools.ietf.org/html/rfc4880#page-71

For the record, no one ever asked we take down that post. We did it just to be polite.

By contrast, when we sold TheSpark.com to iTurf.com in 2000, we spent several man-months of company time making the parody AyeTurf.com, which pissed a lot of people off.

Very cool work, but blinding is a good countermeasure [1], which all RSA implementations should use.

[1] https://en.wikipedia.org/wiki/Blinding_(cryptography)

Edit: And BTW, yet one more argument for NaCl or libsodium, which boasts "no data-dependent branches."

Plug for https://oneshallpass.com. Open source. Your site-specific password is an HMAC; the key is your password and the payload is the site you're logging in to. Works perfectly offline. You can optionally store an encrypted list of the sites you use (and parameters like number of symbols) to the server.

Just commented on that issue. As you point out, most pure software implementations of AES still use S-Boxes, for better or worse. It's a risk to switch to a less standard and more complicated implementation to mitigate these attacks. Of course if you did TripleSec your data, the cache-timing attack is mitigated by the independent Salsa20 stream.

I moved this to an issue on Github [1]. The key you uploaded to our server has a UID that expired on 2014-11-09. The key you linked to on the MIT key server has updated self-signatures (and subkeys), so doesn't have this problem.

[1] https://github.com/keybase/keybase-issues/issues/1410

Great news and congrats to the GnuPG team. A practical near-term consideration: there are plenty of installs of GPG v1 still in the wild --- people who never even upgraded to 2.0. It might not be a good idea to rush to ECC keys if you want to interoperate with these legacy installs. But for the long term, this is a great development.

We'd like to reimplement ICS using ES6, but keep the await/defer syntax and semantics as they are. The current ICS is a big modification to CoffeeScript, and maintaining the patch is tricky. Hopefully ES6 will ease that headache. But we can't make this change until people's node.js installs have caught up, which might take a while.

SHA1 is the only supported hash algorithm for PGP key fingerprints.

Good suggestion to avoid PKCS v1.5; sadly PGP requires it: http://tools.ietf.org/html/rfc4880#section-13.1

Should be fixed now. The Google End-to-End library uses the 5-byte encoding scheme for signature subpacket lengths, which I hadn't seen used before and was buggy in KBPGP. Most signature subpackets are <192 bytes long and can be encoded with the 2-byte length encoding.

BTW, our library doesn't support the ECC extensions yet, so any encryptions/signatures generated with ECC keys will fail to decrypt/verify on keybase (and also on GPG v1.4).