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


ali at lown

May 3, 2012, 10:14 AM

Post #1 of 55 (3727 views)
Permalink
SSH Agent keys >4096 bit?

I am trying to use gpg-agent for my ssh keys as well as my gpg keys,
but am unable to add my 8192 bit ssh key to the agent.

Agent log reports: "2012-05-03 17:48:02 gpg-agent[2190] ssh keys
greater than 4096 bits are not supported"

The limit appears to be arbitarily set in agent/command-ssh.c
following a max mpi_data_size.

Does anyone know why the limit is set at 4096 bits, and whether there
are any plans for supporting SSH keys of lengths greater than 4096bit
in the gpg-agent?

Thanks.
Ali

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


rjh at sixdemonbag

May 3, 2012, 12:09 PM

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

On 05/03/2012 01:14 PM, Ali Lown wrote:
> Does anyone know why the limit is set at 4096 bits

The consensus of the cryptographic community is that beyond 3K keys you
really need to be switching to elliptical-curve cryptography. A 3K RSA
or Elgamal key is roughly as difficult to break by brute-force as
AES128, and that one's so hard that nobody with two brain cells to rub
together is going to try it.

Although I am not a GnuPG developer, I have never heard anything from
the core devs which would make me think they are planning on revisiting
this limit to allow for extraordinarily large keys.

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


kf at sumptuouscapital

May 3, 2012, 12:24 PM

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

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

On 03.05.2012 21:09, Robert J. Hansen wrote:
> On 05/03/2012 01:14 PM, Ali Lown wrote:
>> Does anyone know why the limit is set at 4096 bits
>
> The consensus of the cryptographic community is that beyond 3K keys
> you really need to be switching to elliptical-curve cryptography.
> A 3K RSA or Elgamal key is roughly as difficult to break by
> brute-force as AES128, and that one's so hard that nobody with two
> brain cells to rub together is going to try it.
>
> Although I am not a GnuPG developer, I have never heard anything
> from the core devs which would make me think they are planning on
> revisiting this limit to allow for extraordinarily large keys.

Although GnuPG won't allow generation for larger keys than 4096 bits
without some hacking it will actually import and use such keys without
any modifications being needed (could try to import e.g. [1] from
[2]). So in that sense there seems to be some difference to the
reported behavior to ssh-agent.

Now, whether such a large key is really useful, that is indeed another
question.

[1] https://www.kfwebs.net/pgp/pubkey-large.txt
[2] http://www.kfwebs.net/news/603/15360-bit-OpenPGP-key

- --
- ----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Corruptissima re publica plurimę leges
The greater the degeneration of the republic, the more of its laws
- ----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is now
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
- ----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPotthAAoJEBbgz41rC5UIdSkQAIZ7h8aRF+pYjeOC1coPcnnP
6ZzU8gbYHlxD8V5nqgv09eQZ8R7iqSz2nXCW3uT4SYrNFs4dLQWqC64IGW419mfv
3RD66lEZx0iKukzmzSWeLhjGBECyhbQfSoKG8i78OXZPP8eUFziddheQMQix7yyK
wRcMNl1Rk0FoytlL7/DJOIzVrGJkwMeeZ+kgYunNlk+KokavW66eH0F837y3TmNi
M08JAgSXbogoDTP4y8opmnRjES8WdkvZHaOUkYN3YSPpMet7hCX8uyfGyJXDV+gi
l79f0ltLiEFj7IYYSXVKsJ2c28tEkDBMcz/meYoy4W0kEReuAKM5Kn+OJoSrMTHI
8pfNeBMiYmvpJjHptvxtQNT8G/OEsXQfzsJl34FrWxrHFqHH8v445L+yryDRJzNd
Xy/AWPqpz51RuLYpcLnYmBKt4630hdmnCJf5DSPh4mrnpDFry/ekL5nFXjKPTEq8
AdsyK9JVGKtxerS+OEGeHc6zKIcM6edZNiByyDMwwf8SsJeoq92N/4fO839FapZj
nmlow5lqGPMotrO2im4HzgWDXnRzmUbJJfsDsCRZYzIewT1Y9F313RQdP4taMQhB
lr1aDM5xrft4mnkKRMwHvNVBpWFdP04P1DaOdV5FTj1kJpDqmzD6U+bvKf6Sh/W4
e21RSyf988sHPzn93GGg
=FS9I
-----END PGP SIGNATURE-----


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


