
Belgian programmer solves MIT’s 20-year-old time capsule cryptographic puzzle - MrXOR
https://www.csail.mit.edu/news/belgian-programmer-solves-mits-20-year-old-cryptographic-puzzle
======
TacticalCoder
That'd be me (fellow HNer and belgian programmer)... Very happy to see this
upvoted up to HN's frontpage! Any question welcome but I cannot post the
solution until the time-capsule opening ceremony on the 15th of May : )

EDIT: WIRED article just in. Haven't read it yet. Link if anyone is
interested: [https://www.wired.com/story/a-programmer-solved-a-20-year-
ol...](https://www.wired.com/story/a-programmer-solved-a-20-year-old-
forgotten-crypto-puzzle/)

EDIT2: forgot to tell but the mining pool Antpool posted a message in the
block header / coinbase data of Bitcoin's block 573138 saying "Congrats
Bernard Fabrot for solving LCS35!". My brother tried to time this with the
press release which was supposed to come out on friday but then the press
release got pushed back to today/monday. So yeah, coinbase data of block 573
138 is kinda very cool (it requires cooperation of a mining pool because it's
not just in a transaction but in a block). TYVM to the everybody at Antpool!
Big thanks for that : )

~~~
zaat
> Bernard Fabrot spent the last three and a half years computing the solution
> to a puzzle

TacticalCoder last HN comment is from Dec 5, 2015. Checks out.

Kudos to you, well done!

~~~
TacticalCoder
I actually thought this might get posted to HN, so I went through a lot of
pain to find back a way to get my HN login back (basically had no access to
the email with which I opened an account here: I had to dive deep down in some
Google Suite tied to a domain name to find a way into the user account and
eventually reset my HN password). I'm glad I did in time and didn't miss this
thread!

~~~
zaat
Well, you sure seems like the kind of guy who will go through a lot of pain to
get quick results.

Was this a side project? did it require much attention after the initial
setup?

~~~
TacticalCoder
> Was this a side project? did it require much attention after the initial
> setup?

Totally a side project.

It hardly required any attention: just making sure the computation was running
and making sure to backup the intermediate results once in a while (I had
backups everywhere of the intermediate results: remote servers, USB keys, DVD,
other computers at home, email, etc.).

I only needed to do a few tiny steps once I found the secret message (which
contains a number which allows to compute one of the two prime numbers).

~~~
zaat
Did you knew for certain that your program will solve the puzzle at some time?
Did you have an estimation of the date?

~~~
TacticalCoder
> Did you knew for certain that your program will solve the puzzle at some
> time?

The description of the problem itself explains a way to verify that
intermediate results are correct.

> Did you have an estimation of the date?

