Four RCE Zero-Day Flaws Plague Internet Explorer • Hacker News Board

Re: Four RCE Zero-Day Flaws Plague Internet Explorer

#31

Post by WalterGR » Fri, Jul 24, 2015, 6:50 PM UTC

na85 wrote: post #29

MichaelGG wrote: post #28

Earlier quoted context omitted.

Bad management? Thinking HP wouldn't release and putting people on other tasks in prep for Win 10? Not believing they were critical? Some messed up test or compatibility interaction that ended up slipping the release? Anything else interesting? How long do you think these will go unpatched? If they patch them in a week, will you change your opinion to "wow MS has talent but made a mistake"? Coming to the conclusion t…

MSN Messenger was playing catchup to ICQ, they only became a leader by process of elimination when ICQ turned into adware and MSN was the only non-awful contender.

So it became successful because it was the best option? I don't think that deserves the dismissive "only became successful because..."

Re: Four RCE Zero-Day Flaws Plague Internet Explorer

#32

Post by na85 » Sat, Jul 25, 2015, 1:12 AM UTC

WalterGR wrote: post #31

na85 wrote: post #29

Earlier quoted context omitted.

MSN Messenger was playing catchup to ICQ, they only became a leader by process of elimination when ICQ turned into adware and MSN was the only non-awful contender.

So it became successful because it was the best option? I don't think that deserves the dismissive "only became successful because..."

The best deep-fried snack is still unhealthy. Being the best in a field of crap isn't much of an accolade.

Re: Four RCE Zero-Day Flaws Plague Internet Explorer

#33

Post by KMag » Sat, Jul 25, 2015, 4:50 AM UTC

tylersmith wrote: post #30

trengrj wrote: post #26

Earlier quoted context omitted.

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.

Re: Four RCE Zero-Day Flaws Plague Internet Explorer

#34

Post by KMag » Sat, Jul 25, 2015, 11:31 AM UTC

KMag wrote: post #33

tylersmith wrote: post #30

Earlier quoted context omitted.

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 B…

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.