mika.henrik.mainio at hotmail

May 3, 2012, 12:28 PM

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

03.05.2012 20:14, Ali Lown kirjoitti:
> I am trying to use gpg-agent for my ssh keys as well as my gpg
> keys, but am unable to add my 8192 bit ssh key to the agent.
>
> Agent log reports: "2012-05-03 17:48:02 gpg-agent[2190] ssh keys
> greater than 4096 bits are not supported"
>
> The limit appears to be arbitarily set in agent/command-ssh.c
> following a max mpi_data_size.
>
> Does anyone know why the limit is set at 4096 bits, and whether
> there are any plans for supporting SSH keys of lengths greater than
> 4096bit in the gpg-agent?
>
> Thanks. Ali
>
> _______________________________________________ Gnupg-users mailing
> list Gnupg-users [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Use SSH agent instead of GPG agent for ssh keys.
See the manual page "ssh-add" (and "ssh-agent"). The ssh-agent should
usually start when you login.

- --
Mika Suomalainen
gpg --keyserver pool.sks-keyservers.net --recv-keys 4DB53CFE82A46728
Key fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728

Please don't toppost, if possible
https://wiki.debian.org/FAQsFromDebianUser#What_is_top-posting_.28and_why_shouldn.27t_I_do_it.29.3F

Please don't send HTML, if possible. It's possible with most of
clients, even with webmails, see:
https://wiki.debian.org/DebianMailingLists#HowTo_send_plain_text_emails_to_the_list

I use GPG/INLINE, because some mailing list programs modify the headers
of messages and this way make signature.asc files (PGP/MIME)
unverifiable. Please remove lines about beginning and ending GPG
signature blocks in your replies to messages, which are sent by me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPotxGAAoJEE21PP6CpGcoxjkP/2beQQAl2duihGDiF767lIqK
tox9RdRrh7Afh0Q03VmHaTHzDb4XegzIc//3SY9bGcOLtXaeefqJ2AHxGyj1fsGq
+r84qW0ClAKvlqQF3OY/PMfmTBllUFR4T27C1xmWvU6khTlK+cC+aapSIlSdp8XI
Vtbw+naJ/kUO0BXxDJdK8RwmoXR8qeBRGjB+HLx3G+f2xmKIYCjrzMs4TopEecBz
n+Vt9DA3aqnhoXZzE49zhKOrBiLM/GLTPtWbXccVicIZxVB72/GASw1mLntJZ62Z
g1D+L64C75cI4NgZivUKjLdw7KEZZryrjffJTx4Z9vEfV82+ohkJxUZmDSP+9wBB
XxOUY7v4wy36/rU59U62mGBFFRd8bw1X8PoZNBY4K4BfGXtU4XZIlbhNlLzyYiYd
1pgJObu6mQpubwj5E4s2jOlpSNw9QaxQxFJYq6YiNGD5AdCpB+cC7aUldf3wX4yG
/PEsv9YVZ/lH3JmgRhaevFTV21XZAZMnVnTT8yWqNodLIS9llSg2mKFJs20mfTrK
bvnrjZFUO4JiFppIHN7YShDN7Tj0p5Ha8J8y4s3w1DzSCmVHP3AU4ynakGtnhqiz
GLjouApDe90GV2evdf9dx8lGJCY18sqfcAjlQ93ImPC2Qt/QbCsF9h0aTe1VELC6
EZAEBjU/3fXzxywoemPW
=6xJh
-----END PGP SIGNATURE-----

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


hka at qbs

May 3, 2012, 3:27 PM

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

On Thursday 03 of May 2012 15:09:42 Robert J. Hansen wrote:
> On 05/03/2012 01:14 PM, Ali Lown wrote:
> > Does anyone know why the limit is set at 4096 bits
>
> The consensus of the cryptographic community is that beyond 3K keys you
> really need to be switching to elliptical-curve cryptography. A 3K RSA
> or Elgamal key is roughly as difficult to break by brute-force as
> AES128, and that one's so hard that nobody with two brain cells to rub
> together is going to try it.

It all depends on who you're talking to. French[1] suggest 4k for AES128.

But if you've got data that needs to be protected for 30-40 years, using
AES256 is basically a no-brainer. Using just 4k RSA with that is not a smart
decision, and that's agreed by basically anybody (NIST, ECRYPT II). Especially
when the cost of establishing the link with 8k RSA is insignificant for any
session over 5min in length (as is common in SSH).

Besides that, Schneier and Ferguson[2] say that basically any RSA based crypto
system should support 8k keys. Switching to ECC is not easy, you need to
change your whole infrastructure, protocols, management systems, etc. to allow
this. Generating extemely large keys is very easy in comparision.

Using large keys would be stupid only if you need low latency/high IOPS system
that can't use long lasting secure channels: web servers. But that's not our
use case.

Regards,
Hubert Kario

[1]: http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
[2]: Practical Cryptography, Chapter: RSA Defined, section "The size of n",
p233
--
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


John at enigmail

May 3, 2012, 6:03 PM

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

Ali Lown wrote:
> I am trying to use gpg-agent for my ssh keys as well as my gpg keys,
> but am unable to add my 8192 bit ssh key to the agent.
>
> Agent log reports: "2012-05-03 17:48:02 gpg-agent[2190] ssh keys
> greater than 4096 bits are not supported"
>
> The limit appears to be arbitarily set in agent/command-ssh.c
> following a max mpi_data_size.
>
> Does anyone know why the limit is set at 4096 bits, and whether there
> are any plans for supporting SSH keys of lengths greater than 4096bit
> in the gpg-agent?

[.I think I write this same email on one list or another at least once per year]

Because past RSA key sizes of 2048-3072, the migration is to Elliptic Curve
Crypto (ECC). Huge RSA keys does not scale for most Internet usages (PKI/TLS/SSL).

NO ONE is recommending 4096 RSA or DSA, not because it's unsafe but it's
computationally unwieldy, especially on small devices. At asymmetric key sizes
of 3072 bits, the smart money is moving to Elliptic Curve Cryptography (ECC).

How does ECC compare to RSA _today_?

>From the National Institutes of Science and Technology (one of the gold
standards for engineering know-how):

RSA ECC Sym
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256

(One may add a 'Hash' column by doubling the values in the Symmetric
Encryption column.) These recommendations can be found on page 63 of NIST
Special Publication 800-57, Recommendations for Key Management, Part I. 2nd
Revision, 8 Mar, 2007.
[http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf]
All three parts of SP800-57 are available at
http://csrc.nist.gov/publications/PubsSPs.html

The NSA's 2010 Suite-B
[http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml]
recommendations are:
Type Symmetric Elliptic Curve Hash
Secret 128 256 256
Top Secret 256 384 384

A key aspect of Suite B is its use of elliptic curve technology instead of
classical public key technology. During the transition to the use of elliptic
curve cryptography in ECDH and ECDSA, DH, DSA and RSA can be used with a
2048-bit modulus to protect classified information up to the _secret_ level
[http://www.keylength.com/en/6/].

So, depending on the source, a consensus seems to be forming that beyond a
2048 or 3072 bit modulus for DSA2 or RSA, folks need to switch to ECC.

2048-RSA is the current default in GnuPG. OpenPGP cards will support up to
3072-bit RSA; GnuPG up to 4096-bit RSA and 3072-bit DSA2. ECC in OpenPGP is on
its way toward becoming a RFC and being included in OpenPGP. Larger and larger
RSA keys aren't the solution, ECC is. The balance of power has tipped away
from RSA and toward ECC.

The Internet Draft for ECC in OpenPGP
[https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-11] is in the Final
Comment period with comments due by 2012-04-09.
I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID
is approved. I know it's already present in the 2.1 beta code.

Feel free to ignore everything I've told you. There's no reason you should
trust me. But by all means, keep asking questions and read the authoritative
articles and documents.

-John
--
John P. Clizbe Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or
mailto:pgp-public-keys [at] gingerbear?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

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


wk at gnupg

May 4, 2012, 1:37 AM

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

On Fri, 4 May 2012 00:27, hka [at] qbs said:

> decision, and that's agreed by basically anybody (NIST, ECRYPT II). Especially
> when the cost of establishing the link with 8k RSA is insignificant for any
> session over 5min in length (as is common in SSH).

Sorry, but that is plain nonsense. Maybe not with your desktop box, but
my N900 takes quite some time to compute with 4k RSA keys.

> Besides that, Schneier and Ferguson[2] say that basically any RSA based crypto
> system should support 8k keys. Switching to ECC is not easy, you need to

I can't locate my copy right now. Anyway, such suggestions depend
largely on the context. It might be true in theory for US or French
govt security but not for any practical purposes. Brian Snow of the NSA
once told during lunch that they don't care to break the crypto - "we
cheat". What he meant is that it is way easier and cheaper to exploit
software bugs or RNG peculiarities than to build for example Twinkle
devices. If the NSA is worth its money, you should assume that they
have a bunch of zero day exploits available for all kind of software -
including GnuPG.

In particular SSH, which by its nature can't be used on a dedicated
offline box, the use of even a 4k key is ridiculous. Such use reminds
me more of security policies which demand the use of passphrases but
allow that the passphrase be stored on the same box in a file.

Current practice is the use of 2k RSA keys and you simply do that just
because everyone is happy if you follow this rule. Using a lower key
size might be justifiable but it is not worth to spend the time to
explain the reason why it is okay to use only, say, 1536 bit.


Shalom-Salam,

Werner

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


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


wk at gnupg

May 4, 2012, 1:45 AM

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

On Fri, 4 May 2012 03:03, John [at] enigmail said:

> I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID
> is approved. I know it's already present in the 2.1 beta code.

No, we don't plan to port it back to 1.4. It will actually take years
until ECC keys are in wide use and by then 2.1 will be the stable
release. I even hope to declare 2.1 stable sometime this year.

BTW, the draft is already in the rfc editors's publication queue.


Salam-Shalom,

Werner

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


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


hka at qbs

May 4, 2012, 3:07 AM

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

On Friday 04 of May 2012 10:37:21 Werner Koch wrote:
> On Fri, 4 May 2012 00:27, hka [at] qbs said:
> > decision, and that's agreed by basically anybody (NIST, ECRYPT II).
> > Especially when the cost of establishing the link with 8k RSA is
> > insignificant for any session over 5min in length (as is common in SSH).
>
> Sorry, but that is plain nonsense. Maybe not with your desktop box, but
> my N900 takes quite some time to compute with 4k RSA keys.

OK, so the use of 8k RSA keys won't work with low power embedded devices.

It still doesn't change the overall picture:
1. migrating to ECC is hard and complicated
2. using 8k RSA is easy

> > Besides that, Schneier and Ferguson[2] say that basically any RSA based
> > crypto system should support 8k keys. Switching to ECC is not easy, you
> > need to
> I can't locate my copy right now. Anyway, such suggestions depend
> largely on the context.

Quote from the book:

"The absolute minimum size for n is 2048 bits or so if you want to protect
your data for 20 years. This minimum slowly increases as compiters get faster.
If you can afford it in your application, let n be 4096 bit long or as close
to this size as you can get it. Furthermore, make sure that your software
supports values of n up to 8192 bits long."

That was written in 2003, nearly 10 years ago. They suggested using current
day minimums when GPGPU didn't even exist and FPGAs with large memories were
just surfacing.

> It might be true in theory for US or French
> govt security but not for any practical purposes. Brian Snow of the NSA
> once told during lunch that they don't care to break the crypto - "we
> cheat". What he meant is that it is way easier and cheaper to exploit
> software bugs or RNG peculiarities than to build for example Twinkle
> devices. If the NSA is worth its money, you should assume that they
> have a bunch of zero day exploits available for all kind of software -
> including GnuPG.

possibly, still I'd guess that most of them are active, online attacks

but now we're in the hypothetical realm of vague possibility, such discussion
is useless and suggest more that we "just have to throw away cryto as it's
useless anyway" than anything else. Which, frankly, is bollocks.

> In particular SSH, which by its nature can't be used on a dedicated
> offline box, the use of even a 4k key is ridiculous. Such use reminds
> me more of security policies which demand the use of passphrases but
> allow that the passphrase be stored on the same box in a file.

What has online/offline net connection anything to do with that? Storing
acquired information for 20 years is nothing extraordinary as far as
intelligence agencies and highly motivated individuals are concerned.
Hell, I've got files on my hard drive that are around 15 years old.
Computing in 20 years may be very different than it is today.

> Current practice is the use of 2k RSA keys and you simply do that just
> because everyone is happy if you follow this rule. Using a lower key
> size might be justifiable but it is not worth to spend the time to
> explain the reason why it is okay to use only, say, 1536 bit.

Current practice is for data that hardly never has to deal with secrets that
have to be kept for 40 years (like I noted before). As regularly the most
valuable information being passed over secure links are passwords and http
cookies. Which basically never have validity of over 10 years and 1 year
respecitvely.

Thing is, that is not the only use-case of crypto systems.

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


wk at gnupg

May 4, 2012, 3:40 AM

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

On Fri, 4 May 2012 12:07, hka [at] qbs said:

> It still doesn't change the overall picture:
> 1. migrating to ECC is hard and complicated

Right, it will take years. But that is not a problem.

> 2. using 8k RSA is easy

I already told my opinion on this.

> That was written in 2003, nearly 10 years ago. They suggested using current
> day minimums when GPGPU didn't even exist and FPGAs with large memories were
> just surfacing.

A point that they don't consider is that the weakest link defines the
security of the system. They evaluate this only in terms of algorithms
but not from a software engineering POV. If you look at this this you
see that errors in the software (and hardware) are a far weaker link
than any theory on how long it will take to break a certain algorithm.

> possibly, still I'd guess that most of them are active, online attacks

We have been talking about SSH - this is online. Whether active or
passive doesn't matter. Email can also be considered online.

Backups are often offline and then you won't target the encryption but
the plaintext - having access to the hardware (which you need for
offline attacks) opens a long list of attack vectors and cryptography is
just one of them.

> but now we're in the hypothetical realm of vague possibility, such discussion
> is useless and suggest more that we "just have to throw away cryto as it's
> useless anyway" than anything else. Which, frankly, is bollocks.

Nobody said this.

> What has online/offline net connection anything to do with that? Storing

A lot. Online connections allow for active attacks on the participating
software. For off-line it is harder to mount attacks; but still
possible (cf. Stuxnet).

> have to be kept for 40 years (like I noted before). As regularly the most
> valuable information being passed over secure links are passwords and http
> cookies. Which basically never have validity of over 10 years and 1 year
> respecitvely.

Well, then I can't follow your arguments - we need 8k RSA despite that
the data needs to be protected only for a short term?


Shalom-Salam,

Werner

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


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


rjh at sixdemonbag

May 4, 2012, 5:40 AM

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

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.

An effective quantum computer with the 6144 qubits required to break a
3072-bit RSA key is straight out of science fiction. This quantum
computer would be more powerful than any conventional computer could
ever be: a conventional computer would require 10**1850 bytes of storage
-- and no, that is not a typo -- to compete against it: that should give
you a sense of the outrageous scale involved. There is no other way to
describe this than science fiction.

If you want to defend against science fiction, well, go right ahead.
But I think you should also defend against other sorts of fiction, and I
look forward to hearing how your security model will incorporate G.I.
Joe to fight off the hordes of blue-suited terrorists sent by Cobra
Commander.

And yes, I really do believe that worrying about the development of
large-scale quantum computers is on the same level of seriousness as
worrying about Cobra Commander.

> What has online/offline net connection anything to do with that? Storing
> acquired information for 20 years is nothing extraordinary as far as
> intelligence agencies and highly motivated individuals are concerned.

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!"?

If you have reason to believe you're a person of such interest to such
professionals as would be likely to monitor and store your
communications for twenty years, here's the only effective way to secure
your communications: stop using any technology more sophisticated than a
frying pan.

bin Laden didn't keep his communications secure by using large RSA keys.
He kept his communications secure by abandoning technology and using
cut-outs to do his online transactions for him, and making them travel
hundreds of kilometers away from Abottabad before checking into an
internet cafe to send his traffic.

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


mwood at IUPUI

May 4, 2012, 5:53 AM

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

Let me turn things around. Other than providing opportunities to
discuss the practicalities of large RSA keys, is there any reason why
the agent should care what size key it is storing?

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.


gnupg at oneiroi

May 4, 2012, 7:17 AM

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

Hello Robert, Hello all.

On 05/04/2012 02:40 PM, 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)?

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) and reduce strength of symmetric ciphers in half (with for
example Grover's algorithm).

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.

> 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.
>
> An effective quantum computer with the 6144 qubits required to break a
> 3072-bit RSA key is straight out of science fiction. This quantum
> computer would be more powerful than any conventional computer could
> ever be: a conventional computer would require 10**1850 bytes of storage
> -- and no, that is not a typo -- to compete against it: that should give
> you a sense of the outrageous scale involved. There is no other way to
> describe this than science fiction.

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.

> If you want to defend against science fiction, well, go right ahead.
> But I think you should also defend against other sorts of fiction, and I
> look forward to hearing how your security model will incorporate G.I.
> Joe to fight off the hordes of blue-suited terrorists sent by Cobra
> Commander.
>
> And yes, I really do believe that worrying about the development of
> large-scale quantum computers is on the same level of seriousness as
> worrying about Cobra Commander.

"Believe" is good term when talking about aesthetics for example. This
isn't the same as being convinced about proper approach to technical
problems.

If you have proper background in genetics, fresh stream of information
from covert labs, bio black markets (is there such thing anyway?) its
worth to take your opinion into account.

Please try to avoid comedic undertone of your statements and comparisons
if you want to keep discussion's level sane.

>> What has online/offline net connection anything to do with that? Storing
>> acquired information for 20 years is nothing extraordinary as far as
>> intelligence agencies and highly motivated individuals are concerned.
>
> 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".

Yeah, let's drop all the crypto (encryption) for common folk because
<put your arguments from above here>.

> If you have reason to believe you're a person of such interest to such
> professionals as would be likely to monitor and store your
> communications for twenty years, here's the only effective way to secure
> your communications: stop using any technology more sophisticated than a
> frying pan.
>
> bin Laden didn't keep his communications secure by using large RSA keys.
> He kept his communications secure by abandoning technology and using
> cut-outs to do his online transactions for him, and making them travel
> hundreds of kilometers away from Abottabad before checking into an
> internet cafe to send his traffic.

And this isn't proof for anything (especially guy is down now). At the
best this can be interesting case study. If someone was never caught
driving without driving license (where this is forbidden)
this doesn't mean that it doesn't make sens to have such license. This
is a common trap - you think it's not worth investing your time and
effort (if any) in some kind of approach/tools/procedures because you
believe there will be no incident in which they'll provided you protection.

Giving users easier-then-hacking-through-sources way of setting bigger
key size isn't a crime.

I think I should give Werner much faster phone now ;) (on my own using
8192-bit RSA key takes about 2-4 seconds to successfully auth; phone was
made in 2010 and is simply _average_ smartphone)

