Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: users

SSH Agent keys >4096 bit?

 

 

First page Previous page 1 2 3 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded


gnupg at oneiroi

May 4, 2012, 1:35 PM

Post #26 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/04/2012 05:13 PM, Robert J. Hansen wrote:
> On 05/04/2012 10:17 AM, Milo wrote:
>> Well, many expect rise of the quantum computing during lives of most
>> of us. This can trash most (if not all) asymmetric algorithms
>> (Shor's algorithm)
>
> No. It can trash *some* asymmetric algorithms. There are a good number
> of asymmetric algorithms whose decision problem exists outside of BQP.
> (McEliece, for instance. For those wondering what BQP is, it's the
> quantum computing analogue to P: it describes those problems you can
> solve in a reasonable time with a quantum computer.)

Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk about
those widely used and considered mainstream. Those are our biggest concern.

> I do not understand how, if you're concerned about quantum computing,
> you can believe "it will all be better if we just use larger keys!",
> rather than "it will be better if we use algorithms that cannot be
> efficiently solved by a quantum computer."

I'm not suggesting that longer key for asymmetric ciphers is a cure for
quantum computing backed cryptanalysis.

I wrote about possible, future way of circumventing need of sucking
nova's energy to successfully attack cipher(text).

>> and reduce strength of symmetric ciphers in half (with for example
>> Grover's algorithm).
>
> Not half, reduce the strength of symmetric ciphers by a square root. A
> 128-bit cipher's strength is not halved (which would make it 127-bit);
> it's reduced to the equivalent of 64 bits (the square root of 128 bits).

Thanks for pointing that but in considered situations this is slight
difference.

>> Beside this consider widespread usage of 256-bit symmetric ciphers.
>> If things you are writing are all the truth behind key length
>> security we are dealing with huge, mass overkill or even scam
>> perhaps. But I think we aren't.
>
> It's worth noting that, per Suite B, 256-bit crypto is only required for
> material that's at the top of the classification pyramid: things like
> nuclear weapon release codes and other things that might cause 300
> million people to have a really bad day.

You can't tell consumer or end-user that he can't use 256-bit, symmetric
cipher for his (even!) porn stash because this is some kind of faux pas
and he is iconoclast because of this. It's up to him. Especially he can
get this for almost same price (We can easily count CPU cycles,
electricity used and so on, but from practical point of view difference
is slight).

> 128-bit crypto is considered quite sufficient for the rest of the
> nation's secrets.

Really? Then what's the reason behind 256-bit hw-supproted crypto (e.g.
AES instructions for amd64 and x86), widely accessible on consumer
market which has nothing to do with nuclear weapons?

> Also, some people are using symmetric crypto for secrets that must be
> preserved for 50+ years -- census data, for instance. If you're
> concerned about 50+ years of confidentiality, then yes, it makes sense
> to go hog-wild on key lengths. But for the rest of us, the
> confidentiality of our communications will be better-served by many
> other measures than just adding more bits to the key.

One more time - this is not up to you or software authors to decide
what's the value behind encrypted data. Even if reason of encrypting it
is silly.

>> Just like modern cellphones' CPU/GPUs are s-f from Apollo mission's
>> engineers' perspective, just like "640K ought to be enough for
>> anybody" and like 32-bit address space for IP protocol is more then
>> enough. History is showing quite clearly that such speculations
>> despite - ofte high - competencies of the authors are missed.
>
> (...)
>
> Introduce quantum algorithms, though, and suddenly quite respectable
> computer scientists suddenly start sweating bullets and saying, "uh, I
> don't quite know about this, umm, *in theory* it will be kind of like
> this, but the practical ramifications are ... hey, look at the time,
> gotta go."
>
> 6000-qubit quantum computers are a magic so subtle they are
> indistinguishable from high technology. They might, if we are
> fortunate, be invented in our lifetimes -- but let's not go about saying
> we need 8K RSA keys to defend against 6000-bit quantum computers. If
> quantum computers bother you that much, use McEliece.
>
>> Please try to avoid comedic undertone of your statements and
>> comparisons if you want to keep discussion's level sane.
>
> The discussion was already profoundly silly: the overt comedic
> statements drew attention to this. Successfully, apparently.
>
> (...)
>
>> Giving users easier-then-hacking-through-sources way of setting
>> bigger key size isn't a crime.
>
> No, but there's no point in it, either. Frankly, I'd rather the GnuPG
> developers spent their time on pursuits that are more reasonable and
> will give a better return on investment.

Well, this could be won-won approach for both "camps" because of the
outcome/effects of devs' work.

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

May 4, 2012, 4:57 PM

Post #27 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/04/2012 04:35 PM, Milo wrote:
> Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk
> about those widely used and considered mainstream. Those are our
> biggest concern.

McEliece is almost as old as RSA. Generations of graduate students have
tackled it in cryptanalysis courses. Almost a thousand academic papers
have been published on it. None have shown any significant weaknesses
in McEliece.

Its inventor, Robert McEliece, received the Claude E. Shannon Award a
few years ago. What the Fields Medal is to mathematics, or the Turing
Prize is to pure computer science, the Shannon Award is to information
theory.

On the one hand, we have a cipher designed by a Shannon recipient which
has had almost a thousand papers published about it without any really
significant results. On the other hand, we have you calling it a niche,
proof-of-concept, poorly-analyzed cipher.

> I'm not suggesting that longer key for asymmetric ciphers is a cure
> for quantum computing backed cryptanalysis.
>
> I wrote about possible, future way of circumventing need of sucking
> nova's energy to successfully attack cipher(text).

The power and time requirements for computation are well-known.
Circumventing either would require

(a) invention of completely adiabatic computing
(b) repeal of the Heisenberg Uncertainty Principle
(c) repeal of the Second Law of Thermodynamics
(d) ridiculously large quantum computers running at
unheard-of efficiencies

Any of the four puts us back into the realm of science fiction. If
you're advocating making keys larger, I'd like to know which of the four
science fiction breakthroughs you expect might happen. And no matter
which of the four you choose, I'll point out that should your chosen
breakthrough come to pass, we will all have much bigger things to worry
about than whether our 20-year-old communications are still safe.

> Thanks for pointing that but in considered situations this is slight
> difference.

Halving the strength of a 128-bit cipher leaves you with 127 effective
bits of security. Rooting the strength of a 128-bit cipher leaves you
with 64 effective bits of security. The former is still well beyond our
ability to brute-force: the latter is well within our ability to brute
force. I don't consider this to be a slight difference.

> You can't tell consumer or end-user that he can't use 256-bit,
> symmetric cipher for his (even!) porn stash because this is some kind
> of faux pas and he is iconoclast because of this.

I cannot force someone to not use a 256-bit cipher, true. I can
certainly point and laugh at people who believe using one makes them
more secure, though.

Nobody has the right to be taken seriously. That's a privilege that
must be earned.

> Really? Then what's the reason behind 256-bit hw-supproted crypto
> (e.g. AES instructions for amd64 and x86), widely accessible on
> consumer market which has nothing to do with nuclear weapons?

Marketing.

The dirty little secret of crypto is that we've had a *great* symmetric
cipher ever since the mid-1970s: 3DES. It's big. It's ungainly. It's
slow. It has all the aesthetics of the Soviet Realism school of art.
It's very hard to code up because there are so many fiddly bits. And
yet, 3DES has been turning the best minds in crypto into burned-out
alcoholic wrecks for the last 35 years.

It has been undergoing constant attack for 35 *years*. Entire new
branches of cryptanalysis have been invented just to try and dent it.
These approaches have all failed miserably.

There are a few niches where 3DES doesn't work very well. If you need a
cipher that can encrypt a 1000baseT connection, you're better off using
something faster. If you need it on a smartcard, you're better off
using something more space-efficient. But for the rest of the problem
space, 3DES has been rocking the house for almost as long as I've been
alive.

So here's the question: why isn't 3DES used in more places?

Marketing. Because people -- both in the private sector and in the Free
Software world -- want to be able to say they support the latest and
greatest and best thing.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


faramir.cl at gmail

May 5, 2012, 1:13 AM

Post #28 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

El 04-05-2012 10:17, Milo escribió:
> Hello Robert, Hello all.
...
>> How many petabytes are sent across the wire each day? Do you
>> really think people will be storing all of today's traffic for
>> twenty years, just so some analyst not even born yet will someday
>> be able to say, "wow, I really want to see what's in this random
>> guy's porn stash!"?
>
> Yeah, then leave your home open because "Wow, who want to check
> every door in the world. So many of them".

The difference is you don't need to store doors before checking them.

Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJPpOEmAAoJEMV4f6PvczxAONUH/jIkisFOFHc/soX+uiqfWbU1
GUOVjo+kFqRmXxAZy4BM1+k50fI2DGekwTgOinTnu4T+EymPUsdIHC7RVTTvwak7
fKqCJ8HWhLeZxBxguiicfeYELBHbcXqODdQDl5UqEC3jLxhhHClFpi5nTigyjv0c
fm1QmwoiHHM/J2G6rKo2dEwB3uTUuysf4jsublONE+x1NKYgW7y7UfpUjLK47Pzf
6OfJSB5gM+3LObnuj4blZTiQcWWMeAe/Wu250S0xme7EWnLrAXK2Qk/ZJEFx03kG
8VIQ2aEbEqTfHCFk8dYuXkbeIboLJ1LR4DtIi6vdUst7s0msIrU129LV/MbD4F8=
=w0rK
-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 1:37 AM

Post #29 of 55 (480 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 01:57 AM, Robert J. Hansen wrote:
> On 05/04/2012 04:35 PM, Milo wrote:
>> Yes - niche, proof-of-concept, poorly analyzed ciphers. Let's talk
>> about those widely used and considered mainstream. Those are our
>> biggest concern.
>
> McEliece is almost as old as RSA. Generations of graduate students have
> tackled it in cryptanalysis courses. Almost a thousand academic papers
> have been published on it. None have shown any significant weaknesses
> in McEliece.
>
> Its inventor, Robert McEliece, received the Claude E. Shannon Award a
> few years ago. What the Fields Medal is to mathematics, or the Turing
> Prize is to pure computer science, the Shannon Award is to information
> theory.
>
> On the one hand, we have a cipher designed by a Shannon recipient which
> has had almost a thousand papers published about it without any really
> significant results. On the other hand, we have you calling it a niche,
> proof-of-concept, poorly-analyzed cipher.

This is futile. I'm reminding you that you are giving one example of
rarely used algo (so _niche_ and _out_of_mainsteam_) to back your
statement "that there is good amount of them".

>> I'm not suggesting that longer key for asymmetric ciphers is a cure
>> for quantum computing backed cryptanalysis.
>>
>> I wrote about possible, future way of circumventing need of sucking
>> nova's energy to successfully attack cipher(text).
>
> (...)
>
> Any of the four puts us back into the realm of science fiction. If
> you're advocating making keys larger, I'd like to know which of the four
> science fiction breakthroughs you expect might happen. And no matter
> which of the four you choose, I'll point out that should your chosen
> breakthrough come to pass, we will all have much bigger things to worry
> about than whether our 20-year-old communications are still safe.

This is possibly really big thing to worry. Especially in countries
where pizza is vegetable... But again - you are doing another try to
revalue data which isn't yours with your "value system".

>> Thanks for pointing that but in considered situations this is slight
>> difference.
>
> Halving the strength of a 128-bit cipher leaves you with 127 effective
> bits of security. Rooting the strength of a 128-bit cipher leaves you
> with 64 effective bits of security. The former is still well beyond our
> ability to brute-force: the latter is well within our ability to brute
> force. I don't consider this to be a slight difference.

"(...) Thus in the presence of large quantum computers an n-bit key can
provide at least n/2 bits of security."

Slight difference. I don't have more comments.

>> You can't tell consumer or end-user that he can't use 256-bit,
>> symmetric cipher for his (even!) porn stash because this is some kind
>> of faux pas and he is iconoclast because of this.
>
> I cannot force someone to not use a 256-bit cipher, true. I can
> certainly point and laugh at people who believe using one makes them
> more secure, though.
>
> Nobody has the right to be taken seriously. That's a privilege that
> must be earned.

In context of this discussion your statement is ridiculous. At one point
you even agreed on using 256-bit symmetric cipher for 50+ years
confidentiality (not guaranteed but at least assumed or expected) and
now you are turning all things around.

You are not able to understand that people can get better security
margin dirt-cheap and some stuff can be worth for them of securing for
long, long years. Calling them "not serious" because of picking 256-bit
symmetric cipher is... Well I don't have more comments here.

>> Really? Then what's the reason behind 256-bit hw-supproted crypto
>> (e.g. AES instructions for amd64 and x86), widely accessible on
>> consumer market which has nothing to do with nuclear weapons?
>
> Marketing.

No. Healthy security margin.

> The dirty little secret of crypto is that we've had a *great* symmetric
> cipher ever since the mid-1970s: 3DES. It's big. It's ungainly. It's
> slow. It has all the aesthetics of the Soviet Realism school of art.
> It's very hard to code up because there are so many fiddly bits. And
> yet, 3DES has been turning the best minds in crypto into burned-out
> alcoholic wrecks for the last 35 years.
>
> It has been undergoing constant attack for 35 *years*. Entire new
> branches of cryptanalysis have been invented just to try and dent it.
> These approaches have all failed miserably.
>
> There are a few niches where 3DES doesn't work very well. If you need a
> cipher that can encrypt a 1000baseT connection, you're better off using
> something faster. If you need it on a smartcard, you're better off
> using something more space-efficient. But for the rest of the problem
> space, 3DES has been rocking the house for almost as long as I've been
> alive.
>
> So here's the question: why isn't 3DES used in more places?
>
>
> Marketing. Because people -- both in the private sector and in the Free
> Software world -- want to be able to say they support the latest and
> greatest and best thing.

3des is old and it's providing something like 80-112 bits of security.
It has ugly history of keying hacks and some aren't back compatible -
which is ugly. Your "porn stash" (in metaphorical sense. possibly) can
be safe today, but not tomorrow. It's not marketing.

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

May 5, 2012, 3:08 AM

Post #30 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 04/05/12 22:35, Milo wrote:
> You can't tell consumer or end-user that he can't use 256-bit, symmetric
> cipher for his (even!) porn stash because this is some kind of faux pas
> and he is iconoclast because of this. It's up to him.

Why should the GnuPG authors include a feature they don't believe in? If
it's in GnuPG official, it will need to be supported. What if there is
some bug that only rears its ugly head with 8k keys? They'll need to
spend more time on it, time better spent elsewhere.

And especially, why should they add something they simply don't believe in.

The use of 8k keys is bothersome to others. In the GnuPG case for
certifications and signatures, and in the SSH case for the owner of the
server you're logging in to and burning unnecesary CPU cycles.

> One more time - this is not up to you or software authors to decide
> what's the value behind encrypted data. Even if reason of encrypting it
> is silly.

I don't think it's up to you to decide that the GnuPG authors need to
officially support something they find silly.

And you seem to forget that when you use GnuPG with (for example) 4k
keys, the 4k key is simply not the weakest link! This has been said already.

It's an interesting take on things, that the GnuPG authors somehow think
your data must be invaluable, because they don't offer 8k RSA. If your
data is that valuable, keep it to yourself. Don't give even the
encrypted variant to your enemy. Because your formidable enemy will know
of a way to decrypt it without breaking your 8k key.

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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 3:19 AM

Post #31 of 55 (474 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 10:13 AM, Faramir wrote:
> El 04-05-2012 10:17, Milo escribió:
>> Hello Robert, Hello all.
> ...
>>> How many petabytes are sent across the wire each day? Do you
>>> really think people will be storing all of today's traffic for
>>> twenty years, just so some analyst not even born yet will someday
>>> be able to say, "wow, I really want to see what's in this random
>>> guy's porn stash!"?
>
>> Yeah, then leave your home open because "Wow, who want to check
>> every door in the world. So many of them".
>
> The difference is you don't need to store doors before checking them.

Do you see any technical problem with this?

http://www.wired.com/threatlevel/2008/01/feds-must-exami/
http://www.wired.com/science/discoveries/news/2006/04/70619
http://defensetech.org/2005/12/24/nsa-tapping-into-telecoms-main-arteries/
https://www.eff.org/issues/nsa-spying

Even if it requires some effort is becoming more possible then ever
(especially with such amount of resources...).

> Best Regards

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 3:49 AM

Post #32 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 12:08 PM, Peter Lebbing wrote:
> On 04/05/12 22:35, Milo wrote:
>> You can't tell consumer or end-user that he can't use 256-bit, symmetric
>> cipher for his (even!) porn stash because this is some kind of faux pas
>> and he is iconoclast because of this. It's up to him.
>
> Why should the GnuPG authors include a feature they don't believe in? If
> it's in GnuPG official, it will need to be supported. What if there is
> some bug that only rears its ugly head with 8k keys? They'll need to
> spend more time on it, time better spent elsewhere.

1) You are responding to citation regarding symmetric crypto with widely
used key length.

