> I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones?
Is Cirrus mentioned in the blog post? I can't find it.
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.
Not sure if this fully addresses your use-case, but I like the idea of serving a static bootloader from IPFS. The bootloader would contain all of a website's assets, and code for getting dynamic content from a backend. The backend could be:
- A central API where the bootloader can do arbitrary validation on the API responses.
I believe the IPFS team has already built a browser extension that runs a js-ipfs node. Running an IPFS node is not ideal for power and bandwidth constrained devices like a mobile phone. This is where I see gateways fitting in, long-term. Not having to trust a gateway unconditionally is necessary to make this viable.
There are lots of scenarios where you would want to let an untrusted intermediary handle critical operations for you without actually having to build trust with them.
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.
I've tested a scalar of about 50% 1s against a scalar with almost no 1s, measuring at the nanosecond resolution, with 100 samples each.
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.
About ElGamal: Agreed. I only planned to implement it for my own satisfaction, more than for anything else.
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.
Uber employees are the kind of people who kept a telescope in their bedroom window to peep on girls down the street. I'll never understand why they're still in business.
> Using key escrow as a method of e.g. password recovery is a security vulnerability.
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.
So what you're saying is, "golden keys" are no less secure than any other form of encryption.
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?
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.