--
Kind regards,
Milo

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


dougb at dougbarton

May 4, 2012, 7:59 AM

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

On 05/04/2012 01:45 AM, Werner Koch wrote:
> On Fri, 4 May 2012 03:03, John [at] enigmail said:
>
>> I suspect WK has ECC ready to go in both GnuPG 1.4 and 2.0 as soon as the ID
>> is approved. I know it's already present in the 2.1 beta code.
>
> No, we don't plan to port it back to 1.4. It will actually take years
> until ECC keys are in wide use and by then 2.1 will be the stable
> release. I even hope to declare 2.1 stable sometime this year.

I hope you reconsider backporting ECC to 1.4. Given some of the changes
you've announced for 2.1 I think there are a non-trivial number of users
who will be dropping 2.x altogether.

Doug

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


rjh at sixdemonbag

May 4, 2012, 8:13 AM

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

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

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

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

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

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

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.

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

An Apollo engineer would be unlikely to view a tablet PC as something
indistinguishable from magic. Nothing about it would be unknown to
them: only the size, the power and the integration would be new. This
is pretty much the norm in the field: from a pure computer science
perspective there's almost no difference between a Burroughs 5000 and a
modern x86_64.

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.

> Yeah, then leave your home open because "Wow, who want to check
> every door in the world. So many of them".

