bren2013 | 5 years ago | on: Sci-Founder Fellowship: Helping scientists to start companies
bren2013's comments
bren2013 | 7 years ago | on: RPKI – The required cryptographic upgrade to BGP routing
Not key compromise, but general mis-issuance:
Facebook detected overreach by a vendor with CT: https://www.facebook.com/notes/protect-the-graph/early-impac...
AGL detected certs that were malformed in various ways: https://www.imperialviolet.org/2013/08/01/ctpilot.html
> Technically CT is still not required.
It produces an interstitial, see: https://invalid-expected-sct.badssl.com/
bren2013 | 7 years ago | on: RPKI – The required cryptographic upgrade to BGP routing
Right now, the way key compromise might be detected in RPKI is that a human network operator notices a signed object which is obviously suspicious and posts it on a mailing list. This is the same way that CA compromise was detected in the Web PKI before CT.
CT was useful well before Chrome used their weight to make it required for all new certificates because it was no particular burden on a few people (CA or not) who saw a lot of certificates to add them to CT. This gave the people who might not see a lot of certificates but want to find something weird a corpus to dig into.
Same idea applies to RPKI. But yes, setting up Cirrus took very little of my time.
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
- A central API where the bootloader can do arbitrary validation on the API responses.
- WebTorrent, Scuttlebutt, IPFS PubSub, etc.
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
bren2013 | 7 years ago | on: Introducing Cloudflare’s IPFS Gateway
bren2013 | 10 years ago | on: Cryptographic Data Structures
Typical example: Certificate authorities distribute CRLs primarily through untrusted channels and third parties to lower their operating cost. The CRLs are signed so its a win-win for everybody.
bren2013 | 11 years ago | on: Elliptic curve arithmetic and cryptography library in Rust
I don't even like having to implement NIST's speedup for A = -3, and it's fairly trivial.
bren2013 | 11 years ago | on: Elliptic curve arithmetic and cryptography library in Rust
The p-value of the 2-sample T-test was greater than 1%--there's no evidence that one takes less time than the other. That can be replicated by playing with the benchmarks yourself. If you have any evidence to the contrary, I'd be happy to look at it.
bren2013 | 11 years ago | on: Elliptic curve arithmetic and cryptography library in Rust
Issue #2: Rust has explicitly taken all memory management away from me. There's nothing I can do about that.
bren2013 | 11 years ago | on: Elliptic curve arithmetic and cryptography library in Rust
I actually take the above back. Scalar multiplication on a point IS constant-time (the two distributions are indistinguishable).
Field exponentiation isn't constant-time and I will work on that.
bren2013 | 11 years ago | on: Elliptic curve arithmetic and cryptography library in Rust
The addition law only leaks general cases--doubling, negatives, one argument is zero. Is that not generally considered okay? Intuitively, it doesn't seem like terribly valuable information--in the case of the Montgomery ladder, the attacker already knows we do one doubling and one addition per bit.
Earlier, I was using Euler's theorem for inversions, which should have been more constant-time than Euclid's algorithm. The only problem is, it took slightly over a minute to do one scalar multiplication. Could you describe an attack that would come from knowing information about the z-coordinate? Is there a good way to do constant-time inversion?
Edit: I just added a second benchmark testing scalar multiplication for a random value vs one with lots of zeros, and they produce different distributions with or without the #[const_time] (assuming I'm using it right). Thank you for bringing this up! I'll look into what needs tweaking.
bren2013 | 11 years ago | on: Rides of Glory – Uber Blog (2012)
bren2013 | 11 years ago | on: Least worst golden key
bren2013 | 11 years ago | on: The Horror of a 'Secure Golden Key'
I have no idea what you mean by "security vulnerability" in this case. Key escrows are the primary way asymmetric crypto is used in practice. An escrow recovers the symmetric key a message was encrypted with and you proceed as normal.
> the trusted party doesn't have a nuclear neon target painted on it
By that logic, government agencies should operate exclusively by typewriter. They don't because crypto primitives are designed to be secure against unrealistically strong adversaries. No crypto paper has ever said, "Our construction is secure in the standard model as long as the ROI is less than epsilon."
You can go down the path of "what if there's another Snowden, and it's a snow day in Kentucky...," but you aren't doing cryptography anymore--you're just developing mild paranoia.
bren2013 | 11 years ago | on: The Horror of a 'Secure Golden Key'
People are repulsed when you call it a back door or a "golden key," but "secure golden keys" are simply key escrows. Escrows are one of the first things you learn to build after asymmetric crypto.
Escrows are well understood, secure, and generally regarded as a good idea. However, "back doors" are scary, sordid, and insecure?
bren2013 | 11 years ago | on: The Horror of a 'Secure Golden Key'
Predicting the generator's output reduces to solving the discrete logarithm on elliptic curves, which is incredibly hard unless you chose the private key.
Just like in any asymmetric crypto scheme, given only the public key, it's very difficult to find the private key.
(Actually doing it requires knowledge of how the generator works. I promise you it is easy given the private key, but you can go into its internals if you don't believe me.)
> Isn't it just trivial for someone to "recover" your data by pretent to be you by court order, NSL or other means?
Without a "golden key," somebody would have to ask you. With the "golden key," somebody would have to ask the organization in charge OR you.