2) Proponents of approach you are commenting on gave some arguments here
already. If not sure check thread and other sources.

> And especially, why should they add something they simply don't believe in.
>
> The use of 8k keys is bothersome to others. In the GnuPG case for
> certifications and signatures, and in the SSH case for the owner of the
> server you're logging in to and burning unnecesary CPU cycles.
>
>> One more time - this is not up to you or software authors to decide
>> what's the value behind encrypted data. Even if reason of encrypting it
>> is silly.
>
> I don't think it's up to you to decide that the GnuPG authors need to
> officially support something they find silly.

This is open discussion about free software's value and (expected by
some) functionality. Discussion and judging on value of private data is
something totally different you know.

No offence but I don't think that GnuPG is only to address 100% authors'
needs.

> And you seem to forget that when you use GnuPG with (for example) 4k
> keys, the 4k key is simply not the weakest link! This has been said already.

I'm not forgetting about this. But you are forgetting you are using
symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't have
any problem with this "security overkill" (but yes - symmetric ciphers
are computationally to use cheaper).

For RSA you'll get similar security with ~15k key!

Simply for some 4k isn't enough here. Can you imagine your own, private
data which should be encrypted for more years then 4k asymmetric key is
able to secure? If not you are including into discussion your own needs
(or lack of them) as universal and only truth.