Yes and that one is easy: I wrote a little piece of code (in Clojure,
whatever, it's unrelated to finding the solution) which would check at which
intermediate result the computation was and then compute an "ETA".

Fun story: I'd regularly send my brother something like this...

{ :time-left-in-years 1.239341704718417 :eta "1 year 2 month(s) 26 day(s)"
:percentage-done 0.6284244211583109 }

(that's an actual estimate I found in my old emails)

: )

------
hannob
I just tried to dig into the background of this, the original description is
here:

[https://people.csail.mit.edu/rivest/lcs35-puzzle-
description...](https://people.csail.mit.edu/rivest/lcs35-puzzle-
description.txt)

I have a question and maybe someone can answer it: This indicates that
knowledge of the factorization of the modulus n allows to do this calculation
faster, which is likely how the designers of this puzzle calculated the
result.

However it's not explained how that happens and how the factors of n help. I
assume this may be someone related to RSA, as there you also are able to do
something much faster if you know the factors of a combined modulus. However
in RSA you're able to invert a modular exponentiation. Here you seem to be
able to speedup many successive exponentiations.

Is there some clever way to translate these two problems into each other and
thus use an RSA-like method?

(Update: I found this paper
[https://people.csail.mit.edu/rivest/pubs/RSW96.pdf](https://people.csail.mit.edu/rivest/pubs/RSW96.pdf)
which explains how to do the calculation on page 4, but is still lacking an
explanation why. But I guess for people fluent in number theory it's probably
somehow obvious.)

~~~
acqq
> I guess for people fluent in number theory it's probably somehow obvious

It's "obvious" to the people who are aware of how RSA works, and know that
Rivest based his derivation of the puzzle on the properties on which RSA
encryption also depends.

Note, Rivest is one of Rivest–Shamir–Adleman: "The acronym RSA is made of the
initial letters of the surnames of Ron Rivest, Adi Shamir, and Leonard
Adleman, who first publicly described the algorithm in 1978."

See also:

[https://en.wikipedia.org/wiki/RSA_problem](https://en.wikipedia.org/wiki/RSA_problem)

In shortest and simplest, the "hardest" part is just that the numbers which
have to be processed are _huge_ and that nobody knows an algorithm which would
avoid doing a lot of the calculations to factor such huge numbers. Then for
Rivest as he created the "puzzle" the goal was just how to construct one
special huge number which encrypts the message. Constructing all that is then
by a clever design faster than solving. Those who try to solve the puzzle
don't have the exact construction numbers Rives used, just the result which
has to be attacked by "brute force" calculations. The intermediate results
during that process aren't predictable faster than simply calculating them,
but every next depends on the previous one.

But not _everything_ related to RSA is mathematically rigorously proved, as
you can see in the Wikipedia article.

------
logotype
Wow, congrats! My computer has for the last 16 YEARS been trying to break
RC5-72:
[http://stats.distributed.net/participant/phistory.php?projec...](http://stats.distributed.net/participant/phistory.php?project_id=8&id=422584)

~~~
TacticalCoder
Ah "Ron's Code 5". It's Ron Rivest too ofc!

Good you post this because I had no idea what I could keep my computer busy
with now that LCS35 is solved ; )

------
jey
Wait a minute, did the solution method amount to "do the straightforward thing
using libgmp and then run it for 3 years straight?"

~~~
TacticalCoder
Precisely. And I did this on my everyday workstation, which I also used
simultaneously for coding, browsing, emailing, etc.

Is that not epic? : )

Now I think it's fair to say that part of the solution also consisted in
realizing that using a fast big integer library it was doable in three years
something.

~~~
pure-awesome
Since you were backing up the partial results, I assume this means you could
load such a backup and continue from it if something happened to the running
machine.

Does that mean that you could, if you wished, have switched to a different
machine and just continued where you left off? E.g., could the Peffers team,
if they knew about it, theoretically have taken your partial results and run
them on their FPGA to obtain the final result a little bit faster than if
would have been otherwise?

(Not suggesting this is in any way what you should have done. Just curious)

~~~
TacticalCoder
> Does that mean that you could, if you wished, have switched to a different
> machine and just continued where you left off?

Totally. It's even explained in the original problem description: the idea was
that every year you'd switch to more efficient hardware, picking up the
computation where you let it off, until Moore's law stopped applying.

I considered upgrading from my i7 6700 to a 8700-K overclocked for slightly
faster clock speed (and maybe some instructions taking fewer cycles). It'd
have saved some time.

------
abcd_f
I was going to ask how they would check if the answer is correct, because they
too would need "35 years" to find it...

... but then I realized that N is a product of two primes, which Rivest knows,
so _he_ can take a shortcut and compute the answer faster. That is, the answer
_is_ known.

But this makes you wonder if factoring that N would've been a faster route to
solving this puzzle. What do you guys think?

[1] [https://people.csail.mit.edu/rivest/lcs35-puzzle-
description...](https://people.csail.mit.edu/rivest/lcs35-puzzle-
description.txt)

------
warp_factor
That's why I love HackerNews, you can meet those type of interesting
personalities and ask them questions right here!

Can you tell us a bit more about your self-taught background? What do you do
for a living? How did you hear about the challenge?

~~~
TacticalCoder
I found the challenge by chance. It was so long ago I don't exactly remember
when. Thought it was 2015 but an old comment of mine on HN seems to indicate I
may have started looking into this back in 2014, when I was still using a
core-i5 CPU : )

> Can you tell us a bit more about your self-taught background?

Sure... I started programming in BASIC at 11 years old on the most
inconceivable setup ever: an Atari 2600, which was a gaming console (the
infamous one which lead to the video industry crash of 1983 with a landfill
filled with E.T. cartdridges). So how do you write BASIC on that at 11 years
old? Well your mom offers you a "BASIC cartridge" which comes with a keyboard
in two parts you plug in the joystick ports! (horrible experience but I do
remember writing tiny programs drawing colored lines using that).

Then the Commodore C-64: more BASIC, some assembly using a "power cartrigde",
mainly to modify (hack?) games. Then the Commodore Amiga: learning to write
intros and demos. Then the PC (386, 486, and so on): writing a video game
(finished but never published but it landed me my first job: long way too long
story), writing more intros and demos (won a PC demo compo in Sweden). I'll
blog one day (when I'll have a blog) about that PC / DOS video game which was
running at 60 Hz on a 386 because it used a cool collision detection method I
came up with (which as far as I know is unique and was pixel perfect even back
then and was and still is particularly efficient). I still do have both the
source and the binary for that game.

For the languages I mainly did BASIC then assembly (680x0 and 80x86), C with
inline assembly, C++, Java... Then I stuck with Java for a very long time. Got
a Sun Certified Java Programmer certification around 2000 (which makes me an
oldtimer): only cert I ever got.

I cannot say I didn't do boring Java consultancy for even more boring
companies/organizations. And thankfully once in a while a fun professional
project ; )

Nowadays I'm still programming in Java as for my own projects I like to write
proof of concepts using Clojure (and ClojureScript). And as I'm an Emacs
(IntelliJ for Java though) user if of course waste a lot of time with elisp,
hacking my Emacs config!

I hope you still love HN ; )

------
dzdt
Given that processor technology has underperformed Moore's law since 1999, I'm
surprised that Rivest underestimated the time needed to complete the
challenge. I wonder how that happened.

~~~
aasasd
From my completely noob understanding, the implementation of this particular
operation of squaring has managed to outrun the law.

------
justindrake
Ballpark latency numbers per 2048-bit modular multiplication:

CPU—1100ns

FPGA—66ns

ASIC—1ns (expected)

If you're a hardware engineer (or mathematician) interested is building an
ultra-low latency ASIC, please email justin@ethereum.org

Source:
[https://twitter.com/drakefjustin/status/1123143447551053824](https://twitter.com/drakefjustin/status/1123143447551053824)

Context:
[https://www.youtube.com/watch?v=zqL_cMlPjOI](https://www.youtube.com/watch?v=zqL_cMlPjOI)

------
audiometry
"Based on Moore’s law and how long it took to run the squaring operation in
1999, Rivest estimated that computing the answer to the puzzle should take
approximately 35 years."

So how did Rivest create the puzzle back then in the first place, without
taking 35 years to generate it?

~~~
Sahhaese
The asymmetry of three things is essentially what secures of a lot of
cryptography:

    
    
      1. multiplying two large prime numbers together (easy)
      2. Factoring the result without knowledge of those primes (extremely difficult)
      3. Factoring the result with knowledge of one of the primes (easy)
    

Those properties are essentially what make up the foundation of a lot of
public key crypto.

For this puzzle, knowing the factorisation of n allowed a shortcut to quickly
generate the puzzle, but without that factorisation it required squaring
numbers 79,685,186,856,218 times sequentially so parallelism isn't a help.

The actual code to generate the puzzle was in the original puzzle description
at [https://people.csail.mit.edu/rivest/lcs35-puzzle-
description...](https://people.csail.mit.edu/rivest/lcs35-puzzle-
description.txt) .

------
pieter_mj
From a fellow Belgian : congratulations!

It's very inspiring to see a self-taught programmer achieve such an impressive
result.

Any chance of the capsule ceremony being live streamed? Would be cool to
follow.

------
unclesams-uncle
Congrats! +32 represent! Which beer(s) did you drink to celebrate?

~~~
TacticalCoder
Wow quite a few belgian in here! Weirdly enough I'm not that big of a beer
drinker but... Although I didn't celebrate finding the solution in any other
way than doing a silly dance in front of my family I did celebrate the HN
thread reaching 2nd place on the frontpage by drinking a Mort Subite / Lambic
Kriek : )

------
sah2ed
OT: Can anyone be kind enough to link to the specific model of TacticalCoder's
monitor setup as captured in this Wired photo [0]?

Thanks

0: [https://www.wired.com/story/a-programmer-solved-a-20-year-
ol...](https://www.wired.com/story/a-programmer-solved-a-20-year-old-
forgotten-crypto-puzzle/)

------
fbn79
Looks like Massdrop addicted (keyb, mat, sad, maybe the whatch and monitor
too?)

~~~
TacticalCoder
Ah no, I don't use Massdrop.

Keyboard is a Happy Hacking Keyboard Pro JP. Mat was a gift from my brother
and I have no idea where it comes from. Monitor is a LG. Watch is a slightly
fancy swiss mechanical diver's watch ; )

~~~
cultureswitch
Aaah, living the Topre Life I see? Great to see these babies outside of the
mech keyboard subreddit.

------
grego
What would be the off the self hardware (CPU) to use for this problem today?
Still Intel, or AMD, or does ARM architecture do squaring fast? Or something
else entirely, like GPU?

------
HNLurker2
Can someone ELI5?

------
jsv
Congrats!

------
Supranational
Hey All! Cryptophage team here
([https://www.cryptophage.com](https://www.cryptophage.com)). Feel free to ask
any questions about our alternative approach to solving the puzzle that
Bernard just cracked!

~~~
MrXOR
Congratulations!

One questions: Solving this puzzle has any impact on Verifiable Delay
Functions security (specially Chia's VDF[1])?

[1] [https://github.com/Chia-Network/vdf-competition](https://github.com/Chia-
Network/vdf-competition)

Thanks

~~~
Supranational
Hey MrXOR! First off, thanks for posting this link to HN! Second, the VDF used
here leverages RSA groups, while the Chia implementation uses Class groups.
These two VDFs are compared here:
[https://crypto.stanford.edu/~dabo/pubs/papers/VDFsurvey.pdf](https://crypto.stanford.edu/~dabo/pubs/papers/VDFsurvey.pdf).
Both the VDFs are subject to hardware and algorithmic speedups which will not
impact the security of their use as long as these are taken into account. If
you are interested in learning more about VDFs I would recommend looking at
this collaborative project by Ethereum and Filecoin:
[https://vdfresearch.org/](https://vdfresearch.org/).

~~~
MrXOR
Excuse me, Another question:

From [1]:

>> Cryptophage project solved it in 2 months.

What about ASICs (NSA's power and love!)? How long would it take? any
estimation? 2 days? :-)

[1] [https://www.cryptophage.com](https://www.cryptophage.com)

~~~
Supranational
We are currently investigating ASICs, but a rough estimation would be that
they could be at least 10x faster, if not more (e.g. 6 days or less)

