Git clone index-pack failed
Trying to clone gnupg repository on cygwin which I've done many times in the past, but this is what I'm getting: $ git clone git://git.gnupg.org/gnupg.git Cloning into 'gnupg'... fatal: index-pack failed I've even tried: $ git clone git://git.gnupg.org/gnupg.git --depth=1 Cloning into 'gnupg'... fatal: index-pack failed I'm not sure what I should be trying at this point. Frustrating. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Test mail to kevhil...@gmail.com
Not sure who that was but I was not responsible On Jun 11, 2010 4:26 AM, Werner Koch w...@gnupg.org wrote: Hi! One of the subscribers to this list created a mail forward to an automated ticketing system which responds to the the poster. The owner of the ticketing system at secure.mpcustomer.com does not respond to any of our queries to send us more information on the mails triggering the posting. Thus we need to send these test mails in the hope to figure out the culprit. Sorry for the inconvenience, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
LZMA Compression
Although I understand the compression algorithms within gnupg are specified by the OpenGPG standard, are there any grumblings regarding the addition of the lzma compression scheme? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Practical Advice for those using AES256 cipher?
Although I usually get a wide range of responses, is there any practical advice an end-user should take away from the recent AES256 attacks as described here:http://www.schneier.com/blog/archives/2009/07/another_new_aes.html? Should I continue to use AES256 (double AES) or default to single AES or simply default back to 3DES, or just sit tight? Although I found the article interesting (not sure if I understood a lot of the blog comments), is there any practical advice I should take away from it as it relates to GnuPG? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG + PSI Portable
Did you alter your path statement and put your USB drive directories first in the path? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG 2.0,9 - Error when trying to compile in Linux.
I've composed a How-To for compiling GnuPG and GnuPG2. I used Ubuntu 8.10 as my testing platform. I have also verified the installation on cygwin, although the process with cygwin was slightly more complicated, having to download individual libraries rather than using a package management system. Hopefully others may find these instructions useful: http://ubuntuforums.org/showthread.php?t=649466 -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Happy Thanksgiving
A little off topic, however I wanted to wish Happy Thanksgiving to all those users in America, and actually give Thanks to the regular contributors to this mailing list. Thanks -- Kevin Hilton ___ 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
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: Anyone know what became of the Gaim-E Project?
As others have mentioned there is another pidgin encryption technique: http://pidgin-encrypt.sourceforge.net/ . This project also seems to have stalled if I'm looking at the release dates as an appropriate indication. The OTR website specifically addresses this plugin with the following: How is this different from the pidgin-encryption plugin? The pidgin-encryption plugin provides encryption and authentication, but not deniability or perfect forward secrecy. If an attacker or a virus gets access to your machine, all of your past pidgin-encryption conversations are retroactively compromised. Further, since all of the messages are digitally signed, there is difficult-to-deny proof that you said what you did: not what we want for a supposedly private conversation! This explanation doesn't make a lot of sense to me. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Anyone know what became of the Gaim-E Project?
I'm going to try to steer this back onto a relevant topic Robert I love your off the cuff feelings about things. Its when you are at your best. Question: What value do signatures serve then however other than to provide data authentication but not sender authentication? How can you be sure in any case that if you get an unsigned transmission, that the data is secure, was altered, or that a signature was just mistakingly not appended? As a counter argument -- if the private key was stolen and a message signed using the stolen signature, it really doesn't act to prove sender authenticity either -- but I guess it does serve to prove data authenticity. So in the best case scenario if the private keys are kept truly private and secure, the signature mechanism works as designed. In unideal circumstances however, this trust mechanism falls apart however. Seems like somewhat of a quandary? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Anyone know what became of the Gaim-E Project?
Just wondering if anyone was familar with the Gaim-E project? Supposedly this was a plugin for the former IM client Gaim - now known as Pidgin -- that provided for encrypted IM communication using GnuPG.http://sourceforge.net/projects/gaim-e/ Interesting concept, however looks as if the project was abandoned. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
set type digest mode? plus other query
Who was behind the pgp 6.5.8 ckt release? That seemed like a solid piece of software at the time. If your were using windows, it provided a good tray interface, and made encryption/decryption very easy. How does this piece of antiquated software compare to modern day gnupg as far as ciphers used, digests used, etc. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Session Key Questions
When the session key is randomly generated (asymmetric encryption), how large is the session key? Is the length set or does it depend on other parameter such as the length of the DSA/RSA key or hash? Thanks for clarification. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Session Key Questions
Depends on what algorithm you're using for the symmetric cipher. A 128-bit cipher gets a 128-bit session key, a 256-bit cipher gets a 256-bit session key. The only exception might be 3DES, which technically requires a 192-bit session key, but since only 168 bits get used, there could be some discrepancy there. When the session key is randomly generated (asymmetric encryption), how large is the session key? Is the length set or does it depend on other parameter such as the length of the DSA/RSA key or hash? It is the key size of your symmetric cipher. So AES256 == 256 bits, AES128 == 128 bits, etc. Thanks for rapid response -- I guess I'm missing out on some of the more basic details. Just a quick followup. If I'm planning on using gpg to symmetrically encrypt a file for example, and choose a password. This password is salted and hashed. Say for theoretical reasons SHA512 was used to perform the hashing producing a 512 bit hash result. Would then hash then be rounded, or the right most bits excluded if it were to used with AES encryption (which requires a 128 bit key)? In the opposite situation, say SHA1 produced a 160 bit hash result and I wanted to use AES256 (which requires a 256 bit key) -- would extra bits be added onto the hash result to pad the results up to 256 bits? Using the defaults as provided in the standard gpg.conf file -- what hash is used in the normal salting/hashing process during symmetric encryption? I dont believe this is the s2k-digest-algo since this is for key protection. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Session Key Questions
If the hash output is not enough, then extra 0x00 byte will be added to your passphrase and hashed again to produce additional and different hashing output. If even this isn't enough, then two 0x00 bytes will be added and hashed again, and so on. Ok -- so just some points of clarification. What is the default s2k-digest-algo? Lets say its SHA1 or for the point of argument I set it to be SHA1. SHA1 always produces 160 bit resultants. Say I want to use the AES256 cipher. If I am understanding what has been reported previously, this requires a 256 bit key. If the process you described above works, wouldn't a 160 bit hash always be produced? Just to clarify in my own mind your process -- If the hash output is not enough and an extra 0x00 byte (which I think you are telling me 0x00 = 256 0 bits) is added to the passphrase and then rehashed with SHA1 - wouldn't another 160 bit hash be produced again? How would a 256 bit hash ever be produced is the SHA1 hash was always used. Thanks -- I have a feeling I'm getting off in left field here and missing some understanding of some basic concepts. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Testing a build
Just to throw it out there -- if you need to compile for Windows why don't you do it for cygwin? I've just recently been able to compile both gpg and gpg2 using cygwin on WinXP. This saved me the need to cross compile. Probably not the most elegant solution, however it does work. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG --symmetric option and passphrases
When using gpg with the --symmetric flag (as when symmetrically encrypting a file with a passphrase), is the passphrase salted and hashed? Is so, how many times is it hashed, and what hashing algorithm is used for this process? Is this controlled by some parameter in the gpg.conf file or command line flag? Thanks -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Computational Efficiency of GnuPG ciphers and hashes
Its often been mentioned on this mailing list, that 3DES is notoriously slow. On the flipside, what cipher is considered the fastest -- or the most computationally efficient (if this term even applies)? Are there similar relative results among the GnuPG hashes? Thanks -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG --symmetric option and passphrases
On Mon, Oct 6, 2008 at 10:17 AM, David Shaw [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 10:54 AM, Kevin Hilton wrote: When using gpg with the --symmetric flag (as when symmetrically encrypting a file with a passphrase), is the passphrase salted and hashed? Yes. Unless you change that safe default with --s2k-mode. Is so, how many times is it hashed, and what hashing algorithm is used for this process? By default, it's 65536 iterations. The hash algorithm is SHA-1, unless you change it with --s2k-digest-algo. Is this controlled by some parameter in the gpg.conf file or command line flag? --s2k-count is what you're looking for: --s2k-count n Specify how many times the passphrase mangling is repeated. This value may range between 1024 and 65011712 inclusive, and the default is 65536. Note that not all values in the 1024-65011712 range are legal and if an illegal value is selected, GnuPG will round up to the nearest legal value. This option is only meaningful if --s2k-mode is 3. As always, the defaults here are safe. Don't change them unless you know what you're doing. David Thanks -- very clear explanations. How long can the passphrase be? I assume it would be truncated at a particular length. For example if I passes a Whirlpool Hash as the passphrase, would the entire 128-digit hexadecimal hash be used as the passphrase or would this be rounded? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG2 - IDEA
Ok, I've finally managed to compile the gpg2 package (the stable package, not svn) with cygwin. Is there a way to add idea support to gpg2 or is this feature not supported? Thanks -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
Thanks for the quoted sections from Applied Cryptography. Just to throw more fuel on the fire, however from the quoted material, it would seem that Serpent and 3DES have a lot in common -- slowness, but security. Again a lot of ciphers are already included in GnuPG, many it seems for historical reasons, that could be made read only as many have suggested. How a cipher like cast5, but not Serpent could be included, other than for historical reasons, is beyond me. Again as I have been told on this list, in selecting an AES winner, a lot more factors were considered than just plain security, hence the reason why Serpent was never the AES standard. I'll stop ranting now. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
Purely historical reasons. Also, the SERPENT design team, much like the Twofish design team, is strongly pushing abandoning the AES also-rans and using AES. What's the motivation for abandoning the AES also-rans? I can see the motivation for not including them in the OpenGPG specification, however wouldn't it be a mistake to move toward one algorithm (or two in the case of AES and 3DES)? I guess I'm just confused how critically evaluated algorithms (as per the AES competition), such as Serpent and Twofish, are moving towards the opinion of being abandoned, whereby Camellia is moving towards adoption by the OpenGPG committee. On the surface, there seems to be a lot of double-talk regarding the abandonment/ or reasons for not adopting some algorithms, but on the other hand using similar rationale to except other algorithms. Since I don't really understand the process of cryptography other than on the surface, I could be mistaken. However on the surface -- mathematics removed -- these decisions seem to be more political than based on proven concept. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
Robert can probably give a better explanation that I, however with 3072 DSA signing keys, the SHA512 and SHA256 algorithms functionally produce the same length hash since the lower 256 bits are dropped as per the FIPS specification. I've often wondered the consequences of such an action -- whether this makes the chance of a collision higher or equal in comparing the SHA512 modified hash product to the SHA256 hash product. Perhaps someone could elaborate on this. Of course with RSA keys, no such limitation is in place. Just an FYI. (And just another summary, the battle between RSA vs DSA signing keys has been waged many times prior on this mailing list -- Google for it if you don't believe me -- and to summarize the conclusions of many on this list -- this is no functional advantage of using one over the other). -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
By the way... if I use setpref to set my encryption algorithms to AES256 and AES128, does it mean people won't be able to use, let's say, 3DES to send encrypted messages to, even if they are incapable of using AES? I mean... if I forget to add some algo, would I be making my key less compatible with other OpenPGP software? The prefs associated with your key, is advertising to the sender what you would prefer. However the capabilities to decode an encrypted version is really determined by your gpg version and what ciphers it was associated with. Unless you force an algorithm -- with the cipher-algo preference, if your personal-preference list and the preferences associated with the public key (showpref or pref) have no matches in common (this is not a union of the sets), then 3DES is chosen by default. I believe all gnupg version since inception have had the capablities to decode 3DES encrypted messages as dictated by the OpenPGP RFC specifications. (I could be wrong on this very last statement). The use of personal-cipher-preferences rather than cipher-algo is preferred, since it prevents the problem of sending an encrypted communication that the recipient can not decode. If there is a null union of the personal-cipher-preferences and the key preferences, then 3DES is chosen. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
If you never want to see that algorithm used ever, leave it off the list completely. Not to beat a dead horse, but this statement isn't exactly true. The sender can force the use of a particular algorithm that is not on the list. I take objection to the use of the work never. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
I'm not here to create an argument, however the option(s) cipher-algo digest-algo is specifically addressed within the documentation. All the scenarios you are speaking about are extremely unrealistic, not documented in the documentation, and would take extreme measures to fulfill. I except your statement that we need a basic level of communication, however I think this basic level begins by discussing the possible switches which are discussed and documented specifically within the documentation. I am very much a novice in answering question on this mailing list, however I think your rant was unjustified and inappropriate. I'm not making any claims or false statements or presumptions other than those specifically discussed within the documentation. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing preferences
I think the problem is with the word preferences. The use of this word in the setpref command and in the personal-cipher/hash-preferences really doesn't convey what preferences are preferred over each other. The sender's preferences always trump the recipient's preferences. The use of personal-cipher/hash-preferences performs a verification based on the list contained within the recipient's public key, that the recipient has the capabilities to decode/verify the message, whereas the use of the non-recommended cipher/digest-algo avoids this check altogether. Its straightforward once someone explains it, however the use of the word preferences on both the public keys and the sender's preferences does not convey any information on the hierarchy of the preferences (with senders recipients). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
GnuPG in particular works like this: 1) Take the intersection of all recipients preference lists. This rules out any algorithms that would be unusable by someone. 2) Elect a decider. The decider is the one person whose ordered list we will honor the rankings for. If the user has specified a personal-*-prefs list, then the user is the decider. If the user has not specified a list, then the last recipient key is used. 3) Walk the decider preference list from highest ranked to lowest ranked - as soon as we hit an algorithm that is part of the intersection from step #1, stop. For example: Alice has AES CAST5 TWOFISH Baker has CAST5 AES BLOWFISH Charlie has BLOWFISH AES CAST5 Donald has CAMELLIA TWOFISH BLOWFISH Assuming that there is no personal-*-prefs list set), here's how it falls out: Alice Baker Charlie == AES Baker Alice Charlie == AES Charlie Alice Baker == CAST5 Charlie Alice Baker Donald = 3DES Thats a great explanation. Perhaps this should be included in the documentation. Lastly however this is assuming the sender is not using the cipher-algo digest-algo options. From my reading of the documentation, this will force the use of a particular cipher as dictated by the sender, even if the algorithm is not contained in the list of the public keys. I know these two options are not recommended for use, however since they are included as possible options, I think that they should at least be covered by a what if scenario. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG Defaults
For whatever it's worth, many people within the OpenPGP community would really like to see a lot of algorithms go away. (E.g., if it were up to me, only DSA, ElG, AES, 3DES, SHA1 and SHA256 would be supported.) Some people reduce their advertised capabilities in order to encourage moving to a smaller algorithm set. Based on the lack of vulnerabilities of those limited set of algorithms (excluding SHA1 -- another topic entirely), it would seem to be prudent to refine the number of acceptable algorithms. When the SHA family is eventually supplanted and Camellia cipher officially recognized, I only see this list expanding, not shrinking! -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Session Key Questions
Just some quick questions regarding the session key. Ive consulted the RFC4880 docs, however am still slightly confused regarding the session key. 1. How is the session key generated? How is its entropy randomness determined? Is there a specific algorithm used to generate the key? 2. Once generated, Im confused how its used. When I use the gpg --show-session-key option I receive: gpg: session key: `9:EB7DFF392EA4EDBC90A8836F82462CD0E0B5AB22D49141941CE252311ECD2D9C' I believe 9 is referring to the symmetric cipher which the session key is used as described by: 9.2. Symmetric-Key Algorithms ID Algorithm -- - 0 - Plaintext or unencrypted data 1 - IDEA [IDEA] 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - 168 bit key derived from 192) 3 - CAST5 (128 bit key, as per [RFC2144]) 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 5 - Reserved 6 - Reserved 7 - AES with 128-bit key [AES] 8 - AES with 192-bit key 9 - AES with 256-bit key 10 - Twofish with 256-bit key [TWOFISH] 100 to 110 - Private/Experimental algorithm 3. Is it possible to decrypt a gnupg encrypted message if I know the decrypted session key? How could this be accomplished? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Session Key Questions
On Wed, Sep 17, 2008 at 9:41 AM, Werner Koch [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008 15:52, [EMAIL PROTECTED] said: 1. How is the session key generated? How is its entropy randomness determined? Is there a specific algorithm used to generate the key? It is a random number of course: This random number generator is modelled after the one described in Peter Gutmann's paper: Software Generation of Practically Strong Random Numbers. See also chapter 6 in his book Cryptographic Security Architecture, New York, 2004, ISBN 0-387-95387-6. 2. Once generated, Im confused how its used. When I use the gpg --show-session-key option I receive: gpg: session key: `9:EB7DFF392EA4EDBC90A8836F82462CD0E0B5AB22D49141941CE252311ECD2D9C' That one is the encrypted using the public key algorithm (RSA or Elgamal) and prepended to the messaage as described in rfc4880. 3. Is it possible to decrypt a gnupg encrypted message if I know the decrypted session key? How could this be accomplished? Yes, use: --override-session-key string Don't use the public key but the session key string. The format of this string is the same as the one printed by --show-session-key. This option is normally not used but comes handy in case someone forces you to reveal the content of an encrypted message; using this option you can do this without handing out the secret key. Salam-Shalom, Werner Hmm, this method works different than what I thought. For example if I specify a manual session key on the command line: gpg -se -r KevDog --override-session-key 9:345DFG session_key_test_original But then ask gpg to reveal session key gpg --show-session-key session_key_test_original.gpg decrypt I get: gpg: session key: `9:B619909D1DE40EEAA4865A970522895560D6556561BCD8E2B6DEF6DB8E7DA34D' I must be doing something wrong. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Session Key Questions
for ?? historical reasons of compatibility ?? with pgp 5+ the default cipher that will be used for encryption, and also for protection of the secret key, is CAST-5, not 3DES Nope, 3DES is the only MUST cipher algorithm and thus used as the last-resort if the preference system can't decide upon on the algorithm. CAST5 is like IDEA only a SHOULD in OpenPGP as per rfc2440. The updated OpenPGP (rfc4880) changed this SHOULD algorithms to AES-128 and CAST5 but kept 3DES as MUST algorithm. So what is GnuPG's default implementation is no symmetric cipher is specified? Since it includes AES-128, CAST5, and 3DES in all recent distributions, does it use AES-128 or 3DES as the default symmetric cipher if no cipher is specified on the command line, or within the sender's gpg.conf file? I would assume that it would look at the preferences of the public encryption key, and likely pick the first cipher on the list. Since in most recent versions of GPG, AES256 is the first algorithm specified (as demonstrated with the showpref command), that the sender in turn would reply with an AES256 symmetrically encrypted message (if possible). If an older version of GPG were being used that didnt support AES, it would likely then choose among rank ordered subsequent algorithms as shown in the setpref commad. Following this logic however, it would seem for me that CAST5 would be chosen preferentially rather than 3DES: Cipher: AES256, AES192, AES, CAST5, 3DES, IDEA Other than for backward compatibility purposes, I thought the encryption community had turned their backs on CAST5, but not 3DES. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG Defaults
David Shaw wrote: No. If you don't specify, GPG will take the union of every cipher preference on every key you are encrypting to. It will pick the cipher from that list. If that list is empty, it will pick 3DES. Thanks -- I think I understand the cipher selection process as you describe it. Thanks everyone for the clarification. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Session Key Questions
On Wed, Sep 17, 2008 at 11:51 AM, Werner Koch [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008 17:38, [EMAIL PROTECTED] said: Hmm, this method works different than what I thought. For example if I specify a manual session key on the command line: gpg -se -r KevDog --override-session-key 9:345DFG session_key_test_original --override-session-key is for decyrption only. Shalom-Salam, Werner -- I take it there is not encryption equivalent -- making it in one session using gpg with the symmetric option. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing preferences
I think you are using the wrong command within your gpg.conf file personal-cipher-preferences personal-digest-preferences These control what cipher/hash will be used when using other people's public key. showpref allows you as the sender to be aware of the capabilities (ciphers/hashes) that are available on the recipients machine. You wouldn't want to send someone for example, a message encrypted using the Camellia cipher, when the recipient would not have capabilities by virtue of their gpg version to decrypt the message because Camellia was not compiled into the executable. personal-cipher-preferences (or digest) allows you as a sender to choose algorithms that you prefer. The firstmost algorithm contained within your personal preference that is also within the key preference list is chosen to encode or sign the message. Preferences that are set at key generation time are controlled by the: --default-preference-list string Set the list of default preferences to string. This preference list is used for new keys and becomes the default for setpref in the edit menu. Hopefully that is clear. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG ElGamal Signing Key
Although you would have to go to lengths to create an ElGamal signing key (rather than a DSA or RSA key), is use of an ElGamal signing key still considered to be bad behaivor? The last article I read from 2003 suggested ElGamal signing keys (strictly different than ElGamal encryption keys) had been compromised: http://silverstr.ufies.org/blog/archives/000415.html As a side note, are there any other possible algorithms that may be used to generate a signing key other than DSA/RSA/ElGamal. Thanks. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG Defaults
I'm sure its probably contained in one of the RFC's, however when was DSA signing keys and ElGamal Encryption keys, along with the AES-256 cipher and SHA1 digest chosen as the defaults for key generation? Any particular reasons these were chosen as the defaults? (This is not an attempt to lure people into a discussion of which is better than that). I'm just curious why these were chosen as defaults. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG Defaults
On Tue, Sep 16, 2008 at 11:50 PM, Robert J. Hansen [EMAIL PROTECTED] wrote: Kevin Hilton wrote: I'm sure its probably contained in one of the RFC's, however when was DSA signing keys and ElGamal Encryption keys, along with the AES-256 cipher and SHA1 digest chosen as the defaults for key generation? Any particular reasons these were chosen as the defaults? DSA-1024 is a MUST in the RFC, and therefore is interoperable with every conforming OpenPGP implementation. Likewise with SHA-1. AES is a SHOULD, and is interoperable with the great majority of OpenPGP applications (PGP 7.1+). As DSA-2048 and DSA-3072 support becomes more commonplace (read: as people migrate away from older versions of PGP and GnuPG, a process that takes astonishingly long), you can expect to see the defaults change. I don't know too many people who are still enthusiastic about DSA-1024, although it's still considered infeasible to break it. Im slighly confused. I thought in terms of GnuPG - AES256 was the default cipher as of version 1.48. I thought 3DES was still the standard cipher according to the OpenGPG spec. I dont use PGP, however it would seem that you were implying 3DES is still the default cipher type in this product? Any knowledge on why ElGamal was chosen over RSA as the default session key cipher? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG2 compile problems on cygwin
Perhaps the belongs in development section. Again have never successfully compiled gpg2 for cygwin. I'm trying to compile gnupg2 svn version 4797. I'm getting following error (I've received same error with many of previous revisions also:) libcommon.a(libcommon_a-convert.o): In function `do_bin2hex': /home/klal/temp/gnupg/gpg2/common/convert.c:120: undefined reference to `_gcry_m alloc' Is there something I can do to help with the debugging of this error? Thanks for any suggestions. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
About my prefered settings...
Typing gpg -v --version will give you the capabilities along with the relative numbers for your compiled version of gpg Example: $ gpg -v --version gpg (GnuPG) 1.4.10-svn4783 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12), CAMELLIA256 (S13) Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11) Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SVN version not correctly displaying
$ svn info configure.ac Path: configure.ac Name: configure.ac URL: svn://cvs.gnupg.org/gnupg/branches/STABLE-BRANCH-1-4/configure.a Repository Root: svn://cvs.gnupg.org/gnupg Repository UUID: 8a63c251-dffc-0310-8ec6-d64dca2275b1 Revision: 4765 Node Kind: file Schedule: normal Last Changed Author: wk Last Changed Rev: 4753 Last Changed Date: 2008-04-30 06:46:35 -0500 (Wed, 30 Apr 2008) Text Last Updated: 2008-05-08 00:28:46 -0500 (Thu, 08 May 2008) Checksum: 1c05726d57e4533f00678401269d3603 The version part is discovered here (as you know): m4_define([svn_revision], m4_esyscmd([echo $((svn info 2/dev/null \ || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)| \ tr -d '\n'])) Im not certain about the m4 declarations, but the script logic: echo $((svn info 2/dev/null || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)| tr -d '\n'] Works OK on the command line and produces the desired svn number. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SVN version not correctly displaying
Did You Manually change the version number within configure.ac? I had no idea that you had to change the version number within the configure.ac file. I was hoping to avoid any manual changes but see that it may be needed. Did you make clean or make distclean first? Yes a make distclean -- it didn't make any difference. During the ./configure process it tells you the version number it is compiling for. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Suggestions on how to compile for cygwin
I frequently try to compile svn versions often for the cygwin platform. Both for svn version of gnpgp 1.49 and gnupg2, I'm getting a lot of errors during the make process. All are problems related to the gettext module. By default cygwin is installed with gettext version 0.15 however I did go ahead and install version 0.17 from source as gettext 0.16 or later is required with the gpg2 source installation. I'm still getting errors however. Does anyone have any suggestions how to get around these errors? It always involves the gettext package. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Cygwin gpg 1.4.10 -- svn 4752 make error
Hmmm seems to be another gettext problem -- Any solutions $ gettext --version gettext (GNU gettext-runtime) 0.17 Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Ulrich Drepper. Making all in intl make[2]: Entering directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' gcc -c -DLOCALEDIR=\/usr/local/share/locale\ -DLOCALE_ALIAS_PATH=\/usr/local/ share/locale\ -DLIBDIR=\/usr/local/lib\ -DBUILDING_LIBINTL -DBUILDING_DLL -DI N_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\/usr/local/lib\ -D NO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libi ntl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral version.c version.c:26: error: `LIBINTL_VERSION' undeclared here (not in a function) make[2]: *** [version.o] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk' make: *** [all] Error 2 -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG v2.x?
Just updated to svn version gpg2 4739 Still have same problems trying to compile gpg2 under cygwin with the gettext error: gcc -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshado w -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o compress-bz2.o free-pack et.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o cpr.o plaintext .o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o k eyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen .o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/li bcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lbz2 -lr esolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/usr/local/lib -lgcry pt -lgpg-error -L/usr/local/lib -lassuan -L/usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/temp/gnupg/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/temp/gnupg/libgpg-error-1.6/src/strerror.c:161: undefined reference t o `_libintl_dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) collect2: ld returned 1 exit status make[2]: *** [gpg2.exe] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/gpg2/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/gpg2' make: *** [all] Error 2 I've seen other people complain of a similar error trying to compile other programs, but never found a posted solution. I don't know a lot about playing with the link flags. Are there any suggestions I could try? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG v2.x?
But will it compile using in Vista using cygwin? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG v2.x?
I think I can answer my own question --- No! I obtained svn sources, but during the make process, it failed with the following: gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-secu rity -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o comp ress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-pack et.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey -enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdb io.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libg pgrl.a -lz -lbz2 -lresolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/us r/local/lib -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lassuan -L /usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_ dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/libgpg-error-1.6/src/strerror.c:161: undefined reference to `_libintl _dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strsource.o): In function `gpg_str source': /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG v2.x?
Hmm, thanks for the suggestion. I believe gnupg2 requires gettext 0.17 or greater -- cygwin ships with 0.16, with no higher version available in its mirrors. I downloaded the 0.17 sources from here: ftp://mirrors.kernel.org/gnu/gettext/, compiled and installed. I'm kind of stuck at this point. The intl package is contained within the gettext package correct? For some reason the cvs sources of gettext will not compile. I'm stuck in dependency hell! I'm finding not much luck with the cygwin mailing list either! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG v2.x?
Maybe this isnt for me. I did manage to get gettext compiled from cvs. Its now 0.18-pre1. However I think Im getting stuck at the same point: gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-secu rity -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o comp ress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-pack et.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey -enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdb io.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libg pgrl.a -lz -lbz2 -lresolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/us r/local/lib -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lassuan -L /usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_ dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/libgpg-error-1.6/src/strerror.c:161: undefined reference to `_libintl _dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strsource.o): In function `gpg_str source': /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) collect2: ld returned 1 exit status make[2]: *** [gpg2.exe] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/gnupg2/gnupg/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/gnupg2/gnupg' make: *** [all] Error 2 Still seems like a gettext error. All libs are in /usr/local/libs Thanks for any suggestions or sympathies. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG v2.x?
Clarification, my libraries are in /usr/local/lib Also this link statement seems strange to me. Possibly this is correct?: -lreadline /usr/local/lib/libintl.dll.a ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Whirlpool Hash
Has anyone written a patch that would allow whirlpool as an available hash algorithm for use with gnupg? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Whirlpool Hash
Let us know when you are done with the patch. I'd be interested in trying it out -- that would make one person who could verify your signature! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: When using svn version gnupg, why isnt svn version shown with gpg --version
Just to clarify I wasn't compiling version 1.48 against rev 4702. The flag in the configure.ac was not updated to reflect the newer version, so it appeared it was version 1.48 when in fact it was 1.49 as has been graciously pointed out to me. Thanks for your help. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: When using svn version gnupg, why isnt svn version shown with gpg --version
Whats wrong with my version -- I'm getting 1.48 $ gpg --version gpg (GnuPG) 1.4.8-svn4702 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 My configure.ac (at least the top part looks like this:) # Remember to change the version number immediately *after* a release. # Set my_issvn to yes for non-released code. Remember to run an # svn up and autogen.sh --force right before creating a distribution. m4_define([my_version], [1.4.8]) m4_define([my_issvn], [yes]) m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2/dev/null \ || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)])) I'm guessing it should read like this: m4_define([my_version], [1.4.9]) Since Im using the svn sources I would have thought this file would have automatically at least been updated to 1.49 -- or am I missing something. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: When using svn version gnupg, why isnt svn version shown with gpg --version
Oops, David I see what you meant about updating the flag after the last release -- just updated to the newest svn release and all is well. Thanks $ gpg --version gpg (GnuPG) 1.4.9rc1-svn4705 NOTE: THIS IS A DEVELOPMENT VERSION! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
When using svn version gnupg, why isnt svn version shown with gpg --version
Was wondering if it would be possible to show the actual gpg version with the gpg --version flag when using gpg svn version. It would be nice to show the revision number. thanks -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are DSA2 signing keys backwards compatible?
No. Preferences, including the digest preferences, are not relevant here at all. This is a signature *you* are making. The digest preferences are consulted when someone *else* is making a signature, and wants to know if you can handle it. It has nothing to do with what your key needs because your key is not involved. Sorry I was writing my last reply when I received yours. Thank your for clarification. I understand the difference. However given the fact that I could produce for example SHA256 hashes, wouldn't I prefer the same hash length in return for security reasons? Meaning woundn't it be preferable for the showpref statement to read SHA256, SHA1, RIPEMD160 rather than SHA1, SHA256, RIPEMD160 Again, Im aware of the default-preference-list within the gpg.conf file, This controls the preference order of the hashes, ciphers with key creation within my own set of keys. Other than consulting this in the gpg.conf file, there is no other place this default list could be consulted? Meaning this is no command I could type that would give me the Hash Algorithm I would be using before signing the document -- once the document is signed its easy to see the hash that was used. I suppose the same discussion type could be stated with cipher type. Other than consulting the default preference list within the gpg.conf file (is there is one), is there any way to predict or show a preference list in relation to my own keys? Again if the showpref statement is meant for the other party, is there an equivalent statement or command for myself? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are DSA2 signing keys backwards compatible?
On Feb 10, 2008 10:53 PM, Kevin Hilton [EMAIL PROTECTED] wrote: You could use SHA-512 with it if you liked, but the hash would be truncated to 256 bits. Interesting. Are the higher or lower bits truncated? We follow the advice in FIPS 180-3: L = 1024, N = 160 L = 2048, N = 224 L = 3072, N = 256 Ok. So back to the ever asking defaults question, so why when I produce a 3072 bit DSA signing key, why isnt my first digest hash preference or choice SHA-256? Here is what I am getting: pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC trust: unknown validity: unknown sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E [ unknown] (1). - Command showpref [ unknown] (1). - Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify It would seem in fact that my digest preferences should only be SHA256 or SHA512 based on the information provided! SHA1 or RIPEMD160 shouldn't even be listed here, correct? My reason for asking these questions is in regards to a documentation Im trying to compose for a user's group. Obviously I'm very much a novice in both the mathematics beyonds GnuPG but in also its implementation. Its clear to me you are following both the FIPS and OpenGPG RFC 8440 in implementing the program, however the truncation of longer hash products, along with attempting to predict which hash the program based on the output available will actually use is very troubling and extremely difficult to document given all the nuances of the program, particularly in relation to DSA keys. Given the above example (just one example), where a 3072 DSA key actually uses either a SHA256 or SHA512 bit hash (truncated to 256 bits), despite what is listed when showprefs is displayed -- How do you actually document this scenario? Im sure the situation is similar with 2048 DSA keys. This is particularly troublesome given the fact that many actually recommend the use of 2048 DSA keys - meaning all hashes used are going to be trucated to 224 bits and that 160 bit hashes will never be used despite what would be suggested by the preference statement. Are RSA signing keys subject to some of the same nuances as DSA keys? Practically could a 1024 bit RSA key be used with a 512 hash? Again its all very confusing to me -- math aside and practical considerations why you wouldn't want to mix and match key types and hash lengths. Again Robert Hansen has wisely suggested use the defaults -- I'm understanding this more and more -- however when I see showpref statements that would suggest SHA-1 is the default hash, when in actuality with larger DSA keys it is not, I get rather frustrated. Thank you for your help. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Are DSA2 signing keys backwards compatible?
Are DSA2 signing keys (or simply DSA keys that are larger than 1024 bits) backwards compatible with older GnuPG versions prior to 1.48? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are DSA2 signing keys backwards compatible?
Just to clarify for some other users, What version of GnuPG were the DSA2 keys (or longer DSA signing keys) and the additional SHA hashes introduced? A little of topic, but I'm predicting a future foreseeable bump in the road when the Secure Hash Standard is named in 2011 (or whenever the recent NIST hash analysis is concluded). I guess however the personal-hash-preferences would bypass this problem and default to SHA1 if a new hash (or series of new hashes) is introduced. Hopefully md5 support is abandoned, however I guess for historical purposes this would be unlikely to happen. Even more challenging will be when longer DSA keys become the de-facto standard. I would guess there is not any similar workaround. I guess users of older GnuPG versions would simply have to upgrade. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Authenticate capability of DSA or RSA signing keys
When I perform a gpg --expert --gen-key Im given the following options: Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Your selection? If I select either 3 or 7, Im given the choice similar to below (note the following was produced with option #3): Possible actions for a DSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished I believe I'm aware of the signing capabilities, but how does Certify differ from Authenticate? Obviously I'm confused on the meaning of Certify vs Authenticate. I thought the public DSA signing key did certification/authentication whereas the private DSA key performed the signing. Thanks for any explanation! -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are DSA2 signing keys backwards compatible?
It doesn't work that way. SHA-1 doesn't even work with DSA2 keys. DSA2 doesn't mean a bigger DSA key. It means a bigger hash with a bigger DSA key. DSA2 allows for any hash size that is equal to or greater than the hash size that was used when generating the key. Thus, for example, it is legal (albeit silly) to use SHA-512 with a old DSA key (which uses a 160-bit hash). We just truncate to fit. So just to clarify -- A 3096 bit DSA signing key could only be used with the SHA-512 hash? Thanks for the explanation! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Authenticate capability of DSA or RSA signing keys
Sign = sign some data Certify = sign a key Authenticate = prove you are you Authenticate is used for things like using an OpenPGP key for ssh. I forgot about the certifying of keys, sorry about that. I knew openssh utilized rsa or dsa keys, but didn't know that the same gpg keys could be used for this purpose. That's very interesting. I suppose however the reverse is not true. I suppose I could not take my rsa openssh keypair, and somehow make them work with gpg? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Are DSA2 signing keys backwards compatible?
You could use SHA-512 with it if you liked, but the hash would be truncated to 256 bits. Interesting. Are the higher or lower bits truncated? We follow the advice in FIPS 180-3: L = 1024, N = 160 L = 2048, N = 224 L = 3072, N = 256 Ok. So back to the ever asking defaults question, so why when I produce a 3072 bit DSA signing key, why isnt my first digest hash preference or choice SHA-256? Here is what I am getting: pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC trust: unknown validity: unknown sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E [ unknown] (1). - Command showpref [ unknown] (1). - Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify It would seem in fact that my digest preferences should only be SHA256 or SHA512 based on the information provided! SHA1 or RIPEMD160 shouldn't even be listed here, correct? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
Twofish is almost entirely abandoned nowadays, but it still exists in PGP and GnuPG. Once a bad decision is made in engineering, the engineers are stuck supporting it forever. Is this statement really true or just opinion? Bruce Schneier is one of my favorite cryptoanalysts. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Any plans for GnuPG to implement decrypting to RAM?
Just wonder if GnuPG, similar to PGP, would implement decrypting files to RAM rather than swap, or to allow user to pick location. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
The one specific piece of advice: * Unless you can articulate a clear need why the defaults will not work for your purpose, stick with the defaults. I think I've seen this piece of advice before, and for the most part I agree with it. The problem I have, is that no where in the documentation are the defaults specified. You want me to trust the defaults, but my contention is, at least tell me what the defaults are -- no explanation needed. We had this discussion with the default cipher and hash choices. When you tell me that dsa2 is enabled by default (in newer GnuPG versions), however in the man pages there is still a --enable-dsa2 flag, I hope you understand my confusion. I'm still confused what default cipher is chosen automatically (for me its AES). Again the man pages should accurately represent the defaults, and changes should be made to the documentation when changes to the defaults are added or subtracted. I don't think the current GnuPG manual is complete in any way nor in any way conveys what are the default settings. Its disingenuous for the program creators to expect me to trust the defaults without at least conveying them to me. Rant over, I apologize to the community. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
Im aware of the personal cipher preferences and personal hash preferences, but when talking about the defaults I specifically asking if gpg were installed from source -- no modifications made -- and gpg keys were created - what default cipher and hash would be listed first in the list with the keys? Without any intervention gpg-key-gen It appears to manually choose a DSA signing key (DSA vs DSA2 -- ambiguous since the man pages contain a switch to --enable-dsa2 in the gpg.conf file) with SHA1 hash -- or at least the SHA1 hash is ranked first in the key preference list For the encryption key - a ElGamal 2048 bit key is the default with AES chosen as the first cipher contained in the key cipher preference. Basically I'm aware of the --default-preference-list option in the gpg.conf file that control preferences during key generation. I know how to use this option, but sadly I think the explanation is really lacking: --default-preference-list string Set the list of default preferences to string. This prefer- ence list is used for new keys and becomes the default for setpref in the edit menu. What I want to know is obviously GnuPG comes with a --default-preference-list built-in. If I dont specify this setting in the gpg.conf file, what string is used by default? This would basically reveal the order and list of all the defaults for ciphers, hashes, and compression settings. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
As of 1.4.8 and 2.0.8, and subject to change in future versions: Cipher: AES256, AES192, AES, CAST5, 3DES Hash: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, None You are absolutely correct about these settings. Perhaps this should be included in documentation (and changed when needed), since I would consider these to be the default settings for cipher, hash, and compression choice. All the --enable-dsa2 switch does (and again, it's off by default in 1.4.8 and 2.0.8), is allow you to generate a DSA key that is larger than 1024 bits or has a hash larger than 160 bits. This seems peculiar to me. Why is this setting turned off by default? I'm not at war with anyone in these forums, but many have acknowledged the shortcomings of using 160 bit hashes -- at least with the SHA1 hash. In the same vain, aren't keys sizes larger than 1024 bits actually now recommended? The default fallback allows the creation of a 1024 bit DSA key utilizing the SHA-1 hash -- the preferred preference. Again I know nothing about cryptography but based on the links provided by users' of this forum, it would seem that the choice or a larger DSA key and different hash would be preferable?. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Can you clarify when data compression is used?
Is the data compression algorithm applied to the text prior to being converted to ciphertext, or is the ciphertext compressed, or is it the combination of the ciphertext and encrypted session key that is compressed? I can't seem to find any documentation discussing this. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
On Feb 4, 2008 1:17 AM, Kevin Hilton [EMAIL PROTECTED] wrote: Although not supported on all systems (and not included on ubuntu by default if you can believe it), does bzip2 offers the highest compression? I know that --personal-compress-preferences may be included in the gpg.conf file to take advantage of bzip2 or zlib if desired. Does PGP still only recognize ZIP or no compression? -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
IDEA
Hope I don't get in trouble for posting this, however the idea module can be found here: wget ftp://ftp.gnupg.dk/pub/contrib-dk/idea.c.gz -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
I dont have any feelings or objections about any of the ciphers or hashes included or excluded (ok maybe serpent should be included), however I can imagine that deleting old ciphers and hashes would cause a problem with backwards compatibility. Why md5 and cast5 are still included is beyond me, other than for backwards compatibility. Lastly, who is this governing body that decides what algorithms should be included? The IETF OpenPGP group? As a regular user of gpg, but novice when it comes to the history of PGP/GPG this discussion on the history/politics of GPG/PGP has been very interesting for me. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
From what you are saying about cipher/hashes, it sounds as an end user of gnupg, it would be best to regularly rotate my personal cipher/hash preferences. And lastly, not to be a conspiracy theorist, but how certain can I be that the NSA (who probably employs the single largest collection of cryptographers) hasn't discovered back-doors or cracks in the encryption algorithms? I always get asked this by my brother, and I'm not sure how best to respond. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
Unless you know exactly what you're doing and why, use the defaults. That is all the advice you will get from me. Hmm, not the answer I was quite expecting. Thanks again for all your time. You have greatly enlightened me and reinforced my love for gnupg. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
Just a few follow-up points Quote: My advice has been the same for years: unless you know precisely what you're doing and why, stick with the defaults. GnuPG's defaults are excellent. They make good sense. They interoperate well. Don't mess with them unless you know precisely what you're doing and why. However in your link: http://sixdemonbag.org/cryptofaq.html#agencies, you recommend other things (as discussed below). From my limited knowledge, the default GnuPG settings are to create a 1024-bit DSA signing key, a 1024-bit ElGamal encryption key, a 3DES symmetric cipher, and SHA-1 hash. In your link however, you recommend the creation of 1024 or 2048 RSA signing and encryption keys (or DSA2 signing key with RSA encryption key??), and to choose something else other than the SHA-1 hash. It would seem from your the information in your link, it would not be best to follow the default settings in terms of signing/encryption key creation, and hash algorithm. What hash algorithm should I be using, if SHA-1 is not preferred? SHA512?? Who chooses the defaults in terms of DSA/ElGamal signing/encryption keys? Is this set by the GnuPG programmers or they OpenGPG standard? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
I can see NIST is calling for entries for a competition to discover a new hash function: http://csrc.nist.gov/groups/ST/hash/sha-3/index.html I was hoping they would name the winner of this contest the ASS (American Signing Standard), but see the winner will be referred to as the SHA-3 (Secure Hash Algorithm version 3). No doubt the winner of this consult will eventually be added to the gpg standard. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Question about history of hash and cipher collections
Here was I was able to find about the current hash and cipher choices with gpg Pref Code (n) Algorithm (name)PGP 2 PGP 5 PGP 6 PGP 7 PGP 6.5.8cktGPG 1.0.6 s1 *IDEAX X X X X X * s2 3DES--- X X X X X s3 CAST5 --- X X X X X s4 Blowfish--- --- --- -- X (03) X s7 AES (128) --- --- --- X (7.0.1) X (03) X s8 AES192 --- --- --- X (7.0.1) X (03) X s9 AES256 --- --- --- X (7.0.1) X (03) X s10 Twofish --- --- --- X X (03) X s11 Camellia128 s12 Camellia256 * only with IDEA module Digest (Hash) Algorithms Pref Code (n) Algorithm (name)PGP 2 PGP 5 PGP 6 PGP 7 PGP 6.5.8cktGPG 1.0.6 h1 MD5 X X X X X X h2 SHA1--- X X X X X h3 RIPEMD160 --- X X X X X h6 +TIGER192--- --- --- --- X (08) X + h8 *SHA256 --- --- --- --- X (07) X * h9 *SHA384 --- --- --- --- X (07) X * h10 * SHA512 --- --- --- --- X (07) X * Just a few questions, #1 - How can I generate this list with newer versions of gpg -- is their an internal command that cross-references the s or h numbers with the specific ciphers/hashes that are compiled into the module -- something I can type at the command line? #2 Historically, what ciphers were eliminated -- For example what ciphers were in the s5, s6 slots? Same with the hashes. I believe the TIGER has was equal to s5. What happened to that hash choice? Thanks for your help -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
Sorry about my post Whatever happened to the tiger hash?? Lastly, do you know the reason that the serpent cipher algorithm never made it into gpg. From the NSA competition, I thought the serpent algorithm came in second --- again Im not sure of the criteria that was used to judge strength -- but wasnt it from this competition that the US gov adopted AES as the national standard? Ive seen ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Question about history of hash and cipher collections
Sorry the last post was cut off Sorry about my post I can see you seem to know a lot about gpg -- thanks. Whatever happened to the tiger hash?? Lastly, do you know the reason that the serpent cipher algorithm never made it into gpg. From the NSA competition, I thought the serpent algorithm came in second --- again Im not sure of the criteria that was used to judge strength -- but wasnt it from this competition that the US gov adopted AES as the national standard? Just a question, b/c from my very elementary understanding of ciphers, it seems like serpent is a very secure standard. I believe looking at the source code (either in pgg or pgp2 -- I cant remember) I even saw a serpent.c file. Thanks for your input ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