> It's an interesting take on things, that the GnuPG authors somehow think
> your data must be invaluable, because they don't offer 8k RSA.

This is your flawed conclusion.

> If your
> data is that valuable, keep it to yourself. Don't give even the
> encrypted variant to your enemy. Because your formidable enemy will know
> of a way to decrypt it without breaking your 8k key.

Give people in need reasonable way of providing comparable level of
security in physical means (with at least same costs as with
cryptography). You'll become rich, rich man.

> Peter.
>

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

May 5, 2012, 4:09 AM

Post #33 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/12 12:49, Milo wrote:
> 1) You are responding to citation regarding symmetric crypto with
> widely used key length.

Well it's not my fault someone else went off-topic is it? If you are
here to persuade the GnuPG authors to include AES256 you're too late.

I think you can perfectly discern what message I was intending to get
across.

> 2) Proponents of approach you are commenting on gave some arguments
> here already. If not sure check thread and other sources.

I am very well aware of that. They don't convince, because they don't
tackle the problem of the weakest link.

>>> One more time - this is not up to you or software authors to
>>> decide what's the value behind encrypted data. Even if reason of
>>> encrypting it is silly.
>>
>> I don't think it's up to you to decide that the GnuPG authors need
>> to officially support something they find silly.
>
> This is open discussion about free software's value and (expected by
> some) functionality. Discussion and judging on value of private data
> is something totally different you know.

