Hey! I'm David, a security engineer at the Blockchain team of Facebook, previously a security consultant for the Cryptography Services of NCC Group. I'm also the author of the Real World Cryptography book. This is my blog about cryptography and security and other related topics that I find interesting.

In an old joke, two noblemen vie to name the bigger number. The first, after ruminating for hours, triumphantly announces "Eighty-three!" The second, mightily impressed, replies "You win."

Consider, for example, the oft-repeated legend of the Grand Vizier in Persia who invented chess. The King, so the legend goes, was delighted with the new game, and invited the Vizier to name his own reward. The Vizier replied that, being a modest man, he desired only one grain of wheat on the first square of a chessboard, two grains on the second, four on the third, and so on, with twice as many grains on each square as on the last. The innumerate King agreed, not realizing that the total number of grains on all 64 squares would be 264-1, or 18.6 quintillion—equivalent to the world’s present wheat production for 150 years.

Rado called this maximum the Nth "Busy Beaver" number. (Ah yes, the early 1960’s were a more innocent age.)

To solve the Halting Problem for super machines, we’d need an even more powerful machine: a ‘super duper machine.’ And to solve the Halting Problem for super duper machines, we’d need a ‘super duper pooper machine.’

If we could run at 280,000,000 meters per second, there’d be no need for a special theory of relativity: it’d be obvious to everyone that the faster we go, the heavier and squatter we get, and the faster time elapses in the rest of the world. If we could live for 70,000,000 years, there’d be no theory of evolution, and certainly no creationism: we could watch speciation and adaptation with our eyes, instead of painstakingly reconstructing events from fossils and DNA. If we could bake bread at 20,000,000 degrees Kelvin, nuclear fusion would be not the esoteric domain of physicists but ordinary household knowledge.

But do people fear big numbers? Certainly they do. I’ve met people who don’t know the difference between a million and a billion, and don’t care. We play a lottery with ‘six ways to win!,’ overlooking the twenty million ways to lose. We yawn at six billion tons of carbon dioxide released into the atmosphere each year, and speak of ‘sustainable development’ in the jaws of exponential growth.

A pretty fresh article on how you could use crypto to replace a lot of complicated schemes you might use on your website like password reset or mail confirmation:

and at the place of the token you would put the output of a MAC. Checking the MAC again after receiving the url would confirm that YOU created that url and it has not been modified. Remember, MAC provides integrity and authentication. The author also provides a way to only render this usable once: use the original hashed password as a nonce.

I've used Cmder for a while on Windows. Which is a pretty terminal that brings a lot of tools and shortcuts from the linux world. I also have Chocolatey as packet manager. And all in all it works pretty great except Cmder is pretty slow.

I've ran into Babun yesterday, that seems to be kind of the same thing, but with zsh, oh-my-zsh and another packet manager: pact. The first thing I did was downloading tmux and learning how to use it. It works pretty well and I think I have found a replacement for Cmder =)

I won't go too much into the details because this is for a later post, but you can use such an attack on several relaxed RSA models (meaning you have partial information, you are not totally in the dark).

I've used it in two examples in the above code:

Stereotyped messages

For example if you know the most significant bits of the message. You can find the rest of the message with this method.

The usual RSA model is this one: you have a ciphertext c a modulus N and a public exponent e. Find m such that m^e = c mod N.

Now, this is the relaxed model we can solve: you have c = (m + x)^e, you know a part of the message, m, but you don't know x.
For example the message is always something like "the password today is: [password]".
Coppersmith says that if you are looking for N^1/e of the message it is then a small root and you should be able to find it pretty quickly.

let our polynomial be f(x) = (m + x)^e - c which has a root we want to find modulo N. Here's how to do it with my implementation:

dd = f.degree()
beta = 1
epsilon = beta / 7
mm = ceil(beta**2 / (dd * epsilon))
tt = floor(dd * mm * ((1/beta) - 1))
XX = ceil(N**((beta**2/dd) - epsilon))
roots = coppersmith_howgrave_univariate(f, N, beta, mm, tt, XX)

You can play with the values until it finds the root. The default values should be a good start. If you want to tweak:

beta is always 1 in this case.

XX is your upper bound on the root. The bigger is the unknown, the bigger XX should be. And the bigger it is... the more time it takes.

Factoring with high bits known

Another case is factoring N knowing high bits of q.

The Factorization problem normally is: give N = pq, find q. In our relaxed model we know an approximation q' of q.

Here's how to do it with my implementation:

let f(x) = x - q' which has a root modulo q.
This is because x - q' = x - ( q + diff ) = x - diff mod q with the difference being diff = | q - q' |.

beta = 0.5
dd = f.degree()
epsilon = beta / 7
mm = ceil(beta**2 / (dd * epsilon))
tt = floor(dd * mm * ((1/beta) - 1))
XX = ceil(N**((beta**2/dd) - epsilon)) + 1000000000000000000000000000000000
roots = coppersmith_howgrave_univariate(f, N, beta, mm, tt, XX)

What is important here if you want to find a solution:

we should have q >= N^beta

as usual XX is the upper bound of the root, so the difference should be: |diff| < XX

The constant values used are chosen to be nothing up my sleeve numbers: the four round constants k are 230 times the square roots of 2, 3, 5 and 10. The first four starting values for h0 through h3 are the same with the MD5 algorithm, and the fifth (for h4) is similar.

In cryptography, nothing up my sleeve numbers are any numbers which, by their construction, are above suspicion of hidden properties. They are used in creating cryptographic functions such as hashes and ciphers. These algorithms often need randomized constants for mixing or initialization purposes. The cryptographer may wish to pick these values in a way that demonstrates the constants were not selected for a nefarious purpose, for example, to create a backdoor to the algorithm. These fears can be allayed by using numbers created in a way that leaves little room for adjustment. An example would be the use of initial digits from the number π as the constants. Using digits of π millions of places into its definition would not be considered as trustworthy because the algorithm designer might have selected that starting point because it created a secret weakness the designer could later exploit.

After some evidences of the Silk Road trial got out, Gwern noticed a PGP key was in here...

This is the ASCII-armored private key of the main DPR public key, the one he signed forum posts with and messaged with people. I was surprised to see it screenshotted like that, and I thought it would be hilarious if I could take the private key and announce that I was actually the real DPR by signing it with his key (since I've occasionally been accused of it).

I'm using cmder on windows, it's pretty and it comes with a lot of unix tools (cat, ls, bash, ssh, more, grep...) and pipes and streams and... I can use vim in the console. Not emacs, vim. I do have emacs on windows but I don't think I can do a emacs -nw to just use it from the console. So let's go back to learn vim, because I hate being slow. And here is a nice way of doing it!

I'm digging into the code source of Sage and I see that a lot of functions are implemented with Shoup's NTL. There is also FLINT used. I was wondering what were the differences. I can see that NTL is in c++ and FLINT is in C. On wikipedia:

It is developed by William Hart of the University of Warwick and David Harvey of Harvard University to address the speed limitations of the Pari and NTL libraries.

Although in the code source of Sage I'm looking at they use FLINT by default and switch to NTL when the modulus is getting too large.

By the way, all of that is possible because Sage uses Cython, which allows it to use C in python. I really should learn that...

EDIT:

This implementation is generally slower than the FLINT implementation in :mod:~sage.rings.polynomial.polynomial_zmod_flint, so we use FLINT by default when the modulus is small enough; but NTL does not require that n be `int`-sized, so we use it as default when n is too large for FLINT.

So the reason behind it seems to be that NTL is better for large numbers.