128 bits of entropy for the Rescue Code?

The Bitcoin et al mining competition is driving advances in P2P 
network processing power, especially with the development of 
standalone WiFi-enabled ASIC miners that sit unattended, 
unnoticed, much like a wireless router.

Need more hash/s?  Simply add more miners; you can put them 
anywhere there's WiFi.

From January to September 2013 the Bitcoin network went from 25 
TH/s to 1000 TH/s, achieving 1 PH/s for the first time.  That's 
a 40x increase in just 9 months.  Then 4 weeks later it hit 2 
PH/s.  Now it's closing in on 25 PH/s.

https://blockchain.info/charts/hash-rate

If the trend holds, it will hit 1 EH/s by the end of the year.

Apparently the dramatic increase in Bitcion's network hash rate 
began about 9 months ago as a result of more powerful ASIC 
miners.

As of now it appears that the Litecoin network hash rate is ~100 
GH/s.

http://block-explorer.com/

Litecoin will likely see its network hash rate begin to increase 
this year as *Scrypt* ASIC miners are said to be on their way.  
Though, if legit, initially I don't think the increase will be 
dramatic.

https://alpha-t.net/

https://www.fibonacci.io/

https://www.flowertechnology.com/

For sure, it is very early days for this technology.  However, I 
have seen this sort of grassroots, entrepreneurial movement 
evolve rapidly, and there seems to be economic pressure behind 
it.

I can envision cyberthieves using the evolving technologies to 
build a P2P network, not to mine cryptocurrency, but to crack 
stolen identity codes, sharing the spoils among those who 
participated.

What if engineers find or already have found a way to short-
circuit Scrypt?

I'm guessing that would seriously impact EnScrypt.

As a preemptive measure we may want 128 bits of entropy for the 
Rescue Code.

The only arguments that I know of against a longer RC is that 
users may be resistive and more likely to make entry errors.

I think writing or entry errors are significantly higher for 
random alphabetic letters, no matter how they're presented or 
grouped, because people see them as gibberish, and writing or 
entering gibberish isn't at all natural.

However, writing or entering random decimal digits is extremely 
easy if they're presented in groups of 2, 3, or 4, because 
people see them as small numbers, not gibberish, and writing or 
entering small numbers is almost as natural as breathing.

So, I think that the vast majority of people throughout the 
world can easily handle longer sequences of small numbers.

Example 1: 10 small numbers in 2 rows, 40 digits.

2943 6230 2423 9958 1433
2571 2635 9318 0247 9555 = 132.877 bits

Example 2: 15 small numbers in 3 rows, 39 digits.

294 36 230 24 239
958 14 332 57 126
359 31 802 47 955 = 129.555 bits

I found example 2 to be easier and more friendly looking.  I 
wrote both examples on paper, verbatim, maintaining the rows and 
columns.  I verified twice.  No errors.  All in less than a 
minute and a half per example.  No sweat.

Using the written copies I entered the examples into my Kindle 
Fire HDX's browser address field.  I set the Android keyboard to 
numbers and symbols.  I verified twice.  No errors.  All in less 
than 2 minutes per example.  No problem.

No doubt it would be easier to enter into an SQRL client that 
has separate numeric input fields for each number, with the 
corresponding rows and columns maintained, and auto tab to the 
next field.  A numeric keypad would be an improvement, too.

-- 
Terry //
0
Terry
2/17/2014 4:10:48 AM
grc.sqrl 459 articles. 0 followers. Follow

3 Replies
256 Views

Similar Articles

[PageSpeed] 17

On 2014-02-16 20:10, Terry L. Webb wrote:
> The Bitcoin et al mining competition is driving advances in P2P
> network processing power, especially with the development of
> standalone WiFi-enabled ASIC miners that sit unattended,
> unnoticed, much like a wireless router.
>
> Need more hash/s?  Simply add more miners; you can put them
> anywhere there's WiFi.
>
>  From January to September 2013 the Bitcoin network went from 25
> TH/s to 1000 TH/s, achieving 1 PH/s for the first time.  That's
> a 40x increase in just 9 months.  Then 4 weeks later it hit 2
> PH/s.  Now it's closing in on 25 PH/s.
>
> https://blockchain.info/charts/hash-rate
>
> If the trend holds, it will hit 1 EH/s by the end of the year.

FWIW, even running at an EH/s, guessing 2^128 combinations would take 
this many years:
10,783,127,828,133

That is 10 Peta years. The universe is supposed to only be 15 giga years 
old.

However, if the SHA1 brute-forcing capabilities of bitcoin continue to 
follow that exponential curve (yikes), it won't be terribly long before 
128-bit SHA will be a laughing matter (note, Bitcoin is running 
SHA-256). For the bitcoin network, at any rate.

I made a joke about bitcoin being a special project of the NSA's once, 
designed to figure out some fundamental flaw or property of SHA. I could 
probably joke now that it is designed to create a supercomputer capable 
of breaking SHA protected resources at some unknown time in the future. ;)

