maxtaco

8 ms·

31.
by maxtaco 7y ago
That was my 90%+ likelihood explanation too, but I figured Slack had its act together, and the risk of being wrong was too high.
32.
by maxtaco 7y ago
https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-r...
33.
by maxtaco 7y ago
Keybase CEO here. Let me tell a quick story. January 2019. I was loading the car to leave for a short family ski vacation when I got a truly horrifying email: that my slack account had been accessed from a distant land (that I hadn't b
34.
by maxtaco 8y ago
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 j
35.
by maxtaco 8y ago
Thank you for taking the time to read the report!
36.
by maxtaco 8y ago
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) m
37.
by maxtaco 8y ago
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)
38.
by maxtaco 8y ago
Seems like it's safe for 2^(64) blocks. That should suffice. https://security.stackexchange.com/questions/27776/block-cha...
39.
by maxtaco 8y ago
We are still very early stages here, but we really like the Anonize system ( https://eprint.iacr.org/2015/681.pdf )
40.
by maxtaco 8y ago
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.
41.
by maxtaco 8y ago
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.
42.
by maxtaco 8y ago
Thanks for the mention! We designed Keybase with these exact attacks in mind.
43.
by maxtaco 8y ago
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
44.
The Great Filter: Why You Shouldn’t ICO on Ethereum(medium.com)
7 points by maxtaco 8y ago|1 comments
45.
by maxtaco 8y ago
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 armor
46.
by maxtaco 8y ago
Thanks!
47.
by maxtaco 8y ago
Cool! I would store this file on keybase’s KBFS so it’s available on all of your machines.
48.
by maxtaco 8y ago
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&#x2
49.
by maxtaco 9y ago
Should drop in the next release.
50.
by maxtaco 9y ago
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
51.
by maxtaco 9y ago
Looks like you also got a PUK, but after a delay. Signature here: https://keybase.io/tanderson/sigchain#9b066b9a96f8d041cf7b55...
52.
by maxtaco 9y ago
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.
53.
by maxtaco 9y ago
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 us
54.
by maxtaco 10y ago
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 kno
55.
by maxtaco 11y ago
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 l
56.
by maxtaco 11y ago
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,
57.
by maxtaco 11y ago
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 encrypt
58.
by maxtaco 11y ago
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.
59.
by maxtaco 12y ago
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]
60.
by maxtaco 12y ago
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

More ›