Please read these three quotes again carefully. You are saying you
yourself are off-topic; discussing something totally different. I agree.

> I'm not forgetting about this. But you are forgetting you are using
> symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't
> have any problem with this "security overkill" (but yes - symmetric
> ciphers are computationally to use cheaper).

GnuPG should include 8k RSA because I didn't go through the trouble of
disabling AES256 in my browser, risking breakage when an oddball
webserver administrator disables all algorithms but AES256?

You also indicate yourself where this goes askew: RSA 8k is immensely
more CPU intensive than AES256 v AES128.

>> It's an interesting take on things, that the GnuPG authors somehow
>> think your data must be invaluable, because they don't offer 8k
>> RSA.
>
> This is your flawed conclusion.

I was replying to:
>> One more time - this is not up to you or software authors to decide
>> what's the value behind encrypted data.

I read that as: GnuPG authors decide your data is not valuable enough
for RSA 8k. I'm unsure how else to read it, but it certainly isn't /my/
conclusion, it's what I read as /your/ conclusion. Please don't make it
my conclusion, I would have to severely disagree with myself, and I hate
it when that happens.

A large error I made: I wrote invaluable when I meant not valuable at
all. Is this the source of the confusion?

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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 4:46 AM

Post #34 of 55 (479 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 01:09 PM, Peter Lebbing wrote:
> On 05/05/12 12:49, Milo wrote:
>> 1) You are responding to citation regarding symmetric crypto with
>> widely used key length.
>
> (...)
>
>
>>>> One more time - this is not up to you or software authors to
>>>> decide what's the value behind encrypted data. Even if reason of
>>>> encrypting it is silly.
>>>
>>> I don't think it's up to you to decide that the GnuPG authors need
>>> to officially support something they find silly.
>>
>> This is open discussion about free software's value and (expected by
>> some) functionality. Discussion and judging on value of private data
>> is something totally different you know.
>
> Please read these three quotes again carefully. You are saying you
> yourself are off-topic; discussing something totally different. I agree.

No. Discussion was at some point about reasons of using strong crypto.
And at some point idea that it's not worth to use it against data which
has no value appeared. My point is you are not in the position to say
what's the value of the data someone is encrypting. You weren't reading
carefully enough to see this and you are suggesting me that I'm trying
to force GnuPG authors to do something which is - almost offensive -
rubbish. This is discussion Peter, nothing else.

>> I'm not forgetting about this. But you are forgetting you are using
>> symmetric crypto with 256-bit key length (e.g. HTTPS) and you don't
>> have any problem with this "security overkill" (but yes - symmetric
>> ciphers are computationally to use cheaper).
>
> GnuPG should include 8k RSA because I didn't go through the trouble of
> disabling AES256 in my browser, risking breakage when an oddball
> webserver administrator disables all algorithms but AES256?

In overall I agree with this but "disabling all stuff but AES256" is
silly and overdrawn try to devaluate my statement.

> You also indicate yourself where this goes askew: RSA 8k is immensely
> more CPU intensive than AES256 v AES128.

If you can't afford this "immense" expense - don't use 8k RSA.

>>> It's an interesting take on things, that the GnuPG authors somehow
>>> think your data must be invaluable, because they don't offer 8k
>>> RSA.
>>
>> This is your flawed conclusion.
>
> I was replying to:
>>> One more time - this is not up to you or software authors to decide
>>> what's the value behind encrypted data.
>
> I read that as: GnuPG authors decide your data is not valuable enough
> for RSA 8k. I'm unsure how else to read it, but it certainly isn't /my/
> conclusion, it's what I read as /your/ conclusion. Please don't make it
> my conclusion, I would have to severely disagree with myself, and I hate
> it when that happens.

You are following idea that people who are using strong crypto to things
which are in your opinion worthless aren't serious.

Looks like at best you replied to piece of thread without knowing its
context.

There is a difference between your overdrawn (again) interpretation that
all this data is without value in eyes of GnuPG authors. I'm just saying
that it's not for them do evaluate value of this data. Simple as this.

And yes - by using extremely cheap rhetoric tricks you made this opinion
yours. I'm really sorry because of you but this is not my problem.

> A large error I made: I wrote invaluable when I meant not valuable at
> all. Is this the source of the confusion?

As above.

> Peter.
>

At some point discussion was quite constructive but it's not anymore.

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

May 5, 2012, 5:05 AM

Post #35 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

Milo,

I am sorry if I somehow offended you. That's the feeling I get from your
latest mail. It was not the intention.

I do want to note that no matter how careful you read, English is
multi-interpretable and ambiguous. So when someone interprets a
statement differently than you do, it does not necessarily mean they
must not have read carefully enough.

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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

May 5, 2012, 5:20 AM

Post #36 of 55 (479 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 5/5/12 4:37 AM, Milo wrote:
> This is futile. I'm reminding you that you are giving one example of
> rarely used algo (so _niche_ and _out_of_mainsteam_) to back your
> statement "that there is good amount of them".

"Rarely used" is not the same as "proof of concept." Your statement did
not mention "out of the mainstream." No moving the goalposts, please.

