Re: Question regarding s2k algorithms
On Nov 16, 2008, at 9:47 PM, Kevin Hilton wrote: Ok so let me ask things in a different way Is the s2k-cipher-algo used in any other methods other than for protection of the keyring? Seems odd to me that CAST5 is the default -- however I'm sure this is specified according the one of the RFCs. The RFC says nothing about it. CAST5 was chosen to maximize compatibility with older versions of PGP, but not be as slow as 3DES. If you specify --openpgp, it becomes 3DES. It is used whenever a key needs to encrypted/decrypted with a passphrase. The huge majority of the time that is protecting secret keys. The other spot where this is needed is a little obscure: creating a message with both passphrase *and* public key encryption. That is, some recipients use their secret keys to decrypt, and some recipients use a passphrase. In this case, the s2k-cipher-algo is used to encrypt the session key to the passphrase recipients (and like all symmetric encryption, it's up to you to make sure those recipients can decrypt it). There is no current security implication for using the SHA1 hash for password hashing when using symmetric encryption? I'm only asking this in regards to selecting hash algorithms, because there seems to be a little hedging on the tried and true statement "Use the defaults" when it comes to the selection of hash algorithms. The intention of the last statement is not to rehash the old discussion of which hash algorithm to use -- really it is not!! Don't like SHA1? That's fine, and we give you the ability to change it to something else, but then you become responsible for not shooting yourself in the foot. :) Use the defaults. Really. If we felt that overall there was a better algorithm to use than the current default, we'd make that algorithm into the new default. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question regarding s2k algorithms
Kevin Hilton wrote: > Is the s2k-cipher-algo used in any other methods other than for > protection of the keyring? Seems odd to me that CAST5 is the default > -- however I'm sure this is specified according the one of the RFCs. Dunno; this is one of the parts of GnuPG I've never mucked with, so I can't talk intelligently about it. However, regarding your observation that CAST5 is a weird choice, many non-PGP people would agree with you. Like most of OpenPGP's weirdnesses, this is done to make backwards compatibility with PGP 5 and 6 easier. > There is no current security implication for using the SHA1 hash for > password hashing when using symmetric encryption? None. Well... potentially. A largely theoretical attack has been demonstrated against SHA1 when used for message authentication purposes; it is possible this research will spur on attacks against SHA1 when used for password hashing purposes. However, I don't find it to be very likely. If it were to happen, then /wow/, would it be news. > I'm only asking this in regards to selecting hash algorithms, because > there seems to be a little hedging on the tried and true statement > "Use the defaults" when it comes to the selection of hash algorithms. I can't talk about the community's hedging in general; I can only talk about my own. Algorithms get used in a lot of very different ways. Hash algorithms get used to provide password hashing and message authentication. It is possible for an algorithm to be broken for one purpose and still useful for another. For instance, although I consider MD5 to be horribly broken for most cryptographic purposes, I still use it to create one-time passwords. The attacks against MD5 focus on MD5 as it is used in one problem domain; MD5 in other domains is still quite useful. The same thing is happening to SHA1. SHA1 for purposes of signatures is not looking very good. SHA1 for other purposes is still perfectly fine. However -- good luck explaining this to people. It's one of those infamous "subtle distinctions" I talk about incessantly. Most people don't want to spend the time and energy it takes to be a competent cryptographic engineer. They just want an answer. For these people, "SHA1 is still secure but is not looking good in the long-term; migrate to something else; SHA256 looks pretty good" is the advice I give people. And even then, with the subtleties reduced that far, it never fails that people misconstrue what I say to be "SHA1 is broken! We must use SHA256 for everything!". It's kind of frustrating. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question regarding s2k algorithms
Ok so let me ask things in a different way Is the s2k-cipher-algo used in any other methods other than for protection of the keyring? Seems odd to me that CAST5 is the default -- however I'm sure this is specified according the one of the RFCs. There is no current security implication for using the SHA1 hash for password hashing when using symmetric encryption? I'm only asking this in regards to selecting hash algorithms, because there seems to be a little hedging on the tried and true statement "Use the defaults" when it comes to the selection of hash algorithms. The intention of the last statement is not to rehash the old discussion of which hash algorithm to use -- really it is not!! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question regarding s2k algorithms
Kevin Hilton wrote: > I would assume however if this file along with the password was > distributed, that the recipient's gpg version would need to > specifcally have to have the SHA256 enabled in their build or a > problem would result. Potentially. This is why we tell people not to muck about with the defaults. If there's an actual critical need to alter the s2k, then fine, tweak it: otherwise, leave it with the defaults and don't muck about with it. By default, GnuPG will use SHA1 for this task. All OpenPGP applications are guaranteed to support SHA1, so it's a nonissue. Further, the recent attacks against SHA1 are irrelevant in this particular crypto domain. For this purpose, SHA1 is still as strong as it's ever been. > 2. Asymmetric Encrytion -- Am I wrong to assume, but isn't the > session key salted and hashed in the same manner? Again, wouldn't > the recipient need the specific hashes installed. No. A random session key is generated. There's no need to hash random data; in fact, you can argue that hashing random data will probably decrease its randomness. > If you are using a "stock" gpg.conf file, and say for example this > variable is set to Camellia, or IDEA. Contradiction. The stock gpg.conf file does not set this option. If a user is going to muck about with the defaults, then they're responsible for the consequences of that mucking. You may wish to clarify what you mean. > If you use this "stock" gpg.conf file with another gpg version that > doesn't have these ciphers compiled in -- What results? A default > back to CAST5? Beats me. GnuPG tends to bail out if there's an invalid option in the gpg.conf file. I don't know if that's the case for this option, but that's what's happened to me in the past. > What if you change this parameter after keys are already stored on > the keyring? Will this confuse things? No. > And lastly what specifically is the purpose of the > -for-your-eyes-only flag? Is this option currently still in use, or > only included for backwards compatibility purposes. The specific purpose is to be compatible with a PGP 2.6 'feature' which was really just marketing hype. As the GnuPG manpage says, this option does not actually do what people want it to do. That said, I am absolutely certain if the GnuPG developers were to remove it there would be a hue and cry. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question regarding s2k algorithms
On Nov 16, 2008, at 9:11 PM, Kevin Hilton wrote: Just wondering specifically is the option s2k-digest-algo Does this option specifically refer to one particular digest algorithm or a list of algorithms. I'm just thinking there may be a problem with a few different scenarios if this refers to only one algorithm if for example the SHA256 algorithm is used. 1. Symmetric Encryption -- Using symmetric encryption to specifically password protect a file, the chosen password is salted and hashed with the algorithm specificied with the s2k-digest-algo. I would assume however if this file along with the password was distributed, that the recipient's gpg version would need to specifcally have to have the SHA256 enabled in their build or a problem would result. Yes. This is the same issue with picking a symmetric cipher that your recipient doesn't have. When you're encrypting using --symmetric it's your responsibility to pick algorithms that your recipient can handle. 2. Asymmetric Encrytion -- Am I wrong to assume, but isn't the session key salted and hashed in the same manner? Again, wouldn't the recipient need the specific hashes installed. No. "S2K" means "String to Key". There is no string to key conversion in the session key. s2k-digest-algo only applies to your local secret protection in this case, so there is no issue with asymmetric encryption. s2k-cipher-algo If you are using a "stock" gpg.conf file, and say for example this variable is set to Camellia, or IDEA. If you use this "stock" gpg.conf file with another gpg version that doesn't have these ciphers compiled in -- What results? A default back to CAST5? What if you change this parameter after keys are already stored on the keyring? Will this confuse things? I can't quite parse a question here. Use the cipher for what? Symmetric? Asymmetric? You need to state what you're trying to do. Be specific. And lastly what specifically is the purpose of the -for-your-eyes-only flag? Is this option currently still in use, or only included for backwards compatibility purposes. It tags the data as "for your eyes only", which can be interpreted in different ways by different clients. GnuPG in particular won't display it to the screen, but will save it to a file. Note that this feature is more of a "please don't display this file", than a "this cannot be displayed". It's just a hint. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Question regarding s2k algorithms
Just wondering specifically is the option s2k-digest-algo Does this option specifically refer to one particular digest algorithm or a list of algorithms. I'm just thinking there may be a problem with a few different scenarios if this refers to only one algorithm if for example the SHA256 algorithm is used. 1. Symmetric Encryption -- Using symmetric encryption to specifically password protect a file, the chosen password is salted and hashed with the algorithm specificied with the s2k-digest-algo. I would assume however if this file along with the password was distributed, that the recipient's gpg version would need to specifcally have to have the SHA256 enabled in their build or a problem would result. 2. Asymmetric Encrytion -- Am I wrong to assume, but isn't the session key salted and hashed in the same manner? Again, wouldn't the recipient need the specific hashes installed. s2k-cipher-algo If you are using a "stock" gpg.conf file, and say for example this variable is set to Camellia, or IDEA. If you use this "stock" gpg.conf file with another gpg version that doesn't have these ciphers compiled in -- What results? A default back to CAST5? What if you change this parameter after keys are already stored on the keyring? Will this confuse things? And lastly what specifically is the purpose of the -for-your-eyes-only flag? Is this option currently still in use, or only included for backwards compatibility purposes. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
