Re: GPG's vulnerability to brute force

2014-05-25 Thread Leo Gaspard
On Sat, May 17, 2014 at 10:51:40AM +0200, Peter Lebbing wrote:
 You can't object to scientific theories on the basis that you did not
 study them properly. It might have a bit of a Socratic feel to it, but
 it quite falls short of the real thing.

Just for the record: I do not feel like I ever objected to a scientific theory
on the basis I did not study it properly. I merely object*ed* to Robert's
interpretation of them, stating that my objections might be invalid due to my
incomplete study of the underlying theories (which turned out to be the case).

Thanks for the discussion,

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-17 Thread Peter Lebbing
On 17/05/14 01:12, Leo Gaspard wrote:
 Well... If the operation the bit just underwent was a bitflip (and, knowing 
 the
 bruteforcing circuit, it's possible to know that), the bit was a '0'.

I admit this is beyond my knowledge, but maybe the following is rather
intuitive and not too incorrect.

Flipping one bit is not enough. You don't make any progress toward a
solution if you only keep flipping the same bit. At the least, you need
to decide to flip which bit. That is also information, information that
is not stored in the resultant bit array where you flipped one bit.

More in general, I agree with Rob that this is not a physics course, and
this is just a thought I had and wanted to share.

You can't object to scientific theories on the basis that you did not
study them properly. It might have a bit of a Socratic feel to it, but
it quite falls short of the real thing.

Physics and computation at this level are pretty unintuitive, I think.
Maybe my little attempt to introduce some intuition about information
content is grossly wrong, and maybe it's a folly to attempt intuition at
all.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at http://digitalbrains.com/2012/openpgp-key-peter

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-17 Thread Peter Lebbing

(This mail originally got dropped by the list managing software because
I had accidentally misused a new webmail plugin. I'm resending it
with all original identifiers so it hopefully threads correctly. I'm
also completely ignoring section 3.6.6 of RFC 2822, but who cares? ;)

---

I suddenly realised something about Rob's Crypto FAQ[1]. You state that 
you need 64 bitflips per attempt, because otherwise your attacker can 
simply adapt his key to the order in which you try them. But to save on 
those 64 bitflips, you could also simply do the whole keyspace in 
order[2]. Your expected number of computations does rise from 2^127 to 
2^128, because obviously everybody will then use the key 2^128-1, which 
is the last one you try ;).


The save of 64 bits to 1 bit loses you 6 bits exponential complexity, 
the increase of the expected number of tries increases it again by 1 
bit, so you have saved 2^5 = 32 = 10^1.5 on the numbers Rob gives. When 
I'm quickly reading through the calculations, it seems we changed it 
from 100 nuclear warheads to only 3, to scan the whole keyspace.


However, this whole thing completely falls apart. We were able to save 
63 bitflips per trial in exchange for a twofold increase in total work. 
In the math done in [1], this changes the feel of the numbers radically, 
because to us, the difference between 3 and 100 is big (it's not when 
discussing exponential complexity). But that is because (at least) one 
very large source of bitflips is not looked at: the number of bitflips 
one trial of a key actually takes. Leo called it 10^5, Rob called it 
10^3. If you save 63 bitflips on a total of a million, that doesn't 
change the final numbers in the least. Pull out some hairs and you still 
have a beard: 10^3 - 63 = 10^3. Incidentally, we went from 100 nuclear 
warheads to 3 to 1000[3].


The thing I'm saying is: the explanation for taking 10^2 as the amount 
of bitflips for a single try doesn't seem convincing. It makes it seem 
that you can actually save computation by linearly searching your 
keyspace.


Peter.

[1] http://sixdemonbag.org/cryptofaq.xhtml#entropy
[2] Actually, make that Gray code order, which actually achieves 1 
bitflip changes per succession, unlike normal binary encoding.
[3] Or 10,000 depending on whether 2^128 is better approximated by 
10^38 or 10^39, when you're really nitpicking. Which you shouldn't do 
when discussing exponential complexity. Let's say that with exponential 
complexity, your fingers are too large to pick a nit.


--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-17 Thread Peter Lebbing

On 2014-05-17 15:28, Robert J. Hansen wrote:
Another way of looking at it: RAM is normally implemented as a 
flipflop.


I think the register bank in a processor is still implemented as 
flipflops, and all computation ends up there (on a register machine)[1], 
so your statement is correct in that respect. A register bank is a RAM.