You were also arguing that QC would shred all or most asymmetric
systems. It turns out that no, QC doesn't, can't, won't: it will only
shred the discrete logarithm problem or problems isomorphic to it, such
as integer factorization. Other systems, whether multivariate, lattice
or Goppa code-based systems, won't be. (Well -- lattice systems might:
right now they're only conjectured to be outside of BQP. But Goppa
codes are well-known for being NP-hard.)

If you're now claiming that I've only presented one system, well, that's
because I wasn't aware you were looking for the kitchen sink. Do some
reading on post-quantum cryptography. As I read the tea leaves the new
hotness is in the lattice-based systems, but I think systems based on
Goppa codes will continue to surprise us.

> In context of this discussion your statement is ridiculous. At one point
> you even agreed on using 256-bit symmetric cipher for 50+ years
> confidentiality (not guaranteed but at least assumed or expected) and
> now you are turning all things around.

Not at all.

If you're securing nuclear weapon release codes and you ask me, "is it
okay if I use 256-bit crypto?", I will blink a few times and back away
slowly from the thermonuclear weapon while nodding vigorously and making
noises about how they must be secure for fifty years or more, oh and is
that thing releasing radiation right now and where do you plan on
storing this so I can live far away from it.

If you're securing your recipe book and you ask me, "is it okay if I use
256-bit crypto?", I will smile and pleasantly explain that, really, past
about 112 bits it's just an exercise in paranoia. Use whatever you
like, but managing your keys will be a much more important task than
deciding between 3DES and AES256.

And if you're telling everyone that AES256 will give them a larger
security margin than 3DES, well... at that point I'm going to start
pointing and laughing. There is enough misinformation and half-truths
floating around the crypto-hobbyist's world: I consider it to be a
polite act towards the community to challenge this when I encounter it.

> 3des is old

Old software engineering joke: "legacy code (n): code that hasn't
crashed in the last 40 years."

You call 3DES old. I call it quite well tested in demanding production
environments. More often than not when you swipe a credit card, 3DES is
being used to secure the transaction at various critical points.

> and it's providing something like 80-112 bits of security.

The best attack against three-key 3DES requires almost 10^27 bytes of
RAM. This is completely impractical, as even the inventor of the attack
has said. To the best of our knowledge there is no effective way to
reduce three-key 3DES, which is the only NIST-approved version, below
168 bits of key space.

> It has ugly history of keying hacks and some aren't back compatible -

... I have absolutely no idea what you're talking about here. None.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 5:57 AM

Post #37 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 02:20 PM, Robert J. Hansen wrote:
> On 5/5/12 4:37 AM, Milo wrote:
>> This is futile. I'm reminding you that you are giving one example of
>> rarely used algo (so _niche_ and _out_of_mainsteam_) to back your
>> statement "that there is good amount of them".
>
> "Rarely used" is not the same as "proof of concept." Your statement did
> not mention "out of the mainstream." No moving the goalposts, please.

I mentioned some attributes of ciphers which are generally out of
concern because - e.g. - they aren't widely used. I understand term
"niche cipher" as somehow overlapping and with similar meaning as "out
of mainstream". And I used `,' logical disjunction. Hope my intention is
clear now ;)

> You were also arguing that QC would shred all or most asymmetric
> systems. It turns out that no, QC doesn't, can't, won't: it will only
> shred the discrete logarithm problem or problems isomorphic to it, such
> as integer factorization. Other systems, whether multivariate, lattice
> or Goppa code-based systems, won't be. (Well -- lattice systems might:
> right now they're only conjectured to be outside of BQP. But Goppa
> codes are well-known for being NP-hard.)

after Wikipedia:

"Derivatives of Shor's algorithm are widely conjectured to be effective
against all mainstream public-key algorithms including RSA,
Diffie-Hellman and elliptic curve cryptography". I'm not considering all
of them. I used more general expression.

> If you're now claiming that I've only presented one system, well, that's
> because I wasn't aware you were looking for the kitchen sink. Do some
> reading on post-quantum cryptography. As I read the tea leaves the new
> hotness is in the lattice-based systems, but I think systems based on
> Goppa codes will continue to surprise us.

Thanks for this tip.

>> In context of this discussion your statement is ridiculous. At one point
>> you even agreed on using 256-bit symmetric cipher for 50+ years
>> confidentiality (not guaranteed but at least assumed or expected) and
>> now you are turning all things around.
>
> Not at all.
>
> If you're securing nuclear weapon release codes and you ask me, "is it
> okay if I use 256-bit crypto?", I will blink a few times and back away
> slowly from the thermonuclear weapon while nodding vigorously and making
> noises about how they must be secure for fifty years or more, oh and is
> that thing releasing radiation right now and where do you plan on
> storing this so I can live far away from it.
>
> If you're securing your recipe book and you ask me, "is it okay if I use
> 256-bit crypto?", I will smile and pleasantly explain that, really, past
> about 112 bits it's just an exercise in paranoia. Use whatever you
> like, but managing your keys will be a much more important task than
> deciding between 3DES and AES256.
>
> And if you're telling everyone that AES256 will give them a larger
> security margin than 3DES, well... at that point I'm going to start
> pointing and laughing. There is enough misinformation and half-truths
> floating around the crypto-hobbyist's world: I consider it to be a
> polite act towards the community to challenge this when I encounter it.

And again we are going through field of evaluating data's value. I don't
think I have something more to add here. I understand your point and
possibly person who will ask you such question(s) can follow your advice
without harm.

But I don't think that biggest proponents of longer asymmetric keys are
such kind of guys. Your approach advised to this hypothetical person is
more like tao of using encryption then set of objective rules.

>> 3des is old
>
> Old software engineering joke: "legacy code (n): code that hasn't
> crashed in the last 40 years."
>
> You call 3DES old. I call it quite well tested in demanding production
> environments. More often than not when you swipe a credit card, 3DES is
> being used to secure the transaction at various critical points.

But lacking bigger margin of security because of limited key space. See
NIST advisories for 3des keying methods (see: 50 years+ security
problem; yeah, some people are quite suspicious about them).