If you look at the blockchain.info chart on a logarithmic scale it is 
very flat, which is a good indication that it is increasing in power 
exponentially (hah, a pun!). There is a deflection in the chart about a 
year ago, probably (?) when ASIC miners were introduced in a serious way.

And increasing something exponentially is a good way to make it very 
powerful, very fast.

Assuming that the bitcoin network doesn't grow to consume all of the 
electricity produced on the planet, or something like that, simply by 
doubling in power every year, in 256 years it would be able to 
brute-force arbitrary SHA-256 values in one second, even if it started 
out only capable of one hash per second.

Of course, the bitcoin network is capable of vastly more hashes per 
second than that, and is doubling at least every month. 256 months is 
only 21 years.

FWIW, I wouldn't worry too much about the bitcoin network increasing 
exponentially for that long. There will be issues with electricity 
consumption. Double electricity use every month for 256 months and you 
probably use more electricity than could be produced by converting the 
mass of the universe into energy or something ridiculous like that.

And computing isn't improving in flops/watt at anything like that rate 
(though it is an exponential improvement as well). Efficiency doubles 
every ~2 years, if I am eyeballing the graph below correctly:

http://en.wikipedia.org/wiki/Performance_per_watt

No doubt ASICs buck that trend somewhat, being single-purpose machines.

If you look here, you get a most energy efficient miner of 1818 Mhashes 
per joule:
https://en.bitcoin.it/wiki/Mining_hardware_comparison

The current bitcoin network, at 28 PH/sec, could be consuming as little 
as 1.5*10^7 Joules if the entire network were that efficient.

This guy here presents a number for "Estimated total mass-energy (in 
Joules) of the observable universe.":
http://physicsoftheuniverse.com/numbers.html

That number is 4 × 10^69 Joules.

2^256 is higher, at 1.15*10^77, though only higher by a factor of 10^8. 
So current bitcoin mining computers at their current efficiency could 
just barely brute-force a single SHA-256 value while consuming all of 
the mass-energy that is estimated to be contained in the observable 
universe (whether it took 1 second or not). Now *that* would be some 
entropy. *g*

http://wolfr.am/1fslw56

Yeah, I've probably rounded wrong somewhere up there, and might be off 
by a few orders of magnitude either way.

Anyways, just some fun with how big those numbers really are. 2^128, 
FWIW, would be significantly easier to brute-force. Might only require 
the mass-energy of the galaxy or solar system or something "reasonable" 
like that. ;)

And you could probably do similar calculations for space required for 
all the computing hardware.

As to SCrypt mining ASICS, they are very likely to be optimized for 
Litecoin's SCrypt parameters. EnScrypt goes *far* beyond the memory 
complexity of Litecoin.

All that said, I fully support the use of 128-bit access codes, or as 
close as we can reasonably achieve. The current narrow pathway in SQRL 
is ED25519, at an estimated equivalent of 140-bits of brute-force 
resistance. We should aim for that neighborhood of brute-force resistance.

Regards,
Sam
0
Sam
2/17/2014 6:51:26 AM
In grc.sqrl, Sam Schinke wrote ...

> On 2014-02-16 20:10, Terry L. Webb wrote:
> > The Bitcoin et al mining competition is driving advances in P2P
> > network processing power, especially with the development of
> > standalone WiFi-enabled ASIC miners that sit unattended,
> > unnoticed, much like a wireless router.
> >
> > Need more hash/s?  Simply add more miners; you can put them
> > anywhere there's WiFi.
> >
> >  From January to September 2013 the Bitcoin network went from 25
> > TH/s to 1000 TH/s, achieving 1 PH/s for the first time.  That's
> > a 40x increase in just 9 months.  Then 4 weeks later it hit 2
> > PH/s.  Now it's closing in on 25 PH/s.
> >
> > https://blockchain.info/charts/hash-rate
> >
> > If the trend holds, it will hit 1 EH/s by the end of the year.

> FWIW, even running at an EH/s, guessing 2^128 combinations would take 
> this many years:
> 10,783,127,828,133
> 
> That is 10 Peta years. The universe is supposed to only be 15 giga years 
> old.

You meant Tera years.

2^128 / (60 * 60 * 24 * 365 * 1000^6) = 10.79 trillion years

2^96 / (60 * 60 * 24 * 365 * 1000^6) = 2,512 years

2^80 / (60 * 60 * 24 * 1000^6) = 13.99 days

> However, if the SHA1 brute-forcing capabilities of bitcoin continue to 
> follow that exponential curve (yikes), it won't be terribly long before 
> 128-bit SHA will be a laughing matter (note, Bitcoin is running 
> SHA-256). For the bitcoin network, at any rate.
> 
> I made a joke about bitcoin being a special project of the NSA's once, 
> designed to figure out some fundamental flaw or property of SHA. I could 
> probably joke now that it is designed to create a supercomputer capable 
> of breaking SHA protected resources at some unknown time in the future. ;)

Yeah, and the future is rapidly approaching.  <g>

