This was recently posted to the gnupg-users list introducing OpenPGP:
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
Simon
So we have OpenPGP too? Is that different to PGP? How is it different to GPG lol - *head on desk*
Thanks for the link!
A x
I'm sure Simon will answer this more fully, but (basically) OpenPGP is a "standard" and GPG is just one "OpenPGP Compliant" implementation (there are others). The idea is that an OpenPGP compliant app should be able to handle ciphertext from any of the others.
So we have OpenPGP too? Is that different to PGP? How is it different to GPG lol - *head on desk*
Thanks for the link!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 24/10/13 10:35, Anna Morris wrote:
So we have OpenPGP too? Is that different to PGP? How is it different to GPG lol - *head on desk*
To elaborate on David's answer:
PGP is the original proprietary software for asymmetric email encryption OpenPGP is an open standard for storing and handling keys like PGP does GPG is the most widely used PGP-like application, and is also Free Software
The situation is confused by the fact that "PGP" is used to refer to all three, though strictly speaking it now only refers to a proprietary product owned by Symantec.
Similarly, SSH, though most commonly used in its Free Software implementation, is also a standard that is implemented by proprietary software companies. Therefore the term "SSH" can refer to the SSH protocl, one of many proprietary SSH software systems, or (most commonly) the OpenSSH application.
Proprietary examples: PGP: http://www.symantec.com/en/uk/desktop-email-encryption?fid=encryption SSH: http://www.ssh.com/index.php/products/tectia-ssh-server/233.html
Sam.
- -- Sam Tuke Campaign Manager Free Software Foundation Europe IM : samtuke@jabber.fsfe.org Latest UK Free Software news: uk.fsfe.org Is freedom important to you? Join the fellowship.fsfe.org
Sam Tuke samtuke@fsfe.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 24/10/13 10:35, Anna Morris wrote:
So we have OpenPGP too? Is that different to PGP? How is it different
to
GPG lol - *head on desk*
To elaborate on David's answer:
PGP is the original proprietary software for asymmetric email encryption OpenPGP is an open standard for storing and handling keys like PGP does GPG is the most widely used PGP-like application, and is also Free Software
That's pretty much it. Further, the free software is properly called GnuPG, or the GNU Privacy Guard, but commonly referred to as GPG, and gpg is the name of the command.
PGP stands for Pretty Good Privacy.
The OpenPGP history page covers its conception[1].
The situation is confused by the fact that "PGP" is used to refer to all three, though strictly speaking it now only refers to a proprietary product owned by Symantec.
This is why I always try to refer to OpenPGP when I talk about the protocol, rather than any one product. In one way, I can see that as confusing when most people seem to call it PGP, but I hope, as with this thread, that being fussy about the terminology de-confuses things in the end.
Similarly, SSH, though most commonly used in its Free Software implementation, is also a standard that is implemented by proprietary software companies. Therefore the term "SSH" can refer to the SSH protocl, one of many proprietary SSH software systems, or (most commonly) the OpenSSH application.
At least SSH is actually the name of the protocol *and* the proprietary software! (Although you could refer to the latter as Tectia SSH.) The protocol now in use by PGP and GnuPG is no longer called PGP if we're being pedantic about it.
"SSL" is another. There are two main protocol versions in current use: SSL 3 and TLS 1. Every modern implementation should now support at least TLS 1.0 (and ideally up to the latest TLS 1.2), so we might properly refer to it as TLS, but we're stuck with the name SSL. History strikes again!
In addition to that, if you're looking to use TLS, you need a private and public keypair, similar to that used with OpenPGP. The public part is the certificate, which follows a standard called X.509, is hardly ever referred to as an X.509 certificate, but as an SSL certificate, and it doesn't even have to be used with SSL or TLS.
The software, by the way, is boringly not called SSL. This is probably because it gets implemented in libraries, rather than directly by end user software. Most SSL and TLS libraries are free software, with OpenSSL being the most common, and GnuTLS being a relatively recent addition. NSS (Network Security Services) is that used by Netscape, and then Mozilla. SChannel is Microsoft's proprietary implementation, a part of its operating systems.
Simon
so to reply to ALL of these - Is this OpenPGP standard the one that CGHQ and co were trying to deliberately weaken/water-down or is that something else?
Thanks for the help and info guys, much appreciated
A x
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 25/10/13 11:57, Anna Morris wrote:
so to reply to ALL of these - Is this OpenPGP standard the one that CGHQ and co were trying to deliberately weaken/water-down or is that something else?
Something else I think - I haven't read anything about the NSA affecting the OpenPGP standard. Feel free to link to articles that you think state otherwise - - I'd be interested to go through them.
Best,
Sam.
- -- Sam Tuke Campaign Manager Free Software Foundation Europe IM : samtuke@jabber.fsfe.org Latest UK Free Software news: uk.fsfe.org Is freedom important to you? Join the fellowship.fsfe.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/10/13 13:44, Sam Tuke wrote:
On 25/10/13 11:57, Anna Morris wrote:
so to reply to ALL of these - Is this OpenPGP standard the one that CGHQ and co were trying to deliberately weaken/water-down or is that
something
else?
Something else I think - I haven't read anything about the NSA
affecting the
OpenPGP standard. Feel free to link to articles that you think state
otherwise
- I'd be interested to go through them.
Best,
Sam.
IIRC, it's the encryption algotirhms (e.g. RSA) including the newer elliptic-curve standards that the NSA is accused of influencing.
- -- Jack
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 25/10/13 14:48, Jack Allnutt wrote:
IIRC, it's the encryption algotirhms (e.g. RSA) including the newer elliptic-curve standards that the NSA is accused of influencing.
Yes indeed. I just dug up some articles:
http://www.theregister.co.uk/2013/09/23/rsa_crypto_warning/ https://www.schneier.com/essay-446.html
- -- Sam Tuke Campaign Manager Free Software Foundation Europe IM : samtuke@jabber.fsfe.org Latest UK Free Software news: uk.fsfe.org Is freedom important to you? Join the fellowship.fsfe.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 25/10/13 15:10, Sam Tuke wrote:
Yes indeed. I just dug up some articles:
http://www.theregister.co.uk/2013/09/23/rsa_crypto_warning/ https://www.schneier.com/essay-446.html
Also: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929
The solutions are pretty easy though - stop using RSA (most FS products already did this some time ago afaics), and use longer key lengths with elliptic curve cryptography (sort of obvious in the first place, but developers need to take note).
Best,
Sam. - -- Sam Tuke Campaign Manager Free Software Foundation Europe IM : samtuke@jabber.fsfe.org Latest UK Free Software news: uk.fsfe.org Is freedom important to you? Join the fellowship.fsfe.org
Sam Tuke samtuke@fsfe.org wrote:
Yes indeed. I just dug up some articles:
http://www.theregister.co.uk/2013/09/23/rsa_crypto_warning/ https://www.schneier.com/essay-446.html
Also: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929
The solutions are pretty easy though - stop using RSA (most FS products already did this some time ago afaics), and use longer key lengths with elliptic curve cryptography (sort of obvious in the first place, but developers need to take note).
I don't see a good reason to recommend against RSA for public key (asymmetric) cryptography given the alternatives. The recommendation from Schneier was to use symmetric where possible.
The RSA issue from 2006 was due to the default random number generator (Dual_EC_DRBG) in one of it's products (RSA refers to a company, it's product, and the algorithm). This is an issue, but one that can be rectified with configuration. I don't know of any evidence that shows the RSA algorithm is crippled, but if you do please do tell.
RSA was not used in free software due to patent issues. These are now resolved, and GnuPG now defaults to using RSA for signing and encryption.
DSA is the major alternative to RSA for signing in GnuPG, and ElGamal is a variant of it used for encryption. DSA is faster than RSA. I think, based on readings from various sources, it may have an advantage of a smaller key size for the same effective encryption, but I don't know, and it's hard to measure. (See http://www.keylength.com/ for comparisons of various algorithms from different sources.)
However, DSA has a big problem: it is highly reliant on a good PRNG (pseudo-random number generator). Unfortunately PRNGs are easier to subvert than the mathematics, and the subversion can easily go unnoticed. The case in point (though I think it is more likely to be accidental than actual subversion) is the Debian PRNG weakness that affected OpenSSL and OpenSSH (https://www.schneier.com/blog/archives/2008/05/random_number_b.html). It was apparently present for nearly two years. DSA is also standardised by NIST, which may have been influenced by the NSA (though RSA could also have been pressured by government agencies).
OpenPGP actually does use symmetric algorithms. It encrypts a message using symmetric algorithm with a key generated on the spot, and then uses the asymmetric encryption key to encrypt the symmetric key. To decrypt a message it uses the asymmetric decryption key of the recipient to decrypt the symmetric key, which is then used to decrypt the message (this is simplified somewhat). This reduces the amount of data encrypted with the asymmetric key, and therefore reduces the amount of data that can be used for cryptanalysis.
Similar happens with digital signatures: a one way hash (mathematic function, hard to reverse efficiently) of the message is made, and then it is this that is signed using the asymmetric signing key.
If public key algorithms are truly broken (e.g. a backdoor or a mathematical breakthrough), then this is all moot, but the reduction in the amount of data that asymmetric encryption algorithms are use on, and also data that is less likely to repeat due to the random looking output of the encryption and hash algorithms, makes any other cryptanalysis seem unfeasible, unless a truly large volume of messages are encrypted with the same key.
With TLS and other "immediate" protocols, those where the public key algorithm used to encrypt the symmetric session keys is performed between both sender and recipient at the time of the connection (with email you don't get to do this), known as key exchange, there is an alternative known as Diffie-Hellman key exchange. The basic form has some weaknesses where a man-in-the-middle could obtain the key exchanged at the start of a connection, but this is a relatively short period of time. An enhancement to this is Ephemeral Diffie-Hellman key exchange: this provides what is known as Perfect Forward Secrecy (PFS), which essentially means that the symmetric key used to encrypt a message cannot be recovered from previous messages where the same asymmetric key was used.
So, use symmetric algorithms as much as possible, but that means you still need to exchange the keys. Public key encryption is handy for the case where the sender and recipient meet infrequently, and its use in OpenPGP boils down to key exchange, so it's relatively more secure than directly encrypting or signing messages using asymmetric keys.
You might want to use larger asymmetric keys: 2048 bit RSA or DSA2 is considered a minimum now. You may want to use 3072 or 4096 bit keys to increase the security margin. Using larger keys with asymmetric algorithms offers lesser improvement in security (it could be logarithmic).
Avoid the elliptic curve algorithms for now: they're relatively new and the constants are suspect.
Use ephemeral key exchange where possible.
Change your asymmetric keys after some period of time. With OpenPGP you could keep a large primary key for, say, four years, but create smaller sub-keys that you change every year. This means that you would need to start you web of trust every four years, but arguably that is a good thing to do anyway.
Simon
This is what I was thinking of
"The documents show that the agency has already achieved another of the goals laid out in the budget request: to influence the international standards upon which encryption systems rely.
Independent security experts have long suspected that the NSA has been introducing weaknesses into security standards, a fact confirmed for the first time by another secret document. It shows the agency worked covertly to get its own version of a draft security standard issued by the US National Institute of Standards and Technology approved for worldwide use in 2006. " http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-secur...
I remember someone saying that there was an "open" standard being targeted in this way and I just put two and two together. I didn't seem possible for them to be the sole editor of a closed standard in this way, but maybe a weird "open" one I could see them targeting. It's all a bit over my head. Is this the same thing you two were referring too?
A x
On 25/10/13 14:16, Sam Tuke wrote:
On 25/10/13 15:10, Sam Tuke wrote:
Yes indeed. I just dug up some articles:
http://www.theregister.co.uk/2013/09/23/rsa_crypto_warning/ https://www.schneier.com/essay-446.html
Also: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929
The solutions are pretty easy though - stop using RSA (most FS products already did this some time ago afaics), and use longer key lengths with elliptic curve cryptography (sort of obvious in the first place, but developers need to take note).
Best,
Sam. _______________________________________________ Manchester mailing list Manchester@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/manchester