>> and it's providing something like 80-112 bits of security.
>
> The best attack against three-key 3DES requires almost 10^27 bytes of
> RAM. This is completely impractical, as even the inventor of the attack
> has said. To the best of our knowledge there is no effective way to
> reduce three-key 3DES, which is the only NIST-approved version, below
> 168 bits of key space.
>
>> It has ugly history of keying hacks and some aren't back compatible -
>
> ... I have absolutely no idea what you're talking about here. None.

Check 3des history for details (
https://en.wikipedia.org/wiki/3des#Keying_options ).

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

May 5, 2012, 6:13 AM

Post #38 of 55 (479 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 5/5/12 8:57 AM, Milo wrote:
> "Derivatives of Shor's algorithm are widely conjectured to be effective
> against all mainstream public-key algorithms including RSA,
> Diffie-Hellman and elliptic curve cryptography". I'm not considering all
> of them. I used more general expression.

In that case, everything you're advocating is confusing me. Yes, if and
when QC comes along many existing systems will need to be considered
suspect. However, if you're concerned about QC you will get far more
mileage from switching to a QC-resistant asymmetric algorithm than from
adding a few bits to your RSA key. Why all this focus on longer RSA
keys as a response to QC? It makes no sense at all.

> But I don't think that biggest proponents of longer asymmetric keys are
> such kind of guys. Your approach advised to this hypothetical person is
> more like tao of using encryption then set of objective rules.

That's because there are very few objective rules. Computer security is
dominated by the human element, and human beings do not tend to strictly
follow objective rules.

When it comes to crypto, yes, we can say certain things with great
mathematical certainty. The instant that crypto gets fielded, though,
the math becomes the least important part of the equation. The human
element becomes overwhelmingly dominant.

> But lacking bigger margin of security because of limited key space.

NIST has certified 3DES until 2030: it is quite likely that in 2030 3DES
will be certified for another couple of decades.

> Check 3des history for details (
> https://en.wikipedia.org/wiki/3des#Keying_options ).

I did, and I don't see anything in there that are ugly hacks or
backwards-incompatible. Choose your keying option (three-key being
preferred), stick with it and you're done.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


hka at qbs

May 5, 2012, 6:49 AM

Post #39 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On Friday 04 of May 2012 21:41:25 Peter Lebbing wrote:
> On 04/05/12 20:54, Ali Lown wrote:
> > Might I point out that discussion is with respect to an 8k RSA SSH key
> > for SSH authentication, not for email. A 2 second delay during the
> > initialization of an SSH connection is not a problem.
>
> And here is precisely something interesting: 8k RSA is discussed as a method
> to keep messages confidential for decades. I haven't looked into it, but
> I'm under the impression RSA is used purely for authentication in SSH, not
> for key exchange[1]. What are you protecting decades against here? A server
> reusing a random challenge? That seems quite far fetched.
>
> Oh, by the way, only the computational load for the client was discussed.
> There's also the server (although the public side of the computation is
> quicker than the private side). The server gets logins from potentially a
> lot of clients.
>
> Peter.
>
> [1] I get this impression because there is a configuration option for
> OpenSSH sshd that selects which key exchange methods to use, and they all
> have DH (Diffie-Helmann) in their name.

As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys:
for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of
8k DH.

Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


hka at qbs

May 5, 2012, 7:13 AM

Post #40 of 55 (482 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On Friday 04 of May 2012 08:40:31 Robert J. Hansen wrote:
> On 05/04/2012 06:07 AM, Hubert Kario wrote:
> > It still doesn't change the overall picture:
> > 1. migrating to ECC is hard and complicated
> > 2. using 8k RSA is easy
>
> Nor does it change
>
> 3. using 8K RSA gives a modest increase to an already formidable
> margin of security
>
> Breaking a 128-bit keyspace is hard. Like, really, really hard. The
> power analysis on that one is eye-popping: to break a 128-bit keyspace
> in anything approaching a reasonable length of time requires an energy
> output on the level of a hypernova. If you want to break a 128-bit
> keyspace, please do it in a galaxy far, far away. So why do we need to
> increase a 128-bit keyspace (RSA-3K) to a 192-bit-plus-a-small-amount
> keyspace (RSA-8K)?
>
> The obvious response is "to defend against enhanced attacks against RSA,
> such as quantum computing and Shor's Algorithm." But that's just crazy.
> Shor's Algorithm requires 2N qubits to break an N-bit key. Right now
> we've got quantum computers that have, what, eight qubits? Any RSA
> modulus smaller than sixteen is in trouble now, let me tell you.

Reading about cryptography history I noticed one thing, when NSA said "don't
do something" it meant that this thing did break the crypto entirely or
allowed for far easier attacks.

Considering that they tell us "don't use RSA" (in Crypto suite B), would
suggest that they have an attack on RSA that considerably limits its security.
So whatever 4k RSA really does have a large margin of security is
questionable.

We've already established that telling everybody to use 8k or greater keys is
infeasible because of computational problems (in phones and web servers, let
alone smartchips). The only solution for that problem is to tell everybody to
use ECC (which has lower computational requirements). This does not mean that
long RSA keys are useless for all use cases. SSH certainly isn't one of them.

Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 7:17 AM

Post #41 of 55 (474 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 03:13 PM, Robert J. Hansen wrote:
> On 5/5/12 8:57 AM, Milo wrote:
>> "Derivatives of Shor's algorithm are widely conjectured to be effective
>> against all mainstream public-key algorithms including RSA,
>> Diffie-Hellman and elliptic curve cryptography". I'm not considering all
>> of them. I used more general expression.
>
> In that case, everything you're advocating is confusing me. Yes, if and
> when QC comes along many existing systems will need to be considered
> suspect. However, if you're concerned about QC you will get far more
> mileage from switching to a QC-resistant asymmetric algorithm than from
> adding a few bits to your RSA key. Why all this focus on longer RSA
> keys as a response to QC? It makes no sense at all.

You are mixing two topics:

Need of security margin better then provided by one of common, widely
used asymmetric algorithms using 4k key

and/with

possible impact of QC on asymmetric ciphers in general.

Second topic was started indirectly by you with "tap on nova's energy
output" and my reply to this part has not much too do with first part.

>> But I don't think that biggest proponents of longer asymmetric keys are
>> such kind of guys. Your approach advised to this hypothetical person is
>> more like tao of using encryption then set of objective rules.
>
> That's because there are very few objective rules. Computer security is
> dominated by the human element, and human beings do not tend to strictly
> follow objective rules.

Hmm. Not sure if I can agree with you here. This is something I must
think about.

> When it comes to crypto, yes, we can say certain things with great
> mathematical certainty. The instant that crypto gets fielded, though,
> the math becomes the least important part of the equation. The human
> element becomes overwhelmingly dominant.
>
>> But lacking bigger margin of security because of limited key space.
>
> NIST has certified 3DES until 2030: it is quite likely that in 2030 3DES
> will be certified for another couple of decades.

Guesswork.

>> Check 3des history for details (
>> https://en.wikipedia.org/wiki/3des#Keying_options ).
>
> I did, and I don't see anything in there that are ugly hacks or
> backwards-incompatible. Choose your keying option (three-key being
> preferred), stick with it and you're done.

"(...) This improves the strength of the algorithm when using keying
option 2, and _provides_ _backward_compatibility_ with DES with keying
option 3."

If you aren't OK with this view - fine. Can't help it. The fact is the
simpler and more transparent cipher is, the easier its security
evaluation is. Simplicity in cryptography is often practical.

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

May 5, 2012, 7:26 AM

Post #42 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 5/5/12 10:17 AM, Milo wrote:
> "(...) This improves the strength of the algorithm when using keying
> option 2, and _provides_ _backward_compatibility_ with DES with keying
> option 3."

One-key 3DES *is* DES. It's a DES encryption, decryption with that same
key, then re-encryption with that same key. One-key 3DES existed to
allow institutions to bootstrap their infrastructure out of DES. First
they instituted one-key 3DES, which let them transparently upgrade their
infrastructure without impacting business operations. Once they were
convinced their new 3DES infrastructure was working correctly, they
switched to using two-key or three-key 3DES. One-key 3DES was never
meant to be used as anything more than an upgrade path. The backwards
compatibility of one-key 3DES was necessary for upgrade purposes, but
once fully deployed 3DES has never had a problem with backwards
compatibility.

What you said earlier was that 3DES had a bunch of keying hacks and
backwards incompatibilities. Neither is true. All the various forms
have been scrutinized quite closely and found to be solid.

One-key 3DES has the benefit of backwards compatibility with DES, which
is useful for upgrade purposes, but it's a gross misstatement of fact to
claim that 3DES has a problem with backwards incompatibility.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 7:42 AM

Post #43 of 55 (480 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 04:26 PM, Robert J. Hansen wrote:
> On 5/5/12 10:17 AM, Milo wrote:
>> "(...) This improves the strength of the algorithm when using keying
>> option 2, and _provides_ _backward_compatibility_ with DES with keying
>> option 3."
>
> One-key 3DES *is* DES.

Obviously it's not. It's for example inappropriate to call single run of
DES 3DES...

> It's a DES encryption, decryption with that same
> key, then re-encryption with that same key. One-key 3DES existed to
> allow institutions to bootstrap their infrastructure out of DES. First
> they instituted one-key 3DES, which let them transparently upgrade their
> infrastructure without impacting business operations. Once they were
> convinced their new 3DES infrastructure was working correctly, they
> switched to using two-key or three-key 3DES. One-key 3DES was never
> meant to be used as anything more than an upgrade path. The backwards
> compatibility of one-key 3DES was necessary for upgrade purposes, but
> once fully deployed 3DES has never had a problem with backwards
> compatibility.

And simply, you've just described ugly hack.

> What you said earlier was that 3DES had a bunch of keying hacks and
> backwards incompatibilities. Neither is true. All the various forms
> have been scrutinized quite closely and found to be solid.

And nothing changed in my stance. What's more 3DES is one big hack to
prolong life of outdated cipher.

If you are making such statements as above, try to not do this while
commenting heavily edited, original message.

> One-key 3DES has the benefit of backwards compatibility with DES, which
> is useful for upgrade purposes, but it's a gross misstatement of fact to
> claim that 3DES has a problem with backwards incompatibility.

I'm not interested (in context of this discussion) in benefits of this mode.

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 7:52 AM

Post #44 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 04:17 PM, Milo wrote:
> (...)
>
> You are mixing two topics:
>
> Need of security margin better then provided by one of common, widely
> used asymmetric algorithms using 4k key

I was rather thinking about 4k RSA key or "security equivalent provided
by one of common, widely used asymmetric algorithms" here, sorry.

> and/with
>
> possible impact of QC on asymmetric ciphers in general.
>
> Second topic was started indirectly by you with "tap on nova's energy
> output" and my reply to this part has not much too do with first part.
>
> (...)

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

May 5, 2012, 11:03 AM

Post #45 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/12 15:49, Hubert Kario wrote:
> As far as I know, OpenSSH uses DH parameters of the same size as the RSA keys:
> for 8k DH you need 8k RSA or (which is unmaintainable) manually force use of
> 8k DH.

Okay, going out on a limb here, since all what I say is conjecture.
Actually consulting the SSH RFC's seems like too much work, or seems too
much like work :).

I think it's rather the case that the size of the DH parameters is
proportional to the keysize of the symmetric algorithm used to secure
the SSH session, because the DH params are used to compute the session
key. So you are right that the DH params are proportional in size to a
key used, but you've confused the keys, asymmetric vs symmetric. That
way it makes sense to me.

If I look at the debug messages emitted by the OpenSSH client, I'm under
the impression that key exchange is already completed before
authentication with RSA starts.

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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


gnupg at oneiroi

May 5, 2012, 11:27 AM

Post #46 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 08:03 PM, Peter Lebbing wrote:
> On 05/05/12 15:49, Hubert Kario wrote:
>> As far as I know, OpenSSH uses DH parameters of the same size as
>> the RSA keys: for 8k DH you need 8k RSA or (which is
>> unmaintainable) manually force use of 8k DH.
>
> Okay, going out on a limb here, since all what I say is
> conjecture. Actually consulting the SSH RFC's seems like too much
> work, or seems too much like work :).
>
> I think it's rather the case that the size of the DH parameters is
> proportional to the keysize of the symmetric algorithm used to
> secure the SSH session, because the DH params are used to compute
> the session key. So you are right that the DH params are
> proportional in size to a key used, but you've confused the keys,
> asymmetric vs symmetric. That way it makes sense to me.
>
> If I look at the debug messages emitted by the OpenSSH client, I'm
> under the impression that key exchange is already completed before
> authentication with RSA starts.