> If you look at the blockchain.info chart on a logarithmic scale it is 
> very flat, which is a good indication that it is increasing in power 
> exponentially (hah, a pun!). There is a deflection in the chart about a 
> year ago, probably (?) when ASIC miners were introduced in a serious way.

Yes, last summer a lot of ASICs came online.  Other factors are 
the growing mining pools and the rise of "cloud hashing" 
services where everyone and their Uncle Bob can purchase 
"hashing plans" that go up to 5 TH/s and possibly higher.

Speaking of jokes, maybe soon everyone will commit all computing 
devices to mining and there won't be any bandwidth left for 
other things.  Talk about the ultimate DoS!  <g>

snip

Entertaining stuff, Sam.  :)

I don't think anyone really knows at this point how much power 
is being consumed by the Bitcoin network.  It hasn't been 
measurably cost prohibitive, so far.  Nor has the price of 
electricity risen as a result of increased demand.

> http://www.forbes.com/sites/timworstall/2013/12/03/fascinating-number-bitcoin-mining-uses-15-millions-worth-of-electricity-every-day/

> As to SCrypt mining ASICS, they are very likely to be optimized for 
> Litecoin's SCrypt parameters. EnScrypt goes *far* beyond the memory 
> complexity of Litecoin.

That eases my concern a bit.  But if SQRL goes mainstream it 
will become a target and worth optimizing Scrypt ASIC designs 
for EnScrypt.

-- 
Terry //
0
Terry
2/18/2014 2:54:56 AM
On 2014-02-17 18:54, Terry L. Webb wrote:
> In grc.sqrl, Sam Schinke wrote ...
>
>> On 2014-02-16 20:10, Terry L. Webb wrote:
>>> The Bitcoin et al mining competition is driving advances in P2P
>>> network processing power, especially with the development of
>>> standalone WiFi-enabled ASIC miners that sit unattended,
>>> unnoticed, much like a wireless router.
>>>
>>> Need more hash/s?  Simply add more miners; you can put them
>>> anywhere there's WiFi.
>>>
>>>   From January to September 2013 the Bitcoin network went from 25
>>> TH/s to 1000 TH/s, achieving 1 PH/s for the first time.  That's
>>> a 40x increase in just 9 months.  Then 4 weeks later it hit 2
>>> PH/s.  Now it's closing in on 25 PH/s.
>>>
>>> https://blockchain.info/charts/hash-rate
>>>
>>> If the trend holds, it will hit 1 EH/s by the end of the year.
>
>> FWIW, even running at an EH/s, guessing 2^128 combinations would take
>> this many years:
>> 10,783,127,828,133
>>
>> That is 10 Peta years. The universe is supposed to only be 15 giga years
>> old.
>
> You meant Tera years.

Ah, yes, my bad.

> 2^128 / (60 * 60 * 24 * 365 * 1000^6) = 10.79 trillion years
>
> 2^96 / (60 * 60 * 24 * 365 * 1000^6) = 2,512 years
>
> 2^80 / (60 * 60 * 24 * 1000^6) = 13.99 days

And I don't really think EH/s is the theoretical limit on the bitcoin 
network, either.

[...]
> Entertaining stuff, Sam.  :)

*g* I have some more stuff along those lines. Brute-forcing a SHA-128 
value actually takes far less energy than I had thought.

I was toying with the idea of looking at where moore's law and/or those 
energy-efficiency graphs might end up in the future, too. With 
exponential improvements, calculations based on current computing power 
and efficiency is probably meaningless.

> I don't think anyone really knows at this point how much power
> is being consumed by the Bitcoin network.  It hasn't been
> measurably cost prohibitive, so far.  Nor has the price of
> electricity risen as a result of increased demand.

Right, though if we take as a given that less efficient mining is 
unprofitable, the network should tend towards the more energy-efficient 
mining hardware.

>> http://www.forbes.com/sites/timworstall/2013/12/03/fascinating-number-bitcoin-mining-uses-15-millions-worth-of-electricity-every-day/
>
>> As to SCrypt mining ASICS, they are very likely to be optimized for
>> Litecoin's SCrypt parameters. EnScrypt goes *far* beyond the memory
>> complexity of Litecoin.
>
> That eases my concern a bit.  But if SQRL goes mainstream it
> will become a target and worth optimizing Scrypt ASIC designs
> for EnScrypt.

It would have to become *seriously* dominant to be as profitable a 
target for all that hardware as compared to crypto-currencies. Of 
course, there are some cryptocurrencies that grow their parameters over 
time, and nothing is saying that SQRL's parameters won't become popular 
with some currency or another.

Either way EnScrypt's 16MB memory use is going to be much more expensive 
to pack massive arrays parallel cores with sufficient memory onto a 
single board. Some current ASICs achieve their speed with hundreds or 
thousands of cores (and accompanying memory). Either way, the memory 
will take up a pretty big footprint.

Regards,
Sam
0
Sam
2/18/2014 3:50:40 AM
Reply: