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

[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=rimshot&play=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

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

[Leo Gaspard]

On Wed, May 14, 2014 at 01:15:40PM -0700, Robert J. Hansen wrote:
> >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.
> 
> No.  But since I'm going to be giving a lot of explanation here about how
> you're misusing the Landauer Bound, I'm going to leave how you're misusing
> the Margolus-Levitin Limit as a homework exercise.  :)

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".

(I must say I was more confident about the Margolus-Levitin limit than the
Landauer bound.)

> >Again, assuming testing an AES key is a single bit flip
> 
> It's not.  You have to rekey the cipher.  This multiplies the energy by
> about a large factor.  To make the math easier, let's call it a million.

You may have noticed that, lower in my message, I stated the factor could be
10^5 and it would not matter much. You're calling it a million, why not?

I must admit I thought I overestimated the 10^5 bit flip cost, since I thought
AES-128 was like 7 rounds of something like 5 128-bit changeovers, for approx.
5000 ops in total. But I may have mixed up my recollection of AES with another
algorithm.

Looking up on Wikipedia : Apparently, my evaluation of rounds and changes was
little off, but I think your weighty "rekey" operation might be the optimization
described, that involved a 4kB table -- but it might be more energy-efficient
(or even time-efficient) not to precompute the table if running through lots of
different keys.

> >According to Wikipedia still, the lowest temperature recorded on Earth is
> >10^{-10} K.
> 
> 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?

> So multiply your previous estimate by a factor of ten billion, in order to
> reflect running it at ambient temperature.
> 
> 10^10 * 10^6 = 10^16.  So far your estimate is off by a factor of a thousand
> trillion.
> 
> >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."
> 
> Assuming you could do AES in a single bitflip, it would require liberating
> as heat as a strategic nuclear warhead.  Every additional bitflip adds
> another strategic nuclear warhead.  By the time you're flipping 1000 bits
> for each rekeying, you're basically inflicting World War Three on the earth
> just to brute-force a cipher.

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

So, I stated one could bruteforce at 10^6J (overestimated). You're adding 10^16,
for a total of 10^22J.

A nuclear reactor generates approx. 1000MW [1], ie. 10^9W. This makes 10^22J
every 10^13s. So, 30 nuclear reactors generate enough energy to bruteforce a
key in a year. There are approx. 500 nuclear reactors active on earth (assuming
those under construction in 2012 are now built).

Actually, counting total energy production (13000 Mtoe [3], so
13000.10^6.11.10^6 Wh, ie. 14.10^16 Wh, that is 5.10^20 J per year), that makes
a total of 20 years.

Counting only 5000 bit operations per rekey (see upper for details), this "only"
makes 1 year.

OK, you're right. Sounds like nothing to fear (for the time being, at least --
energy production is steadily increasing).

> I stand by my predictions of ecological catastrophe if anyone ever
> brute-forces a 128-bit cipher.

But I have a few objections of my own about your use of Landauer's principle:
 * 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 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."

I do not know anything about reversible computing. But it seems to me that an

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

[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]

[Robert J. Hansen]

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.


No.  But since I'm going to be giving a lot of explanation here about  
how you're misusing the Landauer Bound, I'm going to leave how you're  
misusing the Margolus-Levitin Limit as a homework exercise.  :)



Again, assuming testing an AES key is a single bit flip


It's not.  You have to rekey the cipher.  This multiplies the energy  
by about a large factor.  To make the math easier, let's call it a  
million.



According to Wikipedia still, the lowest temperature recorded on Earth is
10^{-10} K.


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.


So multiply your previous estimate by a factor of ten billion, in  
order to reflect running it at ambient temperature.


10^10 * 10^6 = 10^16.  So far your estimate is off by a factor of a  
thousand trillion.



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."


Assuming you could do AES in a single bitflip, it would require  
liberating as heat as a strategic nuclear warhead.  Every additional  
bitflip adds another strategic nuclear warhead.  By the time you're  
flipping 1000 bits for each rekeying, you're basically inflicting  
World War Three on the earth just to brute-force a cipher.


I stand by my predictions of ecological catastrophe if anyone ever  
brute-forces a 128-bit cipher.



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

Re: Result of the crowdfounding

[Fizzlifax]

Hi Werner,

thanks a lot for Your freely explications! - This was really interesting
for me...

another question ist the VAT for about  5212,-- €

> The legal entity behind GnuPG is my company g10 code.  This is a
> commercial entity and we have to pay VAT on all donations (19% from the
> amount we received from Goteo; i.e. without the Goteo and Paypal costs).
> The VAT we pay on the material procured for the rewards (about 500 Euro)
> reduces our depth to the tax office (not yet included in the overview).
> Given that the majority of costs at g10 code are currently my salary,
> which is not subject to VAT, the VAT issue is indeed a bit unfortunate.
> There is no easy solution for this; however I am thinking about a
> solution.
You see here for ex. one important reason for a non profit-Organisation
as "juridic subject" of the goals...

another one for any- or -bigger donations - would be exoneration of tax
for the donator... - so we pay actually twice taxes.. ;-(

> I am currently working with a web guy on a new structure for the site.
> I am also about to redo the donation page, move it from g10code.com to
> gnupg.org, and allow for non-Paypal donations.
Next problem we have often seen, when open-Source Projects in reason of
private-ownership turned suddenly in closed source...! whats quite
annoying after it...

Best would be something like a foundation (Stiftung). With the
Participation of several gov-institutions there would also be some
interesting support for employment however the most problem is still the
lazyness and anxious of the peoples to use encryption... or loose the
passphrase or even private key...

There for I would be happy if there would be a possibilty to involve
some identy-card with nfc-able smartphones... - but this is another
subject...

Nevertheless if foundation there would may be more possibiltities to
enlarge the range of security tools...? I think after all NSA-Problems
there could be some interest it for outsides of the friends in the
west-overseas-countries...

Salam Shalom

Ralf



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

Re: Future inclusion of Threefish in Gnupg?

[David Shaw]

On May 14, 2014, at 9:35 AM, Sin Trenton  wrote:

> Hello everyone,
> 
> Just out of curiousity, are there any plans for including Threefish into 
> GnuPG?
> Or does it have to be incorprorated into the OpenPGP standard first and 
> *then* perhaps baked into GnuPG?

Yes.  GnuPG follows the OpenPGP standard, so any new algorithms would need to 
go through that process first.

David


___
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]

[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

Future inclusion of Threefish in Gnupg?

[Sin Trenton]

Hello everyone,

Just out of curiousity, are there any plans for including Threefish into 
GnuPG?
Or does it have to be incorprorated into the OpenPGP standard first and 
*then* perhaps baked into GnuPG?


In simple curiousity and because I have a soft spot for Twofish[1]

Sin Trenton

[1] Soft spots are also known as chinks in your armour, I know, I know...

--
Random notes at https://sintrenton.wordpress.com
Twitter: @SinTrenton
PGP Key: 0xC233169488515CE5

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

Re: GPG's vulnerability to quantum cryptography

[Robert J. Hansen]

I might have to ask Robert how comfortable his new asbestos longjohns are.


Rather, as evidenced by my willingness to try and tackle this one.

To a first approximation, trust is confidence in the future's  
predictability.  My friends who grew up in dictatorships tell me the  
uncertainty was far worse than the oppression -- or, more to the  
point, that pervasive uncertainty is its own unique form of  
oppression.  They didn't know which of their loved ones were reporting  
on them to the state security forces.  They didn't know if the police  
officer they saw on the street was going to obey the dictator's law or  
decide his truncheon and gun gave him the right to enact his own law.   
They didn't... etc., etc.


To defend against this, they smiled and moved forwards.  Some turned  
to religion: "God will provide.  God will keep me safe."  Some turned  
to optimism: "Tomorrow will be better.  I won't get shaken down by the  
authorities tomorrow."  But they all worked to create their own  
confidence in the predictability of the future, and in so doing  
managed to keep their psychological health intact.  That health helped  
them prevail against their situation.


So, my answer to whether "some things are suspect" or "all things are  
suspect" is the true state of affairs is this: does it really matter?   
Regardless of whether "some" or "all" are suspect, a smile and faith  
in tomorrow seem to be much more important.  Don't despair.   
Tomorrow's looking good.  Embrace that, and then you might find the  
answers to other questions come more easily.  :)




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

Re: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases

[Aaron Toponce]

On Wed, May 14, 2014 at 06:26:31PM +0200, Werner Koch wrote:
> > Ah. Interesting. Should I file a proper bug against GnuPG then?
> 
> Please do that.

Done. https://bugs.g10code.com/gnupg/issue1640

Thanks,

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


pgpQCElNaRK6x.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases

[Werner Koch]

On Wed, 14 May 2014 14:51, aaron.topo...@gmail.com said:

> Ah. Interesting. Should I file a proper bug against GnuPG then?

Please do that.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: GPG's vulnerability to quantum cryptography

[Robert J. Hansen]

> 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


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

Re: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases

[Aaron Toponce]

On Tue, May 13, 2014 at 11:30:21PM -0400, David Shaw wrote:
> Looks like a bug.  Note that on each of the keys that didn't work there is a
> direct signature on the key.  This is not very common, and is usually used
> for a designated revoker (i.e. "I permit so-and-so to revoke my key for me").
> I suspect there is a bug printing the fingerprints on a key from a key file
> (rather than from a keyring) for keys with a direct signature.

Ah. Interesting. Should I file a proper bug against GnuPG then?

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


pgp7jybYnMPZM.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "gpg --with-fingerprint $FILE" is not listing the keyfingerprint in some cases

[Aaron Toponce]

On Wed, May 14, 2014 at 11:32:07AM +1000, Fraser Tweedale wrote:
> This behaviour also occurs for me in 2.0.22.  Instead of exporting
> the key, you could use --list-keys, which works for me:

Yeah, I'm not interesting in running it from the keyring, as I am assuming that
the key is not imported, but only the file is available.

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


pgp0mJ31Mhuai.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Result of the crowdfounding

[Werner Koch]

On Tue, 13 May 2014 18:58, fizzli...@posteo.net said:

> What for is this campaign manager? - Is this a part of goteo or of
> gnupg or somebody else?

This is what I had to pay to Sam for his work on the campaign.  My
friends at the FSFE suggested that I should run a campaign as soon as
possible and suggested that I hire Sam to manage it.  Sam was a part
time employee with the FSFE back than and thus had some spare time.  He
did the video, wrote blog entries, and managed the Twitter stuff.

> another question ist the VAT for about  5212,-- €

The legal entity behind GnuPG is my company g10 code.  This is a
commercial entity and we have to pay VAT on all donations (19% from the
amount we received from Goteo; i.e. without the Goteo and Paypal costs).
The VAT we pay on the material procured for the rewards (about 500 Euro)
reduces our depth to the tax office (not yet included in the overview).
Given that the majority of costs at g10 code are currently my salary,
which is not subject to VAT, the VAT issue is indeed a bit unfortunate.
There is no easy solution for this; however I am thinking about a
solution.

> Nevertheless - there are for a for a result of 37270,-- € Costs in an
> amout of 50%!

:-(

I realized too late that the published costs calculation was not correct
from the beginning.  For example the Goteo fee was given only at about
50% of the actual value and VAT was completely missing.  It was my fault
to no ask Sam to have me check the numbers before publishing.  Changing
them later was not possible.

> My question now: Would'nt it be better to put every year some "Index"
> in the top of the gnupg-website with the actual need for the runnig
> year and beg for direkt donations?

That is indeed the plan.  But it takes some more time.  The campaign
helped to raise awareness and allowed me to keep on working on the
project.

I am currently working with a web guy on a new structure for the site.
I am also about to redo the donation page, move it from g10code.com to
gnupg.org, and allow for non-Paypal donations.


Salam-Shalom,

   Werner


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

Re: GPG's vulnerability to quantum cryptography

[Peter Lebbing]

On 14/05/14 09:47, Michael Anders 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.

Brute-forcing a 128 bits key is, as far as we know, impossible without
destroying a large part of the earth in the process.

https://www.gnupg.org/faq/gnupg-faq.html#brute_force

Also, you're really broadening from "some things are suspect" to "all things are
suspect", but let's not delve into that too deep. I might have to ask Robert how
comfortable his new asbestos longjohns are.

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 

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

encryption information in a signature

[Hauke Laging]

Hello,

I would like to suggest a probably easier alternative to my proposal 
"sign encrypted emails":

http://lists.gnupg.org/pipermail/gnupg-users/2014-January/048681.html

The purpose is that the recipient can be sure that the message has left 
the sending system encrypted (and: encrypted for a certain key) – as it 
is easily possible for a MitM to encrypt an unencrypted message without 
being noticed, deluding the recipient about the confidentiality of the 
message.

Nearly the same effect as that by my former suggestion may be reached by 
defining a notation which says: "This message is sent encrypted only. It 
will be encrypted for this key / these keys: ..." There is no reason not 
to trust the sending system about that.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GPG's vulnerability to quantum cryptography

[Michael Anders]

> 
> GPG encrypted data (using RSA) can be collected today and easily decrypted
> after 50-100 years using a quantum computer. See:
> https://en.wikipedia.org/wiki/Shor%27s_algorithm

Well let's see. Usually in a new technology, once you are really going
to apply it in the real world, new problems not thought of before are
going to pop up. (Think of fusion energy from the tokamak, which is
always predicted to be here in 20 years from "now" - since more than 40
years.)

> 
> For this reason, what I do today is share long keys with people I know *in
> person*. We then use regular AES-256 to encrypt/decrypt our messages back
> and forth. Every 6 months we meet in person to renew our keys. (To be more
> secure, we actually create the keys in portions via in-person at different
> places, OTR, SMS, landline phone, mobile phone, and snail mail.)
> 
> AES-256 is not vulnerable to quantum cryptography as RSA is, so we feel
> much safer this way.
> 
There is another quantum algorithm called Grovers Algorithm that would
reduce the effort to crack 256 bit key AES to the effort necessary to
crack 128 bit key AES. 
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.
So if you are worried about the quantum computer, using AES as is
directly won't help you a lot. You'd also need symmetric algorithms with
at least 512 bit keys and at least 256 bit block size to retain the same
security margin as in the pre quantum computer era. Large block and key
size algorithms surely do exist.

50 years from now, I'm going to be 105. So if I 'll be alive then, I'll
be grateful to be able to ask quantum computer equipped Baltimore for
help on recovering my old secrets which might have slipped from my
memory by then ;-)


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