Hm, shouldn't authentication happen before exchanging key for
symmetric part of encryption during the SSH session?

> Peter.
>

--
Regards,
Milo

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


hka at qbs

May 5, 2012, 4:42 PM

Post #47 of 55 (479 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On Saturday 05 of May 2012 20:03:04 Peter Lebbing wrote:
> On 05/05/12 15:49, Hubert Kario wrote:
> > As far as I know, OpenSSH uses DH parameters of the same size as the RSA
> > keys: for 8k DH you need 8k RSA or (which is unmaintainable) manually
> > force use of 8k DH.
>
> Okay, going out on a limb here, since all what I say is conjecture.
> Actually consulting the SSH RFC's seems like too much work, or seems too
> much like work :).
>
> I think it's rather the case that the size of the DH parameters is
> proportional to the keysize of the symmetric algorithm used to secure
> the SSH session, because the DH params are used to compute the session
> key. So you are right that the DH params are proportional in size to a
> key used, but you've confused the keys, asymmetric vs symmetric. That
> way it makes sense to me.

The secret being exchanged is, of course, the random session key. Its size is
related to size of subgroup in DH. But it's the size of prime used that sets
the security level, which just happens to share security evaluation with RSA
as far as number of bits is concerned (IOW: n-bit DH is considered to be as
hard to attack as n-bit RSA).

