Hacker News Reader

Comment by amaks | Hacker News Reader

"Microsoft was initially given a May 12, 2015 deadline, but this deadline was extended to July 19 at the vendor’s request. Since the company failed to meet this deadline, ZDI has decided to inform users of the existence of this flaw."

I would expect Microsoft to handle security vulnerabilities with a higher priority. Not sure why they are dropping this on the floor.

View on HN

At some point I prototyped a tool that used Ron Rivest's timelock puzzles (repeated squaring modulo the product of two large safe primes takes a long time and isn't parallelizable, but is quick to compute if you can factor the modulus) to encrypt compressed tarballs of zero-day disclosures.

The idea would be that if you found a vulnerability in a product whose vendor was likely to pour more money into gag orders and legal threats than into fixing the vulnerability, you would publish the vulnerability encrypted in such a way that it would take several years of continuous computation to get the decryption key. Legal threats and/or general foot dragging couldn't put the cat back in the bag.

Sometimes I regret not publishing the tool.

Do you still have access to the source? Sounds a really interesting tool even if just partly completed.

Here is an implementation of the same thing, but tailored toward encrypting Bitcoin private keys. Generalizing shouldn't be too difficult if you're interested: https://github.com/petertodd/timelock

Also a good article by Gwern about the same topic: http://www.gwern.net/Self-decrypting%20files

No, the implementation you link to uses parallel-serial hash chains. Using that implementation, the person creating the file has to do as much work as the person reading the file, it's just that the creation can be parallelized. Use the linked to code, if you'd need to dedicate 1.5 months on a 16-core machine to generate a file that takes 2 years to read.

I'm suggesting something based on quadratic residues moduo a Blum integer instead of repeated hashing. This allows a shortcut if you know how to factor the Blum integer. It takes a few minutes on a single core to create a file that would take 2 years to read. Most of the file creation time is spent checking large random numbers for primality.

There are tradeoffs between the two different ways of creating timelock puzzles, but for the time being, I'm willing to assume anyone who can factor an 8192-bit number in under 2 years has better things to do with their cracker than decrypt my 0-day.

I suppose it would be nice to have a hybrid system where you could have stronger guarantees that someone capable of factoring 8102-bit integers would still need (for instance) at least 6 months of computing hash chains after they finished solving the quadratic residue portion of the problem, and someone who couldn't factor 8192-bit integers would spend (for instance) 18 months computing quadratic residues, followed by those 6 months of hash chaining. This would need 11.25 days of compute time on a 16-core machine to set up the hash chains, but at least it's not months of setup time.

I should point out that I would suggest using the solution to the quadratic residue problem as a key for a Blum Blum Shub stream cipher to encrypt the hash chains and the message, so that portion of the system only relies on square roots and quadratic residues modulo a Blum integer. (Using the quadratic residue solution as a key for AES-GCM or ChaCha20-Poly1035 would open you up to weaknesses in those ciphers, and in this case the slowness of Blum Blum Shub isn't a problem.)

Then, for the inner puzzle, I would use hash chains using a hash in the Blake family to generate a ChaCha20-Poly1305 key to encrypt the plaintext. Since Blake's round function is based on ChaCha20, this also reduces the number of different primitives you're relying on.

In the end, the cipher text would be doubly encrypted with Blum Blum Shub and ChaCha20-Poly1305, with keys being the solutions to repeated quadratic residue modulo a Blum integer and repeated hash chains using a hash from the Blake family. This minimizes the number of possible points of failure.

I'm sure there's a lot that goes into fixing these, but Adobe surprised many in the security community with their fast and responsible reaction to the zero-day flaws unveiled by the Hacking Team leaks.

Microsoft has the resources to fix these; I'm not sure what their excuse is (and it may be valid), but vulnerabilities like this should take highest priority.

> Microsoft has the resources to fix these;

I agree, and have to assume the time to fix is back testing and checking with big vendors/users if the fix inadvertently breaks something they were relying on. At this point how many windows bugs are now features set in stone and must be carried on in perpetuity because so much software has been built around the buggy behavior?

Lots, but RCE is never a feature that will be set in stone.

Reply on news.ycombinator.com