However, the word normally is not quite apt. What you normally call 
the RAM of your computer is DRAM, and DRAM is implemented by a charge on 
a capacitor. This achieves much higher densities on a chip than SRAM, 
but is also slower.


HTH,

Peter.

[1] Alternatively, in the registers between pipeline stages of the 
processor. If somebody knows about the latest CPU techniques and 
disagrees, by all means, enlighten me :). My knowledge pretty much ends 
at basic pipeline design, and is not up to speed with current CPU 
technology.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-17 Thread Robert J. Hansen
 However, the word normally is not quite apt. What you normally call
 the RAM of your computer is DRAM, and DRAM is implemented by a charge on
 a capacitor. This achieves much higher densities on a chip than SRAM,
 but is also slower.

Point, but I think it's equivalent: whether it's a flipflop getting a
signal or a microcapacitor that's charging/discharging, in both cases
previous state is getting obliterated and the entropic cost accrues.  :)

Thank you for the correction, though!

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-17 Thread Peter Lebbing

On 2014-05-17 19:52, Robert J. Hansen wrote:

Point, but I think it's equivalent: whether it's a flipflop getting a
signal or a microcapacitor that's charging/discharging, in both cases
previous state is getting obliterated and the entropic cost accrues.  
:)


Absolutely, no argument there. In fact, currently, we can't make 
transistors work without capacitance, and a flipflop is built of 
transistors, so the parallels go even further.


Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-16 Thread MFPA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 15 May 2014 at 5:55:08 PM, in
mid:ac4ef92f2c0a44f147cb3fedeb2ea...@butters.digitalbrains.com,
Peter Lebbing wrote:


 Decryption using a wrench rather than a key;
 http://xkcd.com/538/  (don't forget the on-hover text!)

I guess I never hovered over the picture before.

- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

If you save the world too often, it begins to expect it
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlN12Z5XFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5pdIgEAMWYGgmFIEGuLwk9lR3csrbMzsQ4pGkOhhTS
1dMEeQcVzy07GEqcqaVKSgObh8hKC4W6ws1XfGSNMbexEVQALq98ykpSQDWSAQpK
rRry4j8VbKx0PMjxPLMl3MCi+2+Rs6WqbjOQKgBoX+u7k4oEqqjJzazVrO1HYuUO
1Hy/+FZR
=x0hL
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-16 Thread Leo Gaspard
First: I agree with everything skipped in the quotes.

On Wed, May 14, 2014 at 07:31:26PM -0400, Robert J. Hansen wrote:
 On 5/14/2014 6:11 PM, Leo Gaspard wrote:
  BTW: AFAICT, a nuclear warhead (depending on the warhead, ofc.) does 
  not release so much energy, it just releases it in a deadly way.
 
 A one-megaton nuke releases a *petajoule* of energy.  That's a lot.
 When people start using the phrase peta- to describe things, I
 suddenly become very interested in their Health  Safety compliance.
 This is a petawatt laser.  This is a petawatt reactor.  This is a
 petajoule of energy.  This is Peta Wilson.[1]

Well... A nuclear reactor produces 1GW, and thus produces 1PJ in 10^6 s, that is
approx. 11 days 14 hrs. Sure, you may be very interested in Health  Safety
compliance of nuclear reactors, but...

  * You state the energy would be released (or did I misunderstand?). 
  Wikipedia states it is a minimum possible amount of energy required 
  to change one bit of information So no ecological catastrophe (not 
  counting nuclear waste, CO2, etc)
 
 You're beginning to make me a little irate here: the Wikipedia page
 answers this in the second sentence of its first paragraph.  Any
 logically irreversible manipulation of information ... must be
 accompanied by a corresponding entropy increase.
 
 Key phrase: Entropy increase.
 
 Layman's translation: Heat increase.
 
 The Landauer Bound gives not just a minimum amount of energy necessary
 to change a bit of information, but how much heat must be liberated by
 that computation.  And I repeat, this is in the second sentence of the
 first paragraph of the Wikipedia article...

Well... Currently, at a French equivalent of undergrad level (CPGE), we're
learning entropy is a theoretical quantity, that has no real-world meaning --
thus not creating heat. Actually, its unit (J.K^{-1}) does seem to validate this
interpretation: contrarily to e.g. enthalpy, it's not an energy. Perhaps are we
oversimplifying, or perhaps did I completely misunderstand the teachers, but if
this is true there is no heat release. OTOH there would be heat absorption
through the need to move the entropy out of the system -- provided AES is not
reversible (see below for my case against that point).

  information on each flipped bit. Actually, IIUC, flipping a bit is a
   reversible operation, and so the landauer principle does not apply.
 
 Look!  A bit of information:  ___
 
 That's what it was before.  Of course, it's now carrying the value '1'.
 So, tell me: you say bit flips are reversible, so what was the value
 before it was 1?  I promise, I generated these two bits with a fair coin
 (heads = 0, tails = 1).

Well... If the operation the bit just underwent was a bitflip (and, knowing the
bruteforcing circuit, it's possible to know that), the bit was a '0'.

I believe I must have misunderstood your challenge! (Or, just coming to my mind:
maybe was I unclear: when saying bitflip I did not mean setting a bit, but
rather setting its value as 1 - old value.)

 Reversible means we can recover previous state without guessing.
 Current computing systems are not reversible.

I do not state that physically our processors are reversible. I do not even
state any processors might ever be, or adiabatic computers might ever exist.

I just state the theoretical application going from the set of 128-bit keys to
the set of 128-bit cleartexts (with the 128-bit ciphertext fixed) is a bijection
(or so I hope -- unless many keys produce the same ciphertext from the same
cleartext, which would be an attack on AES and ease bruteforce naturally).

As a consequence, I cannot see where a bit of information was lost, and thus
where Landauer's bound is supposed to apply. But maybe am I the one lost here!

Thanks for your previous and hopefully future answers,

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-16 Thread Robert J. Hansen
This is the last I will be saying on the subject.  I am not interested
in teaching a course on thermodynamics.

 Well... A nuclear reactor produces 1GW, and thus produces 1PJ in
 10^6 s, that is approx. 11 days 14 hrs. Sure, you may be very
 interested in Health  Safety compliance of nuclear reactors, but...

But what?  This in the same ballpark as you'd get from releasing a
half-kilogram of antimatter on the world.  It's big.  There are no
but...s about it.

 Well... Currently, at a French equivalent of undergrad level (CPGE), 
 we're learning entropy is a theoretical quantity, that has no 
 real-world meaning

There are two equivalent ways to define entropy, one using
thermodynamics and one using statistical mechanics.  When using the
statistical mechanics definition it's easy to forget you're talking
about the real world instead of just juggling around a lot of numbers
and probabilities.  When using the thermodynamic definition you get your
fingers burned and that reminds you you're talking about
*thermodynamics* -- how heat moves around in a system.

 Well... If the operation the bit just underwent was a bitflip (and, 
 knowing the bruteforcing circuit, it's possible to know that), the 
 bit was a '0'.

It was actually a 1.  The two bits were 1 and 1.  Knowing the second
value was a 1 is of no help whatsoever in recovering the previous state.
The previous state could have been anything.  The bit has no memory of
what it was before: that information is lost to the universe, and there
is a corresponding increase in entropy (heat) associated with it.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-15 Thread Mark H. Wood
On Wed, May 14, 2014 at 07:31:26PM -0400, Robert J. Hansen wrote:
 On 5/14/2014 6:11 PM, Leo Gaspard wrote:
[snip]
  * You state it is a lower bound on the energy consumed/generated by 
  bruteforcing. Having a closer look at the Wikipedia page, I just 
  found this sentence: If no information is erased, computation may
  in principle be achieved which is thermodynamically reversible, and 
  require no release of heat.
 
 Yeah, adiabatic computing.  Give me a call as soon as we have an
 adiabatic computer: I'll be deeply fascinated.  Right now that's even
 more theoretical than quantum computing -- we've actually observed
 quantum computation in the lab on a small scale, while adiabatic
 computing is so far a complete no-go, AFAIK.
 
 (Then again, it's been a few years since I've dived into the literature
 on it -- if you can find a paper demonstrating real-world adiabatic,
 energy- and entropy-free computing, I will be deeply fascinated.  I
 wasn't kidding about that.)
 
  information on each flipped bit. Actually, IIUC, flipping a bit is a
   reversible operation, and so the landauer principle does not apply.
 
 Look!  A bit of information:  ___
 
 That's what it was before.  Of course, it's now carrying the value '1'.
 So, tell me: you say bit flips are reversible, so what was the value
 before it was 1?  I promise, I generated these two bits with a fair coin
 (heads = 0, tails = 1).
 
 Reversible means we can recover previous state without guessing.
 Current computing systems are not reversible.

I notice that the Wikipedia article refers here to thermodynamically
reversible which is perhaps not the same thing as computationally
reversible.  So I looked up thermodynamically reversible and found

  
http://www.brighthubengineering.com/thermodynamics/4616-what-are-reversible-and-irreversible-processes/

which gives the interesting summary: thermodynamically reversible
processes are theoretical and don't occur in the real world.  These
seem to live in the same realm with 100% frictionless surfaces and
insulation with infinite R-factor.

That article seems confused as to whether a reversible process must be
infinitely slow or infinitely fast, but Wikipedia says the former:

  http://en.wikipedia.org/wiki/Reversible_process_%28thermodynamics%29

But I'm way, way out of my depth here so I'll shut up.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-15 Thread Robert J. Hansen
On 5/15/2014 8:30 AM, gnupg-users@gnupg.org wrote:
 The save of 64 bits to 1 bit loses you 6 bits exponential complexity,
 the increase of the expected number of tries increases it again by 1
 bit, so you have saved 2^5 = 32 = 10^1.5 on the numbers Rob gives. When
 I'm quickly reading through the calculations, it seems we changed it
 from 100 nuclear warheads to only 3, to scan the whole keyspace.

Huh: neat!  It doesn't surprise me that there are interesting ways to
tweak the numbers: my calculation is something that would have to assume
vast pretensions of standing just to be considered worthy to go on the
back of a bar napkin.  :)

 The thing I'm saying is: the explanation for taking 10^2 as the amount
 of bitflips for a single try doesn't seem convincing. It makes it seem
 that you can actually save computation by linearly searching your keyspace.

Point.  If/when I make a revision of it I'll review it.  :)



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-15 Thread Peter Lebbing

On 2014-05-15 14:30, gnupg-users@gnupg.org wrote:

Leo called it 10^5, Rob called it 10^3. If you save 63 bitflips on a
total of a million, that doesn't change the final numbers in the 
least.

Pull out some hairs and you still have a beard: 10^3 - 63 = 10^3.
Incidentally, we went from 100 nuclear warheads to 3 to 1000[3].


Whoops, I mixed up one million and one thousand. Always makes me
realise I don't do physics calculations often enough, and feel a bit
ashamed :). Let me slightly redo that:

Leo called it 10^5, Rob called it 10^6. Let's take the more
conservative one for argument's sake. If you save 63 bitflips on a 
total

of one hundred thousand, that doesn't change the final numbers in the
least. Pull out some hairs and you still have a beard: 10^5 - 63 = 
10^5.

Incidentally, we went from 100 nuclear warheads to 3 to 100,000[3].

Peter.

[3] Or a million depending on whether 2^128 is better approximated by
10^38 or 10^39, when you're really nitpicking. Which you shouldn't do
when discussing exponential complexity. Let's say that with
exponential complexity, your fingers are too large to pick a nit.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-15 Thread Robert J. Hansen

I notice that the Wikipedia article refers here to thermodynamically
reversible which is perhaps not the same thing as computationally
reversible.  So I looked up thermodynamically reversible and found


At the level we're talking about, the distinction between  
thermodynamics and computational theory gets a little hazy.  Seriously  
-- we're talking about the deepest magics of math and physics, where  
in order to get peak efficiency from our CPUs we have to exploit the  
Bekenstein limits of the event horizons of black holes.  So, perhaps  
not the same thing is absolutely true.  Perhaps a lot more similar  
than we think.  At this level of theory, things get pretty wacky.


I studied quantum computation and quantum information theory some in  
grad school.  My takeaway from it was that by the standards of the  
field I am basically a dog who's learned to shake hands, sitting at a  
table listening to Deutsch and Witten and Susskind argue and thinking  
that I'm really smart just because I can recognize one word every few  
minutes.  Every now and again they look over my way, realize I'm  
paying attention, say good boy! and scratch my ears and I bark and  
think I'm making a real contribution to the discussion.


Yes, I am *that far* out of my depth here -- Scott Aronson I ain't.   
Please be careful about thinking I'm any kind of an authority here.



which gives the interesting summary: thermodynamically reversible
processes are theoretical and don't occur in the real world.


Yep.  Second Law again: entropy must always increase, meaning nothing  
is truly thermodynamically reversible.  But if adiabatic computing  
*did* exist, man, it would be cool -- as I said, if someone's able to  
demonstrate it I'll be deeply fascinated.  (And then I'll try to see  
if I can leverage it to travel back in time.  Because hey, once the  
Second Law no longer limits you, the world's your oyster.)



That article seems confused as to whether a reversible process must be
infinitely slow or infinitely fast, but Wikipedia says the former:

  http://en.wikipedia.org/wiki/Reversible_process_%28thermodynamics%29


The closer you approach energy-free computing, the slower the process  
goes -- this is a consequence of several different things, including  
the Margolus-Levitin theorem, which says that a bit can't be flipped  
faster than h/4E seconds.  The less energy you put in, the slower the  
flip goes.




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-15 Thread Robert J. Hansen

Incidentally, we went from 100 nuclear warheads to 3 to 100,000[3].


So, I can put you down as solidly in the eco-catastrophe camp, then?  :)




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force

2014-05-15 Thread Peter Lebbing

On 2014-05-15 18:25, Robert J. Hansen wrote:
So, I can put you down as solidly in the eco-catastrophe camp, then?  
:)


Oh, definitely. Unless our understanding of computing at the physical 
limits drastically changes, I think blunt-force cryptanalysis is way 
better than brute-force.


Decryption using a wrench rather than a key; http://xkcd.com/538/ 
(don't forget the on-hover text!)


Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 
http://digitalbrains.com/2012/openpgp-key-peter


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-14 Thread Leo Gaspard
On Wed, May 14, 2014 at 12:21:36PM -0400, Robert J. Hansen wrote:
  Since the well known agency from Baltimore uses its influence to have
  crypto standards coast close to the limit of the brute-forceable, 128
  bit AES will be insecure not too far in the future.
 
 No.
 
 https://www.gnupg.org/faq/gnupg-faq.html#brute_force

I unfortunately have to object to this FAQ article. (Please note I'm not using
any information beyond what Wikipedia provides -- and I may be wrong in my
undertanding of it.)

First, the Margolus-Levitin limit: 6.10^33 ops.J^{-1}.s^{-1} maximum
So, dividing the 2^128 by 6.10^33 gives me a bit less than 57000 J.s (assuming
testing an AES key is a single operation). So, that's less than 1min for 1kJ.
Pretty affordable, I believe.

Then, Landauer's principle: energy k T ln 2.
Again, assuming testing an AES key is a single bit flip, as k is approx.
10^{-23}, this gives an overall energy (per kelvin) of
2^128 . 10^{-23} . ln 2 J.K^{-1}, which is approx. equal to 10^16 J.K^{-1}
(overestimated, as k was underestimated).
According to Wikipedia still, the lowest temperature recorded on Earth is
10^{-10} K.
This makes for a total of 10^6 J, if the computation is done at that
temperature.
According to http://hypertextbook.com/facts/2009/VickieWu.shtml ; the human body
uses approx. 6MJ (ie. 6 . 10^6 J) per day.
As a consequence, the process would consume less than a day of a human body.

Granted, this is still far from possible : Here I assumed testing an AES key was
a single bit flip, and that the computation was entirely done at the coldest
temperature ever recorded in a laboratory. Anyway, the former is a not-so-huge
constant (ie. less than 10^5, I'm almost sure of that), and multiplying the
results by this constant still yields an imaginably possible lower bound. And
the latter already has been recorded, despite my believing no computation has
been done at that temperature, it is still possible in a foreseeable future.

So, despite bruteforcing being obviously impossible in this day and age, and
most likely impossible in the near future, it seems to me that the following
statement is exaggerated: The results are profoundly silly: it’s enough to boil
the oceans and leave the planet as a charred, smoking ruin.

The impossibility of bruteforce, to me, lies with current physical computation
capabilities, more than with theoretical lower bounds, that are far below
current prowesses.

Hoping I didn't miscompute,

Leo

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-14 Thread Robert J. Hansen
10^10 * 10^6 = 10^16.  So far your estimate is off by a factor of a  
thousand trillion.


*Ten* thousand trillion.  Sorry, that one's entirely my error.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GPG's vulnerability to brute force [WAS: Re: GPG's vulnerability to quantum cryptography]

2014-05-14 Thread Robert J. Hansen
On 5/14/2014 6:11 PM, Leo Gaspard wrote:
 Well... Apart from the assumption I stated just below (ie. single
 bit flip for AES), I cannot begin to think about an error I might
 have done with this one, apart from misunderstanding Wikipedia's
 statement that The processing rate cannot be higher than 6.10^33
 operations per second per joule of energy.

That's why it's a homework problem.

 If you want to run the temperature lower than the ambient 
 temperature of the cosmos (3.2K), you have to add energy to run
 the heat pump -- and the amount of energy required to run that
 heat pump will bring your energy usage *above* that which you
 would've had if you'd just run it in deep space at 3.2K.
 
 Sorry for my ignorance, but... if you have enough time to explain
 me, how do you derive this?

$dS = \frac{\delta Q}{T}$

The Second Law of Thermodynamics says there ain't no such thing as a
free lunch.  You want to lower the heat (entropy) in one place, you have
to (a) move that entropy elsewhere and (b) pay an entropic price on top
of it.  If you're moving a million units of entropy from A to B, you're
going to be be paying at least a million and one units of energy.
That's a gross simplification, but close enough for government work.

You want to lower the temperature (heat, entropy, whatever) to 10^-10 K?
 Okay, fine: pay the price.  But you will *always* be paying more than
if you were to just run the machine at 3.2K, and that's a consequence of
$dS = \frac{\delta Q}{T}$.

To put it in terms that we all can understand -- your air conditioner
runs on electricity.  Moving heat from inside your house to outside
requires energy be added to the overall system.  The hotter the day, the
more energy your air conditioner needs to move the heat around.

 BTW: AFAICT, a nuclear warhead (depending on the warhead, ofc.) does 
 not release so much energy, it just releases it in a deadly way.

A one-megaton nuke releases a *petajoule* of energy.  That's a lot.
When people start using the phrase peta- to describe things, I
suddenly become very interested in their Health  Safety compliance.
This is a petawatt laser.  This is a petawatt reactor.  This is a
petajoule of energy.  This is Peta Wilson.[1]

(I trust that Ms. Wilson will forgive my asking, uh, do we have someone
certified for operating her, and where's the nearest Health  Safety
card? without getting too, well, petulant.[2] )

[1] http://en.wikipedia.org/wiki/Peta_Wilson
[2] http://instantrimshot.com/index.php?sound=rimshotplay=true

 * You state the energy would be released (or did I misunderstand?). 
 Wikipedia states it is a minimum possible amount of energy required 
 to change one bit of information So no ecological catastrophe (not 
 counting nuclear waste, CO2, etc)

You're beginning to make me a little irate here: the Wikipedia page
answers this in the second sentence of its first paragraph.  Any
logically irreversible manipulation of information ... must be
accompanied by a corresponding entropy increase.

Key phrase: Entropy increase.

Layman's translation: Heat increase.

The Landauer Bound gives not just a minimum amount of energy necessary
to change a bit of information, but how much heat must be liberated by
that computation.  And I repeat, this is in the second sentence of the
first paragraph of the Wikipedia article...

 * You state it is a lower bound on the energy consumed/generated by 
 bruteforcing. Having a closer look at the Wikipedia page, I just 
 found this sentence: If no information is erased, computation may
 in principle be achieved which is thermodynamically reversible, and 
 require no release of heat.

Yeah, adiabatic computing.  Give me a call as soon as we have an
adiabatic computer: I'll be deeply fascinated.  Right now that's even
more theoretical than quantum computing -- we've actually observed
quantum computation in the lab on a small scale, while adiabatic
computing is so far a complete no-go, AFAIK.

(Then again, it's been a few years since I've dived into the literature
on it -- if you can find a paper demonstrating real-world adiabatic,
energy- and entropy-free computing, I will be deeply fascinated.  I
wasn't kidding about that.)

 information on each flipped bit. Actually, IIUC, flipping a bit is a
  reversible operation, and so the landauer principle does not apply.

Look!  A bit of information:  ___

That's what it was before.  Of course, it's now carrying the value '1'.
So, tell me: you say bit flips are reversible, so what was the value
before it was 1?  I promise, I generated these two bits with a fair coin
(heads = 0, tails = 1).

Reversible means we can recover previous state without guessing.
Current computing systems are not reversible.

 So it might be that Landauer's principle just does not apply to 
 AES-128

No.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users