> If I look at the debug messages emitted by the OpenSSH client, I'm under
> the impression that key exchange is already completed before
> authentication with RSA starts.

DH without authentication is useless (trivial to MITM). You need to
authenticate the DH params you recieve from the other party before you do
anything with them.

Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


faramir.cl at gmail

May 5, 2012, 8:51 PM

Post #48 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

El 05-05-2012 7:46, Milo escribió:
...
>> You also indicate yourself where this goes askew: RSA 8k is
>> immensely more CPU intensive than AES256 v AES128.
>
> If you can't afford this "immense" expense - don't use 8k RSA.

But if you send a signed message, using RSA 8k, then you force your
recipient to use it. GPG choses the symmetric algo and hash algo based
on the recipient's preferences, but it can't chose they asymmetric algo.

Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJPpfVfAAoJEMV4f6PvczxA8PwIAKD1jSUMQhx+nWrOmTMAfwTp
6XKso4YKlr0eQofnYDywBu8sUW2N1HZvl2u2f/1pp8n63Xifua45a6glZPl5nsGF
wouA2OFcQPupDIOZVq6skkp+Dxxr2nvjvvG2HYxSJqtAjWsEezFcUrmFP15/TC4W
G7RNAz8bC39O9VNcPCBA5qBLUX/DF2tBKZ22tm9IEE1OTiYREOJNnq0AQcnkro/T
xIbZwcVQTz7wuG8TTzy5tQZNJnk0tTVSNbEpPJGEP2D7gVXteaprV+nVhcfwOGkr
1w1VlQiQTRFJBIWJyKES6LTLqtqSkIlTEogAsWLX53k7RyhVCie0iI7qg/8SDNg=
=LOro
-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


peter at digitalbrains

May 6, 2012, 1:09 AM

Post #49 of 55 (476 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 06/05/12 01:42, Hubert Kario wrote:
> But it's the size of prime used that sets the security level, which
> just happens to share security evaluation with RSA as far as number
> of bits is concerned (IOW: n-bit DH is considered to be as hard to
> attack as n-bit RSA).

Ah, yes, I misunderstood your point.

But the DH protects the session. Cracking DH will get you the session
contents. RSA is only used to authenticate. If it weren't for the
symmetric encryption of the session, you can probably even get a
(plaintext,ciphertext) pair. I've quickly snooped through the RFC's. RSA
is used by the client to sign the "session identifier", which is
determined by DH.

Determining the (plaintext, ciphertext) pair from RSA gets you nothing
in this case. Which is fortunate, because the server you log into also
has the (plaintext, ciphertext) pair after you authenticate.

Actually factoring the semiprime is obviously something completely
different. But we were talking about keeping confidential messages
confidential for decades. There is nothing confidential about an
authentication challenge. Confidentiality is encryption. Authentication
is a form of signing[1]. With signatures, the plaintext is not confidential.

> DH without authentication is useless (trivial to MITM). You need to
> authenticate the DH params you recieve from the other party before
> you do anything with them.

The /server/ is authenticated during key exchange. The /client/ can also
be authenticated with a plaintext password sent over the encrypted
connection to the server. I don't think the client is authenticated
until after key exchange, whether you use RSA or a password (or another
form of authentication).

Peter.

[1] Signing a challenge, which is still quite different in nature from
signing data.

--
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://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users


rjh at sixdemonbag

May 6, 2012, 1:50 AM

Post #50 of 55 (475 views)
Permalink
Re: SSH Agent keys >4096 bit? [In reply to]

On 05/05/2012 10:42 AM, Milo wrote:
> Obviously it's not. It's for example inappropriate to call single run
> of DES 3DES...

At this point I genuinely can't tell if I'm being trolled. I'm going to
assume that I am not, and this will be my last statement on this entire
thread.

Two functions may operate quite differently, and yet be considered
completely identical from a computational perspective. If I ask you to
add the numbers from 1 to 100, you might solve it the long way by doing
one hundred additions or you might do it the quick way by computing
(101*100)/2 or you might do it the fastest possible way by making a
lucky guess of 5,050.

Doesn't matter. They're all equivalent. If Function A and Function B
accept the same domain, output the same range, and have identical
surjections from domain onto range, then they can be said to be identical.

DES is an example of this. Nowhere in the DES validation tests does it
specify, "your code must look like this." The DES validation tests only
say, "given this input and this key, you must generate this output." If
your implementation passes the DES validation tests, then
congratulations, you can be certified as a FIPS-compliant DES
implementation.

One-key 3DES is quite capable of passing the DES validation tests. This
means that for all intents and purposes it is a DES implementation.

As I said, I don't know if I'm being trolled or if you're just
thoroughly misinformed. If the former, please stop. If the latter, it
can be corrected.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

First page Previous page 1 2 3 Next page Last page  View All GnuPG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.