Non sequitur.

> Yeah, let's drop all the crypto (encryption) for common folk because
> <put your arguments from above here>.

Non sequitur.

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

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


ali at lown

May 4, 2012, 9:21 AM

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

> Let me turn things around. Ā Other than providing opportunities to
> discuss the practicalities of large RSA keys, is there any reason why
> the agent should care what size key it is storing?

Thank you for trying to return this discussion to the original topic.

My intention as OP was to ask how difficult it would be to implement
(it seems to just be a magic-value in the code), rather than the
discussion on the (non?)merits of 8k keys this thread appears to have
become. (Which seems to have a split opinion amongst the
more-knowledgeable-than-me residents of this list).

Ali

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


wk at gnupg

May 4, 2012, 10:08 AM

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

On Fri, 4 May 2012 16:59, dougb [at] dougbarton said:

> I hope you reconsider backporting ECC to 1.4. Given some of the changes

It would be a lot of work and I doubt that we can find anyone to finance
that. In fact, finding financial support for any kind of work on GnuPG
is very hard.

> you've announced for 2.1 I think there are a non-trivial number of users
> who will be dropping 2.x altogether.

Really? The only major change users might notice is the dropping of
secring.gpg - something I am announcing for more than 10 years ("Please
always use --export or --import and don't use the keyring files
directly").


Shalom-Salam,

Werner

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


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


wk at gnupg

May 4, 2012, 10:14 AM

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

On Fri, 4 May 2012 14:53, mwood [at] IUPUI said:
> Let me turn things around. Other than providing opportunities to
> discuss the practicalities of large RSA keys, is there any reason why
> the agent should care what size key it is storing?

The OpenPGP parser has a limit on the size of the MPI which is at 16k
bits. This is required to avoid DoS attacks. Key generation is limited
in the way we allocate memory for prime generation and well, the
arbitrary limit of 4k RSA modulus.


Salam-Shalom,

Werner


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


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


wk at gnupg

May 4, 2012, 11:40 AM

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

On Fri, 4 May 2012 16:17, gnupg [at] oneiroi said:

> I think I should give Werner much faster phone now ;) (on my own using
> 8192-bit RSA key takes about 2-4 seconds to successfully auth; phone was

2 seconds are way too long. I look at most mails not even for a second;
if I need to wait 2 seconds for decryption and another 2 for verifying
the signature, this will be a very noticeable delay. From a UI design
point of view, any noticeable delay is a no go.

And for sure I need to make sure a power socket is close to me if my
device is constantly crunching numbers.


Shalom-Salam,

Werner

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


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


ali at lown

May 4, 2012, 11:54 AM

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

>> I think I should give Werner much faster phone now ;) (on my own using
>> 8192-bit RSA key takes about 2-4 seconds to successfully auth; phone was
>
> 2 seconds are way too long. Ā I look at most mails not even for a second;
> if I need to wait 2 seconds for decryption and another 2 for verifying
> the signature, this will be a very noticeable delay. Ā From a UI design
> point of view, any noticeable delay is a no go.

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 for sure I need to make sure a power socket is close to me if my
> device is constantly crunching numbers.

Find one with a better battery/more-efficient processor if these sorts
of calculations would really be an issue, compared to the general
radio use of the phone.

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


wk at gnupg

May 4, 2012, 12:24 PM

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

On Fri, 4 May 2012 20:54, ali [at] lown said:

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

The delay with SSH would even be longer. Again, it is plain stupid to
assume that you can reach any security improvments on mobile phone (or
to a lttle lesser degree on servers) by increasing the key sizes. The
security gain is bug bound and not bound to the key size.

> Find one with a better battery/more-efficient processor if these sorts
> of calculations would really be an issue, compared to the general
> radio use of the phone.

Radios are very well optimized. CPUs also very energy efficient - but
only if they are idle. On most smartphones you can already notice that
by playing a Vorbis file compared to playing a MP3 file; the latter use
the DSP (instead of the general purpose CPU) and will play a lot more
music before charging is required. Right, you may gain a similar
battery life boost by using a crypto accelerator - however they are only
designed for 2048 bit and I don't know whether they are available on SoCs


Salam-Shalom,

Werner

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


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


peter at digitalbrains

May 4, 2012, 12:41 PM

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

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.

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


dougb at dougbarton

May 4, 2012, 12:47 PM

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

On 05/04/2012 10:08 AM, Werner Koch wrote:
> On Fri, 4 May 2012 16:59, dougb [at] dougbarton said:
>
>> I hope you reconsider backporting ECC to 1.4. Given some of the changes
>
> It would be a lot of work and I doubt that we can find anyone to finance
> that. In fact, finding financial support for any kind of work on GnuPG
> is very hard.

Understood.

>> you've announced for 2.1 I think there are a non-trivial number of users
>> who will be dropping 2.x altogether.
>
> Really? The only major change users might notice is the dropping of
> secring.gpg - something I am announcing for more than 10 years ("Please
> always use --export or --import and don't use the keyring files
> directly").

I think a lot of people are frustrated with the agent generally, and
only use 1.4 as a result already. The thing that will kill 2.1 for me is
the removal of the multiple public keyring functionality.

Doug

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


ali at lown

May 4, 2012, 12:54 PM

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

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

I created the 8k keys prior to understanding the full effects
reasoning behind a 1k/2k key simply because it was't particularly
computationally expensive for me to do, and I saw no harm in being
overly cautious with a longer key than average.
I see no purpose though (at this stage, with my public key spread
around a variety of locations without issue) in generating a new
'smaller' key for the sole purpose of being able to use GPG's SSH
agent, requiring me to change the public key in every location.

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

I think this is fairly irrelevant to the discussion. Yes there is an
overhead, but performing the calculations is not a significant
concern. (If a server is getting lots of fake logon attempts, you need
to sort out your firewall instead).

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


dougb at dougbarton

May 4, 2012, 12:57 PM

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

On 05/04/2012 12:54 PM, Ali Lown wrote:
> I see no purpose though (at this stage, with my public key spread
> around a variety of locations without issue) in generating a new
> 'smaller' key for the sole purpose of being able to use GPG's SSH
> agent, requiring me to change the public key in every location.

So then your choices are to use 1.4, or patch the agent code to use 8k
keys.

Doug

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