Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

cfr · 2013-09-06 23:59:30

How similar or otherwise are the key encryption schemes used by e.g. https/ssl and by gpg/ssh keys? If the former is broken, is the latter likely to be broken, too? I ask because I'm not entirely clear how the ways in which key-based encryption works might differ between the kind of system where there is no pre-arranged key-sharing of a private kind (you rely on CA hierarchies instead) and where there is (as when you generate a public/private key pair for use with gpg or ssh).

It is just that the way the Guardian described this today seemed to fit the key-generation paradigm of gpg/ssh even though the encryption reported broken is of the https/ssl type so I'm not sure if I'm just misunderstanding the way these things work or if both are broken or what.

[Note that I am looking for technical information about this and am not trying to start a political discussion even though the question is motivated (as some may guess) by one of today/yesterday's political bomb shells.]

Last edited by cfr (2013-09-07 00:01:16)

Strike0 · 2013-09-08 14:21:46

Given the amount of fuel and technical speculation in that matter, your question has to be answered with "maybe". By the way you should have provided a technical case with it (e.g. how you generate your ssh keys). Without that your thread is more a case for "GNU/linux discussion" in my view.

We don't want to add to the fuzz and speculation here. But let me give you an example: this was an unfortunate bug for the debian project (only). It affected all the applications you name plus many more. It required the regeneration of ssh keys, revocation and regeneration of server ssl certificates (generated over a couple of years with the stable repo!) and more ..
I use this example, because your question is general and it might add to your existing understanding of the mechanics of the protocols and linkages of the packages you name. Follow the links there, dig our wiki and pacman for dependencies of things you use. Maybe that answers enough, so that you even consider this solved for yourself.

mhogomchungu · 2013-09-09 00:46:19

when you connect to an ssh server you have never connected to,you will get a prompt with a signature of the server you are trying to connect to and you are then asked to verify the signature of the ssh server you are about to connect to.

ssh put the responsibility of verification of the signature of the server on you.

https/ssl on the other hand does not ask you,but ask the certificate authority.

The above is the only difference.

ssh way does not scale since to verify the signature,you will have to already have the signature of the server that you hopefully obtained through a different secured means and this is just not workable online.

At the end of the day,you will have to trust somebody to do the work for you when the work gets large enough and what is broken with https/ssl is the certificate verification part,not the encryption path.

cfr · 2013-09-09 00:53:24

@mhogomchungu,
No. It is the encryption part I am asking about here. The issue of trust in certificates is different and is well known as far as I am aware.

@Strike0,
Thanks. I was aware of the Debian incident but hadn't actually seen the information first-hand.

I can't say I consider this solved. I am afraid that it "maybe" broken also may be as close as it is possible to get. I was really interested in whether it was very likely to be broken for gpg/ssh just because it is for https/ssl etc. That is, if the encryption for the latter is known defeated, can we pretty much assume it is also defeated for the former? I guess that is probably not the case without knowing more about the way in which https/ssl etc. is broken...

mhogomchungu · 2013-09-09 01:05:52

if its the encryption part,then they are the same,if its broken in one,it also means its broken on the other.

what guardian article are you referring to?

cfr · 2013-09-09 01:16:14

http://www.theguardian.com/world/2013/s … s-security

Arch Linux

#1 2013-09-06 23:59:30

Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

#2 2013-09-08 14:21:46

Re: Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

#3 2013-09-09 00:46:19

Re: Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

#4 2013-09-09 00:53:24

Re: Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

#5 2013-09-09 01:05:52

Re: Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

#6 2013-09-09 01:16:14

Re: Public/private key encryption: https/ssl vs. e.g. gpg/ssh keys

Board footer