From crypto at artemicode.de Sat Dec 1 17:40:04 2012 From: crypto at artemicode.de (Selene Feigl) Date: Sat, 01 Dec 2012 17:40:04 +0100 Subject: Keypad support for PC/SC card readers? Message-ID: <50BA32E4.4070302@artemicode.de> Hello, I have a PC/SC card reader (specifically a "Reiner SCT cyberJack RFID komfort", which is an dual interface RFID/contact class 3 smart card reader (display/keypad) Out of the box the OpenPGP card is working, but the keypad of the card reader seems not to be used to enter the PIN. Is the keypad supposed to be working with gnupg 2.0.x with my reader? Is it possible to get it to work somehow? I offer to test patches if they are available. Although I am a developer, I have no idea of PC/SC / gnupg development. So I am probably not much help at the moment - that could change when someone points me to suitable information to get my keypad working. Greetings Selene Feigl From mailinglisten at hauke-laging.de Sat Dec 1 19:11:15 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 01 Dec 2012 19:11:15 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <50BA32E4.4070302@artemicode.de> References: <50BA32E4.4070302@artemicode.de> Message-ID: <16527463.zXm0jXBUG8@inno> Am Sa 01.12.2012, 17:40:04 schrieb Selene Feigl: > Out of the box the OpenPGP card is working, but the keypad of the card > reader seems not to be used to enter the PIN. Does this refer to setting / changing the PIN or to PIN entry for regular card usage? GnuPG does not support setting / changing the PIN via PIN pad. Whyever. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From crypto at artemicode.de Sat Dec 1 22:47:17 2012 From: crypto at artemicode.de (Selene Feigl) Date: Sat, 01 Dec 2012 22:47:17 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <16527463.zXm0jXBUG8@inno> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> Message-ID: <50BA7AE5.8080302@artemicode.de> Am 01.12.2012 19:11, schrieb Hauke Laging: > Am Sa 01.12.2012, 17:40:04 schrieb Selene Feigl: > >> Out of the box the OpenPGP card is working, but the keypad of the card >> reader seems not to be used to enter the PIN. > > Does this refer to setting / changing the PIN or to PIN entry for regular card > usage? GnuPG does not support setting / changing the PIN via PIN pad. Whyever. > > > Hauke > This refers to regular card usage (signing and ecryptoing a file to myself and decrypting it afterwards). I was asked to enter the PIN for these operations on the text console for both operations. Selene Feigl From mailinglisten at hauke-laging.de Sun Dec 2 01:19:41 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 02 Dec 2012 01:19:41 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <50BA7AE5.8080302@artemicode.de> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> Message-ID: <4256837.J9hvIsBDl6@inno> Am Sa 01.12.2012, 22:47:17 schrieb Selene Feigl: > This refers to regular card usage (signing and ecryptoing a file to myself > and decrypting it afterwards). I was asked to enter the PIN for these > operations on the text console for both operations. There is an option for scdaemon which prevents PIN pad usage: --disable-keypad Is that in the config file? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From patch at cs.ucsb.edu Sun Dec 2 03:24:37 2012 From: patch at cs.ucsb.edu (Patrick Baxter) Date: Sat, 1 Dec 2012 18:24:37 -0800 Subject: WOT and Authentication Research Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, I have a couple research ideas dealing with Authentication and the WOT. I'm looking for any criticism, opinions, or thoughts on my current directions. Mostly, I want to make sure I'm not barking at the wrong problems or that there are not any reasons why some of my current ideas fundamentally would never work either in practice or in theory. It'd be ideal to incrementally deploy any of these solutions, but I'm not assuming that redesigning things is out of the question. Particularly, when it comes to the role of keyservers. One way to describe the general problem of authentication that I think was stated well was in "Distributed Identity Management in the PGP Web of Trust"[1]: >we are trying to map unique and unforgeable identifiers (in this case public >keys) to ambiguous and potentially contested identifiers (names, e-mail >addresses, ect.) I'd state this one step further and say that really you want to know that an identity controls both this forgeable identity and sole access to the private key. Correctly mapping a public key to a communication domain is important but it is better when you can also capture the identity behind it. Google should control its own domain name but also the private key of the public key associated with it. Alice should actually control alice at alice.tld and her private key. When I say communication domain I am mainly considering any sort of unique namespace as part of a communication medium that needs authentication (but may not always require it). Usually these are handed out by single authorities. The obvious cases are e-mail accounts, domain names, XMPP accounts. All have common ways to encrypt and sign information (straight PGP, HTTPS, OTR respectively) The actual keys used for each encryption scheme can be subkeys of the master identity. Ultimately though you must also consider that private keys can be stolen or lost. Their are two independent failure involved: stolen/lost private keys and/or lost control of a communication domain. To account for these failures you can't make knowledge of this mapping immutable, but you also don't want to make it trivial for someone to claim a new public key for an email address whose real owner has already published a key. Malicious people can always of course publish new mappings, so instead I want a strategy to generally restrict publishing of bad mappings while balancing the ability to update mappings for legitimate reasons. I'd like to bring the discussion to find a more sane way to balance these constraints. I have some ideas for improvements in two areas, but keep in mind none of this is tested or fully worked out. First, what I see as the problems with current infrastructure. Problem 1: WOT I see the main function of the WOT is to maximize the chances that, when introduced to a new party, that user van verify the key through a path in the WOT. It'd be nice to have some sense of reliability in this validity and to detect whether this new party is malicious or not (their public key -> domain mapping is not the identity you expect). 1) Trust metrics don't scale in finding valid paths, other proposed trust metrics return non-binary results. When is a WOT path good enough? Current GPG uses a trust metric to say whether or not a key you signed is trusted to introduce another key. Although it makes sense to add a metric for a keys trustworthyness to introduce new keys[2], I don't think this scales logically. Even in the strongly connected WOT [3] the average distance is around 6. This means that to introduce yourself to a new key you need already have determined trust worthiness of 5 arbitrary nodes as introducers. You want to use the web to validate new people and I think in most cases its very unlikely you are capable of making this many trust decisions for some random path. You can make a trade off by using the trust metric of each node only to the keys it signs. Now you might be able to validate longer paths, but the trust metric is less meaningful. Instead users often use the presence of a key on a keyserver for validation (bad) or they attend many key signing parties and have directly signed the keys they talk too. There is a lot of room for improvement, even the existence of one valid path in the WOT (without trust metrics) is better then just taking a key from a keyserver. 2) Multiple keys can contain the same UID. This is a problem because multiple keys can claim ownership to a single name or email address. This allowed because that email address might have multiple keys used with it. I think this is a huge area of improvement. I'd like to impose some sort of structure or restrictions to how non-malicious nodes maintain a WOT. This way there must be some consensus on a single established mapping so that it is not easy for Mallory to create a new key and claim it belongs to an email they don't own. Problem 2: End-user Usability and Accessibility The current WOT and PGP infrastructure is limited to advanced users. It requires manual signing and knowledge to make abstract verification and trust decisions. This is the usability problem. I think a lot of this can be solved through implementation and my current idea revolves around building signatures for a WOT by automatically signing keys you've 'verified'. There are lots of ways to capture out of band user interactions to build a web. User-to-user interaction provides many ways of remembering and establishing validity with identities. People close to you in your social network should be strongly validated and remembered. No paths through the WOT is necessary. Users need a structured approach to both remembering and validating keys but also a way to sign keys and participate in the WOT. The Guardian Project has already started work on this end of things in their PSST project [6]. I've interned for them this past Summer and the PSST project of theirs has largely inspired (or overlapped with) things I am writing now. General Solution: Basically, I think there should be a single publicly established mapping of public keys to domain identifiers. One of each type of domain identifier per public key. It is assumed that each of these domains can provide some sort of proof of control and that as long as you control your domain identifiers and sole access to you private key you can always keep your mapping valid and prevent others from claiming control. Ideally, if private keys couldn't be lost, you could always use your private key to prove ore reestablish ultimate control of something like an email account. However, private keys can be lost or stolen too and this must be considered. Should a failure of lost access/control of EITHER a private key or domain identifier occur there needs to be a best effort approach to resolving this issue. If you lose everything, nothing can be done and you now no longer have control of those accounts or communication channels. This is already true. However, if this mapping also captured some real-world identity of yours. You may be able to appeal through out of band channels to those who validated you based on this knowledge. The big picture is that I want to use some sort of consensus or proof of control to publicly bind this single mapping. A keyserver infrastructure to support this will be necessary but can be designed to require consensus on a single WOT across many keyservers. Of course, all verification of paths should take place offline and we want to servers to have the least authority as possible. They ultimately will have some authority on what mappings are valid. This places a stricter requirement on how we spread WOT information, but will place a higher confidence in the ability to use that information. Improving the role of the WOT: In general, I think the WOT is necessary to provide introductions to new identities. There needs to be some established guarantee of what it can provide and what it cannot. I'd like to see existing paths in the WOT better leveraged for new introductions. 1) 1-1 Mapping and Proof of Identity: I mentioned this mapping above in that the WOT data structure requires a 'consensus' on a single mapping for each public key to a domain(There can only be one!). Also a proof of control is necessary to create or change mappings. Much of the details of this still need to be worked out. There needs to be some cost to changing this identity for legitimate reasons so that malicious users cannot either: present a different public key for a domain identity they don't own OR that by having control of a domain identity they are able to remove the public key the legitimate user controls . There may be some practical solutions that mitigate this problem. For email for example, when you wish to change your master key but keep your email, there could be a lead time on making the change if you lose your key. So when a token is sent to the email to confirm the change, even if its intercepted, as long as it isn't censored, the user in control of the email address will have time to react and prove the key isn't actually lost. A different set of criteria could be determined for each domain of potentially contested mappings. In the future, if a user has a stronger ability to guarantee their private keys are not stolen (ie they have a trusted security token with backups) or that they will at least have access to revocation, stricter requirements could be added to update a key server identity. An important point I think here is also drawing the line between when its good to be flexible in allowing keys to change and when to fail to prevent MITM attacks. Different domains will have different requirements. Also, there are a lot of advantages to a central key infrastructure, but at some point it is still a central point of failure. Maybe if this *better* keyserver thing plays out, work into a distributed WOT data structure that supplements the key servers could be done. There would need to be a meaningful way to solve conflicts between what a user learns from another user and what the keyserver shows. Initial links into this WOT and identities of the keyservers should be distributed with user software that manages these keys. This way they have secure HTTPS communication with the server and eventually they can move to verifying their own seeds into the WOT. This is essentially key pinning and is where the bootstrapping will occur. Since your often already required to trust that software is non-maliciously distributed why not reduce the bootstrap process to a single point. This reduce the opportunities for malicious attacks to one. If people had physical keyrings (I think this is one day ideal, something like GPG smart cards that store more data) you could also trust an entity to supply some initial pinned keys through snail mail rather then the network. That may or may not be a better. 2) WOT structure, path computability, and utility A lot of interesting statistics and research has been done on the current strong set of PGP keys. The most recent attempt on improving trust metrics I've found is in the paper cited as [1]. They argue that current users often simply validate a key by its existence on a public keyserver and that "without automated tools for determining the trust of keys in the web of trust in an established way, users have no feasible alternatives to these bad practices." This paper assigns a trust rating for 3 different methods of determining trust: Disjoint paths, Network Flow, and Strongest Path. I think these are interesting methods, but in the paper, random weights of introduction trust are assigned to each edge in the WOT. This is at least scalable compared to the current GPG solution because you only need a trust metric for keys you signed. I'm not convinced trust introduction metrics are useful beyond a localized scope, but I think path analysis will be. Other statistics and analysis of paths in the WOT: [4][5]. It is not clear to me what is the best way to validate in the WOT and what decision to make when you receive a non-binary metric. For the moment, I think using strongest or disjoint paths would be fine to validate (but not necessarily sign) keys in the WOT once we have some better guarantees that the mapping is correct. So you are essentially trusting the maintenance of the WOT by keyservers combined with an existing valid path that you compute yourself. One interesting way to structure the WOT is by creating a Hypercube of Trust[7]. Based on the size of the Hypercube you have a strict # of bounded disjoint paths that are easily computed and some guarantees on malicious nodes. Quite interesting, but the obvious problem is that this structure doesn't reflect the reality of how the WOT necessarily must be created (socially/randomly). It may be possible to use existing signatures in the WOT to create hypercubes, but thats just another research path. Maybe you could detect what specific signatures you need to create a hypercube and ask those users to validate each other. The hypercube would sort of be a overlay structure used for computability and possibly for better guarantees on malicious nodes (people who make bad signatures on purpose or not). Improving WOT building and user accessibility: A user's own keyring provides the strongest level of verification. Certain types of validation interactions with people they know can be captured as key signatures. Manual signing of course would still be possible to help build connectivity in the WOT. Also, it will be necessary that a user has access to their private keys whenever possible. Most domains of communications don't require authentication, but its ideal that a user always has the option. This of course ties directly into the "Portable Shared Security Tokens" research by the Guardian Project[6]. At some point a user may not be able to verify or validate through the WOT. Then you must fall back to the SSH model of simply remembering keys otherwise known as TOFU/POP (Trust on first use persistence of pseudonym). Verifying a user and keeping a signature is simply the stronger model of this and will also contribute signatures to the WOT. Trusting on first use is bad, so this should be minimized whenever possible or even disallowed for certain use cases. More details will need to worked out. What if you are forced to trust someone on first use, but are MITM'd? Then the next time you talk to this person (still MITM'd) you discover a valid link through the WOT to the real public key. It'd be nice to say that there is enough knowledge to abort your MITM connection, but I'm not yet convinced there is a clear hierarchy of validity here. 1) Automatically building WOT signatures by capturing validation events It'd be nice if every user can contribute to the WOT but also easily verify their own close friends they talk to. Protocols like OTR employ the socialist millionaire protocol for verification and ZRTP can leverage knowledge of a user's voice to verify each other's keys. This is a pretty strong verification I would argue. These exchanges should be captured as signatures. The more ways to capture these interactions the better. Android NFC 'key bumping' might be another valid out of band signing process and you could always find new ways. 2) Minimizing Trust Decisions through portability and use of key hierarchy. Ideally, if Alice validates\ Bob through the OTR socialist millionaire protocol, it'd be nice if this translates over to email as well. By tying multiple accounts to a single identity you can minimize the amount of verification or blind trust decisions a user must make. Thus you have a master key that has signatures for subkeys of each communication domain. So Alice and Bob talk on Jabber and validate each other's OTR keys. Then since they both have their master key present, these keys are exchanged after the OTR sequence and they both sign and verify each other's keys. Now when they use their email encryption and signing subkeys they can validate it through this same signature. Even if they are sending email on a different computer that doesn't have access to their private master key, as long as they know the public key of their master key -> this original verification signature can be passed along safely to their devices that have email since signatures are not private and cannot be forged. This improves portability as well. Open Problems: How can we minimize authority of the key servers? Users will have strong guarantees of people signed in their keyring but must trust the keyservers to establish single mappings between public key and unique communication domain identifier. Also, how would you handle discrepancies between user and keyserver if they wish to build and maintain their own WOT. Is it practical for users to initiate their own proof of control? Can everyone be a keyserver? Also one thing I realized about this mapping I'd want to enforce is that this is precisely what certificate authorities are supposed to be doing when they are doing their job. Except we want to capture this without centralized failures and retain the ability to create our own keys and signatures. So thank you for reading any of this email. I apologize for the verbosity, much of this writing I kept to help organize my own thoughts. Some of this material revolves around trying to develop some sort of community consensus around best practices for authentication infrastructure and some of this is research that still needs exploring, thinking, and results. I am a new grad student at UCSB and interned for the Guardian Project this past summer. I have been interested in authentication for some time, and discussions about Guardian Project's PSST project has been an initial building block for some of these thoughts. Regards, Patrick Baxter References [1] "Distributed Identity Management in the PGP Web of Trust" http://www.seas.upenn.edu/~cse400/CSE400_2005_2006/Margolis/paper.pdf [2] GNU Privacy Handbook: Using Trust to Validate Keys http://www.gnupg.org/gph/en/manual.html#AEN385 [3] Analysis of the Strong Set in the PGP Web of Trust http://pgp.cs.uu.nl/plot/ [4] Neal McBurnett, PGP Web of Trust Statistics http://bcn.boulder.co.us/~neal/pgpstat/ [5] pgp keys, pathfinder, statistics, references http://www.staff.science.uu.nl/~penni101/henkp/pgp/ [6] Portable Shared Security Token http://guardianproject.info/wiki/PSST [7] Improving Webs of Trust Through Predetermined Graph Structure http://repository.lib.ncsu.edu/ir/bitstream/1840.16/617/1/etd.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCgAGBQJQurtXAAoJEByqL5nxaJPJGsoL/jcVEbx4qBwMdOTlFb0xYqUu Y8+i9x36GbB2MIuvoIKj9erKwrT/h+wzcuGVAXb2SaGRgCStPWxGjxrcE9y5dI/z g7Q8d77LeU6QjdLzr0arhLajuRkL9/E4KQfdJDUVtdqWPrRitx15mX50VXKwS36v AsJuFKXGqqncGXRERTQbGxqngBXMDME27a4emHcidi40ftd1yec3ESEBmLfNSPMx Nu49VnytjD8XguKC7gF7E1qnIQ5toFU2VlioZqfGFbrVnJf4wmSEU/aiMAYurLcx oYYGTNia9c66E6uUpTd4gXYMQOgEgRwhOfE1diQj3w9TXyaOzuFQDxvHTiID5Geg tJFqZxkOVzuragDrRAhwBaf3RoBwhDSgym8DkneRDq8EqgMHiYiQL240Jsp9j9RO cMOEpRgt4WjyMpy5iKNiU31W3OodsF+npX1MVGhWo7pIR3BFO+ee45wuOwnNjhOv SA9WE5iJ5sxTe+Ibjip9Yfr9llQIl+6XRrFALVAGcg== =a9bQ -----END PGP SIGNATURE----- From crypto at artemicode.de Sun Dec 2 10:57:27 2012 From: crypto at artemicode.de (Selene Feigl) Date: Sun, 02 Dec 2012 10:57:27 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <4256837.J9hvIsBDl6@inno> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> <4256837.J9hvIsBDl6@inno> Message-ID: <50BB2607.4040107@artemicode.de> Am 02.12.2012 01:19, schrieb Hauke Laging: > Am Sa 01.12.2012, 22:47:17 schrieb Selene Feigl: > >> This refers to regular card usage (signing and ecryptoing a file to myself >> and decrypting it afterwards). I was asked to enter the PIN for these >> operations on the text console for both operations. > > There is an option for scdaemon which prevents PIN pad usage: > --disable-keypad > > Is that in the config file? > There was no scdaemon.conf yet - so I suppose the answer is no. I suppose gnupg tries to detect whether a keypad is available. Is that logged? Which debugging level would be needed. Note: that is a PC/SC reader without CCID Selene Feigl From dshaw at jabberwocky.com Sun Dec 2 16:23:08 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 2 Dec 2012 10:23:08 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <20121007022039.GB57007@redoubt.spodhuis.org> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> Message-ID: <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> On Oct 6, 2012, at 10:20 PM, Phil Pennock wrote: > GnuPG folks (since this is cross-posted, if my mail makes it through): > > there is a bug in GnuPG's SRV handling, I've identified where I think > it is, it's in the second block of text from me; the first part of this > mail relates to SKS and some policy issues around the new keyserver > pool Kristian has added. Somehow I didn't notice this mail when it originally came through. Anyway, thanks for the report. Clearly the port supplied in the SRV should be honored. Can you try the attached patch (against 2.0)? David -------------- next part -------------- A non-text attachment was scrubbed... Name: bug1446.patch Type: application/octet-stream Size: 1339 bytes Desc: not available URL: From richard.hoechenberger at gmail.com Sun Dec 2 20:38:06 2012 From: richard.hoechenberger at gmail.com (=?ISO-8859-1?Q?Richard_H=F6chenberger?=) Date: Sun, 02 Dec 2012 20:38:06 +0100 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBA8C6.3050409@gmail.com> References: <50BBA8C6.3050409@gmail.com> Message-ID: <50BBAE1E.6020608@gmail.com> Apparently I just now figured out how to use Google ;) Found two flash drives with built-in encryption & pinpad: http://www.lok-it.net/ http://www.corsair.com/usb-drive/flash-padlock-2-usb-drive.html Do you guys have any experience with one of these? Best, Richard From peter at digitalbrains.com Sun Dec 2 21:09:21 2012 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 02 Dec 2012 21:09:21 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <50BB2607.4040107@artemicode.de> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> <4256837.J9hvIsBDl6@inno> <50BB2607.4040107@artemicode.de> Message-ID: <50BBB571.5030604@digitalbrains.com> On 02/12/12 10:57, Selene Feigl wrote: > Note: that is a PC/SC reader without CCID AFAIK, keypad entry is only supported through the internal CCID driver of GnuPG, not through a PC/SC stack. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From richard.hoechenberger at gmail.com Sun Dec 2 20:15:18 2012 From: richard.hoechenberger at gmail.com (=?ISO-8859-1?Q?Richard_H=F6chenberger?=) Date: Sun, 02 Dec 2012 20:15:18 +0100 Subject: OT: USB key with hardware encryption? Message-ID: <50BBA8C6.3050409@gmail.com> Hello, so, it happened again. Since I have neither a scanner nor printer at home, I had to scan and print some important documents (CV, copies of some certificates) at my workplace. Scanned them right onto a USB key, which of course had to be unencrypted and formatted with a FAT file system. When I got back home, the key with all its sensitive data was gone. Probably left it somewhere on the train, I don't know. This is not the first time this has happened to me. I usually encrypt every mass storage device in my possession; but I cannot use full disk encryption software at my workplace because of access restrictions. Also, the standalone scanners require plain FAT, as mentioned earlier. I was wondering whether there are USB flash memory devices available that support some kind of hardware encryption, i.e. maybe some USB key with a keypad, which only exposes a (transparently) decrypted filesystem to the host computer. I am using Linux, OS X, and Windows. Do you have any thoughts and recommendations on this issue? Richard From crypto at artemicode.de Sun Dec 2 22:05:54 2012 From: crypto at artemicode.de (Selene Feigl) Date: Sun, 02 Dec 2012 22:05:54 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <50BBB571.5030604@digitalbrains.com> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> <4256837.J9hvIsBDl6@inno> <50BB2607.4040107@artemicode.de> <50BBB571.5030604@digitalbrains.com> Message-ID: <50BBC2B2.5090702@artemicode.de> Am 02.12.2012 21:09, schrieb Peter Lebbing: > On 02/12/12 10:57, Selene Feigl wrote: >> Note: that is a PC/SC reader without CCID > > AFAIK, keypad entry is only supported through the internal CCID driver of GnuPG, > not through a PC/SC stack. > > Peter. > Ok that is sad, but it is an information at last. Is support planned or are there any technical restrictions that make it impossible Selene From dougb at dougbarton.us Sun Dec 2 22:31:21 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 02 Dec 2012 13:31:21 -0800 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBA8C6.3050409@gmail.com> References: <50BBA8C6.3050409@gmail.com> Message-ID: <50BBC8A9.8060006@dougbarton.us> On 12/02/2012 11:15 AM, Richard H?chenberger wrote: > I usually encrypt > every mass storage device in my possession; but I cannot use full disk > encryption software at my workplace because of access restrictions. > Also, the standalone scanners require plain FAT, as mentioned earlier. It's OT for this mailing list, but you could use TrueCrypt in portable mode in this situation with a file volume. Doug From jhs at berklix.com Mon Dec 3 00:31:14 2012 From: jhs at berklix.com (Julian H. Stacey) Date: Mon, 03 Dec 2012 00:31:14 +0100 Subject: OT: USB key with hardware encryption? In-Reply-To: Your message "Sun, 02 Dec 2012 20:38:06 +0100." <50BBAE1E.6020608@gmail.com> Message-ID: <201212022331.qB2NVEu5001224@fire.js.berklix.net> =?ISO-8859-1?Q?Richard_H=F6chenberger?= wrote: > Apparently I just now figured out how to use Google ;) Found two flash > drives with built-in encryption & pinpad: FYI a stick here has paint label: integral 1 GB USB 2.0 Flash Drive with some kind of encryption, its ships with .exe[s] for MS so I've no idea what as I don't touch Microsoft, & use it as plain stick, It has a switch on side makes it switch between a plain 1g stick or apparently a 1.4M USB floppy & then one runs some binary MS stuff to access the rest of stick. Mounting the fd0 it show I previously zeroed out the MS stuff. >From my http://berklix.com/~/jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/devd/jhs.conf match "vendor" "0x0d7d"; match "product" "0x1620"; match "devclass" "0x00"; match "devsubclass" "0x00"; match "release" "0x0100"; FreeBSD /sys/dev/usb/usbdevs: vendor ADDON 0x0d7d Add-on Technology With switch on locked, /dev/ shows just a 1.4M USB floppy & dmesg reports: ugen1.3: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4101 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: < USB DISK Pro PMAP> Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1MB (2880 512 byte sectors: 64H 32S/T 1C) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From faramir.cl at gmail.com Mon Dec 3 02:42:36 2012 From: faramir.cl at gmail.com (Faramir) Date: Sun, 02 Dec 2012 22:42:36 -0300 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBC8A9.8060006@dougbarton.us> References: <50BBA8C6.3050409@gmail.com> <50BBC8A9.8060006@dougbarton.us> Message-ID: <50BC038C.4020605@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 02-12-2012 18:31, Doug Barton escribi?: ... > It's OT for this mailing list, but you could use TrueCrypt in > portable mode in this situation with a file volume. I think he can't, TrueCrypt in portable mode still require admin rights to run, and Richard mentioned access restrictions. Another option is to use 7zip in portable mode, it allows to encrypt the compressed volume using AES, unless the restrictions affect it too (AFAIK, it doesn't require admin rights, but maybe there are ways to restrict it too). Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQvAOMAAoJEMV4f6PvczxAo/kH/i45wACE5Gdee4Qm7dS+0c4m lZQU1wZEwRv0a1G0+qEjbSXmhv3iyHJSHIMDGJPDclVCNq28qCPhmNY7letcmsZP LWhP0pG4V2R0Bg1wW4gxt1RavIKQHEC2QaV5j4OuXqIvFoA8Aj+ULZhFpschcy+c B+NB1WSzuAbEfY93ReHE310iCSq0BITVzB1fKFeR9xGL+4j3MYGQ9Ud8MBxvKBum oFXBXQIG8wQNxXACE6Lva+4YRtPzOgrVosBSpDcqz96S/hhHAJN0usENbmShorB1 NfnbHZgvWKckjTBFqUZCekhkThKXzCRPY8DbccM5BUlciIw/11mRcn1H8iIAoH4= =WUAE -----END PGP SIGNATURE----- From faramir.cl at gmail.com Mon Dec 3 02:49:53 2012 From: faramir.cl at gmail.com (Faramir) Date: Sun, 02 Dec 2012 22:49:53 -0300 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBAE1E.6020608@gmail.com> References: <50BBA8C6.3050409@gmail.com> <50BBAE1E.6020608@gmail.com> Message-ID: <50BC0541.9020508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 02-12-2012 16:38, Richard H?chenberger escribi?: > Apparently I just now figured out how to use Google ;) Found two > flash drives with built-in encryption & pinpad: > > http://www.lok-it.net/ > http://www.corsair.com/usb-drive/flash-padlock-2-usb-drive.html I've read a review about the corsair usb drive, and the writer said it was easy to crack, but then I read another review, saying it is a lot less flawed than the other review said, so I'd trust it to keep my data safe from casual attackers (seriously, how many of us need NSA-proof devices? I know I don't). But don't put it on a washing machine, it seems to be less water-proof than it is supposed to be. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQvAVBAAoJEMV4f6PvczxAc9cIAJgvwUkbB9uZDmTpI88ohHUU TuSFrb7k38V310na7Ne/UEQ2hyn7nNKtSELMMffF4V9w2ixF6PIFhSmovrh7zESh R2iqVHKGQveYdlXSUPhMXVb/wj9QOwlV0UTSmtxw3cbnYNXyf5KGPx4cM1j6pdse Faoam58fMWElmTU/FTSN853cmfUeJcSxLgTZ0TCzsALutFGb7A1Hdz56mzjzHsOe gdzUkckCkgLaFfqXEzkbqfz2/WxeiNfo3aRsQtZv42aFMKnpKm28RSo5LFR4Hl9B pBHe31rWkh5nU/PeF0VH+rzeHqjRU1Js+qilvve58T7uxKY+DKohrBgoTK7QXsE= =uuPo -----END PGP SIGNATURE----- From faramir.cl at gmail.com Mon Dec 3 03:17:43 2012 From: faramir.cl at gmail.com (Faramir) Date: Sun, 02 Dec 2012 23:17:43 -0300 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBAE1E.6020608@gmail.com> References: <50BBA8C6.3050409@gmail.com> <50BBAE1E.6020608@gmail.com> Message-ID: <50BC0BC7.7020002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 02-12-2012 16:38, Richard H?chenberger escribi?: ... > http://www.corsair.com/usb-drive/flash-padlock-2-usb-drive.html > > Do you guys have any experience with one of these? I found the favorable review: http://www.everythingusb.com/corsair-flash-padlock-2-flash-drive-18671.html And I think at Corsair's site there is more info. IIRC, even if you can retrieve the encrypted files, you have to defeat a full 256 bit key, not a 10 digits PIN, so, the PIN is intended to be used together with the time bruteforce protection, and would be used to unlock the AES key. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQvAvHAAoJEMV4f6PvczxAuB4H+gM0HUAJLO9QMgAY5JDP5qib eMZIIGY59U0KEkK5+brZ4waEz9YuG3ZdOMaNhGwMp5TjSVc4JaDnDa44fWyX5j7q 1UQPCI56T4EJ6PYgchsGkuwuSSFnLhJgymomzQXKP7WX70z6pKyXI7v6ztInLGa7 mQRWRa5wEqwzvs3cYKeiINpfifA8jC+W39s7nFiw6GHPafHEpIDZEiGm9y+7CBiu SdKGHlpS+x+KDfaLlXvyEeDI/qQxoDpFPKLLSAYp7YN5uxJYbIQbbFr2JQn6JyEb +EtjKVXu9WKMzXO33fmmsuUSQl4hxNL07F8HcnEXwXQSAFij4paDHNOTfC61c9M= =Mbc8 -----END PGP SIGNATURE----- From len.cooley at gmail.com Mon Dec 3 03:59:11 2012 From: len.cooley at gmail.com (Len Cooley) Date: Sun, 2 Dec 2012 21:59:11 -0500 Subject: Gnupg-users Digest, Vol 111, Issue 2 In-Reply-To: References: Message-ID: I used PGP years ago (when it was still free and the source-code was readily available). I created key pairs. I haven't used any encryption for quite some time, and now I'm trying to move back into using it. I'm beginning to learn about GPG, and I transferred my key pairs to GPG. But, these are old keys. I should probably create new ones. Is there any good reason I should keep my old decryption keys? (Hope this doesn't sound too elementary). -- http://www.auditmypc.com/freescan/antispam.html From dshaw at jabberwocky.com Mon Dec 3 05:46:02 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 2 Dec 2012 23:46:02 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <20121203005958.GA82072@redoubt.spodhuis.org> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> Message-ID: <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> On Dec 2, 2012, at 7:59 PM, Phil Pennock wrote: > On 2012-12-02 at 10:23 -0500, David Shaw wrote: >> On Oct 6, 2012, at 10:20 PM, Phil Pennock wrote: >>> GnuPG folks (since this is cross-posted, if my mail makes it through): >>> >>> there is a bug in GnuPG's SRV handling, I've identified where I think >>> it is, it's in the second block of text from me; the first part of this >>> mail relates to SKS and some policy issues around the new keyserver >>> pool Kristian has added. >> >> Somehow I didn't notice this mail when it originally came through. Anyway, thanks for the report. Clearly the port supplied in the SRV should be honored. >> >> Can you try the attached patch (against 2.0)? > > Might be a sleep issue, but I'm having trouble persuading gpg2 to use > gpgkeys_hkp instead of gpgkeys_curl, or even telling them apart from > "--keyserver-options debug,verbose" output. > > I'm going to bail and grab coffee, but here's what I have for testing, > which should make it easy for you to test too. Hmm. Were you intending to test with the internal HTTP support or with libcurl? You're currently built with internal support: > gpgkeys: curl version = GnuPG curl-shim Looking at the internal support, it seems not to work on platforms with getaddrinfo(), which is odd as that part works in the 1.4 code. Anyway, try the attached patch in addition to the original one, and you should hopefully have better results. I also fixed an issue where the Host: header was not being set correctly after a SRV. It seems to me that like SNI, the Host header should be the SRV name, and thus should never have a :port attached. I tried talking to keytest.spodhuis.org to test, but all the ports returned in the SRV were not listening. Or at least, not listening to me ;) $ telnet keyserver.spodhuis.org 11373 Trying 94.142.241.93... telnet: connect to address 94.142.241.93: Connection refused $ telnet keyserver.spodhuis.org 11374 Trying 94.142.241.93... telnet: connect to address 94.142.241.93: Connection refused David -------------- next part -------------- A non-text attachment was scrubbed... Name: bug1446.patch.2 Type: application/octet-stream Size: 3405 bytes Desc: not available URL: -------------- next part -------------- From rjh at sixdemonbag.org Mon Dec 3 06:00:41 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 03 Dec 2012 00:00:41 -0500 Subject: Gnupg-users Digest, Vol 111, Issue 2 In-Reply-To: References: Message-ID: <50BC31F9.7040703@sixdemonbag.org> On 12/02/2012 09:59 PM, Len Cooley wrote: > I'm beginning to learn about GPG, and I transferred my key pairs to > GPG. But, these are old keys. I should probably create new ones. Is > there any good reason I should keep my old decryption keys? The best reason to keep your old keypair around is pretty simple: "what does it hurt?" If you delete your keypair, then if anyone sends you traffic encrypted to that keypair you'll be unable to read it. If you keep your keypair, then you can. And it's not as if it takes up a lot of room on your hard drive or impairs GnuPG's performance. :) From wk at gnupg.org Mon Dec 3 11:17:26 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Dec 2012 11:17:26 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <50BB2607.4040107@artemicode.de> (Selene Feigl's message of "Sun, 02 Dec 2012 10:57:27 +0100") References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> <4256837.J9hvIsBDl6@inno> <50BB2607.4040107@artemicode.de> Message-ID: <87hao330eh.fsf@vigenere.g10code.de> On Sun, 2 Dec 2012 10:57, crypto at artemicode.de said: > I suppose gnupg tries to detect whether a keypad is available. Is that > logged? Which debugging level would be needed. 2.0.19 has support for keypads via PC/SC. Add this to ~/.gnupg/scdaemon.conf log-file /some/file debug 2048 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Mon Dec 3 12:41:10 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 03 Dec 2012 12:41:10 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? Message-ID: <4887283.ocuTOb2Q7p@inno> Hello, are there arguments for preferring either a) having one RSA subkey for decryption only and one for signing only or b) having only one RSA subkey for both decryption and signing? Do any problems arise with the smartcard if the same key shall do different tasks? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Mon Dec 3 12:53:40 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 03 Dec 2012 12:53:40 +0100 Subject: Gnupg-users Digest, Vol 111, Issue 2 In-Reply-To: References: Message-ID: <2189070.C5RORrd6BL@inno> Am So 02.12.2012, 21:59:11 schrieb Len Cooley: > But, these are old keys. I should probably create new ones. Is > there any good reason I should keep my old decryption keys? What do you mean by keep? Not to delete the private keys? If you have not needed these keys for years then it is improbable that you will need them in the future. But the other way round: Is there any good reason to delete private keys which have been used? You should (if you haven't done so yet) create and publish revocation certificates for the oly keys stating that you have a new key (mentioning the new key ID at best). Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From olav at enigmail.net Mon Dec 3 13:00:05 2012 From: olav at enigmail.net (Olav Seyfarth) Date: Mon, 03 Dec 2012 13:00:05 +0100 Subject: Gnupg-users Digest, Vol 111, Issue 2 In-Reply-To: References: Message-ID: <50BC9445.2030508@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi Len, > I used PGP years ago and created key pairs. I should probably create new > ones. Is there any good reason I should keep my old decryption keys? you must distinguish between using your old keys for new messages/files and keeping them to be able to decrypt old messages/files. Whether it's a good idea to further use the key depends on how the key was created and how big your web of trust is that is associated to that key. If you sticked to the defaults in PGP as they have been many years ago, then maybe it's a good idea to create a new key to use further on AND keep the old key in case you need to decrypt any old message or file. Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJQvJRCAAoJEKGX32tq4e9WljAL/RqiqPs3xT/aqAA9cScG0Zjg yupL4G4TPJfWr7Gwy5kDnzjwh+uOOtFlnX5v/3eU4cIYgVxVw+vKmPswCWXq6gGc ilFbXAvilNkuVfdNYPxm0wE2suz70re/W0AMPickClbXUJOot3jBbgbV12cTVRa5 Tilg54s+0UVD9KrfC5KVLfxsAgNIrUgmznN0OESwZXM+hoFUJSLZhanGtRRF+P2Q 1FGIsQPuWTnaDEsK54iPWOOLfKYEDEWdcGskUWddjPsWskCMppAv6Z39f0gCeT6x /R6asIA+tuQ05d+h6hfIkHGe90MIlxpQRv9fD8GFmwY1rUUUcNM11Hc4VJfbsD1w oM34hrejCEo80dkDexm8yXI8BZRsmIQ95zrWcWA9p1TtRyc9HFsmfFKk7EIgvFw1 MZN5dFtHc0fHaCa4vt56fbcMAKpp2N3wgOD4+K2HHzoryeRd0fDQL7qVgxSbVdmy /3ied18f5KTlmASo/lgv+g513mzI9+ywGZJCv6RMYw== =FP4U -----END PGP SIGNATURE----- From olav at enigmail.net Mon Dec 3 13:03:56 2012 From: olav at enigmail.net (Olav Seyfarth) Date: Mon, 03 Dec 2012 13:03:56 +0100 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBA8C6.3050409@gmail.com> References: <50BBA8C6.3050409@gmail.com> Message-ID: <50BC952C.6000309@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi Richard, you look for a thumb drive that supports some kind of hardware encryption and can operate OS independent and be accessed as plain FAT. I use and recommend http://www.bioslimdisk.com/p_signaturelite.html Works 100% self contained. But it's not exactly what I'd call cheap. Also have a look at these: http://www.digittrade.de/shop/index.php/cat/c22_Security-Media.html Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJQvJUoAAoJEKGX32tq4e9Wt6EL/RlMqaM/JaekUHEHC00+Lair 0sHafHIAIst/L5iwhSrPvBmA9cK9zAHx6SRkhYkZ0t6mDMv3OfPLhk2UZ+tGqT+h KTHmskPLBM5OQtxB5R83BM1ivbv/Nt7+kCu2dF36sLnCca5jg/9l2A8QntOmBgZO yUx0VNiEIAldq831Lkrtmf8LEqu569FjZyL4NPvEl6mfmthtLpYf4qZVPKVNC7m0 QkhDVfmVfUXudR0ILBRhnKPicUgW/sNO9IHYRrheh8HD7g3TaWSgs+o5RxjqCpLO Mtc6UAwitRK1mBhkNMFjkhTR5/hfMndgBPCl9byEXgM/D1DflxpS8mVSrkU0SWNo QveiXmUBf9OnpuQCAndLGiY7f+4pN0yejsazaGS6TYawGT3gM7Gn2ftf13gcbJP4 6tq755+scCor2q5+GYTeIM6ocDNluCdgQlH0YLGbODiXY0kS++C5UrvfD+fgPzZq PCU1Cjl21mvO65nN1+UYOa3B3Pt9Bhq8BHkl6CFwdQ== =9xUN -----END PGP SIGNATURE----- From mwood at IUPUI.Edu Mon Dec 3 15:43:25 2012 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 3 Dec 2012 09:43:25 -0500 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBA8C6.3050409@gmail.com> References: <50BBA8C6.3050409@gmail.com> Message-ID: <20121203144325.GB7555@IUPUI.Edu> Not to discount the value of media with built-in encryption hardware, but...maybe you should also try the same methods as secure couriers in the movies: attach the USB drive to a cord or chain clamped to your wrist, so that it can't leave you without your knowledge. You can probably adapt a simple, cheap lanyard made for carrying thumb drives. Losing control of your information is bad, but so is losing your work and your valuable equipment. Combining high- and low-tech measures seems appropriate. Of course there's also the lowest tech of all: designate a secure place (a buttoned-flapped or zipped pocket, for example, or even a money belt or a traveller's concealed document shoulder pouch) in which you will carry the medium, and write out a checklist to make certain that you've followed your procedure. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu There's an app for that: your browser -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From vedaal at nym.hush.com Mon Dec 3 17:05:44 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 03 Dec 2012 11:05:44 -0500 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBA8C6.3050409@gmail.com> Message-ID: <20121203160545.1B9A410E2C8@smtp.hushmail.com> On Sunday, December 02, 2012 at 3:16 PM, "Richard H?chenberger" wrote: >I was wondering whether there are USB flash memory devices >available that support some kind of hardware encryption, i.e. maybe some USB >key with a keypad, which only exposes a (transparently) decrypted >filesystem to the host computer. > >I am using Linux, OS X, and Windows. > >Do you have any thoughts and recommendations on this issue? ===== have never used any hardware encrypted USB, but here is a workaround you might find helpful: [1] Instead of encrypting the entire USB, put several truecrypt voulmes on the USB, and leave a good amount of empty space on the USB , (e.g. 4 gig) , that you don't use for anything but the files you want to print or scan. [2] Burn a dvd of *UPR with TAILS*. (Ubuntu Privacy Remix with The Amnesic Incognito Live System) https://www.privacy-cd.org/en (It's available directly as an burn-ready iso image.) This uses a modified bootable run-from-dvd version of Unbuntu 10.x (UPR calls it 'Locked Lynx' ), which has Truecrypt and GnuPG 1.4.10 installed on it. It also has a front end for gnupg. Upon booting, it can mount whatever truecrypt files you want, and write/encrypt/decrypt directly into the truecrypt volume, or do any gnupg operations on any file on the USB itself. It has a 'wipe original' option, but am not sure what kind of 'wiping' is involved, but if your threat model is only some random person who may find the USB you lost in a public place, it might be sufficient for you. [3] Boot from the dvd, mount the truecrypt file that has whatever you want to print, and copy it to the empty space in the USB [4] Reboot from your work computer and print the files you want, and scan whatever you want into the empty space on the USB. [5] Reboot from the dvd, mount the truecypt volume and copy everything back into the truecrypt volume. [5] Encrypt and Wipe the files left on the empty space on the USB, (encrypting into the truecrypt volume, and wiping the files on the non-truecrypt space on the USB), dismount the truecrypt volume and shut down. n.b Some quirks on the UPR-TAILS system: [1] The gnupg front end does not have a conventional encryption option, so it needs a key to encrypt to. (You can import your own, but it's simpler and safer to just let the front end generate one for you, since you are mainly interested in the 'wipe original' option. You don't need to save the key, and it's simple enough to generate one key each time you need to use the system.) [2] The front-end keeps the passphrase for the key in memory for the entire time the system is booted. (I haven't found any way to set a time for it or turn it off). Working from the commandline 1.4.10 doesn't keep the passphrase in memory, and works pretty much as expected, but doesn't have the 'wipe' option. [3] The size of the UPR-TAILS system is 'just a little bit bigger' than a pocket size mini-dvd, and needs to be burned to a full-size dvd. [4] The truecrypt volume doesn't dismount from the ordinary truecrypt window, but needs to be right-clicked on in the ubuntu file browser, and dismounted from the truecrypt option in the right-click drop down menu. hth, vedaal From jhs at berklix.com Mon Dec 3 18:01:00 2012 From: jhs at berklix.com (Julian H. Stacey) Date: Mon, 03 Dec 2012 18:01:00 +0100 Subject: OT: USB key with hardware encryption? In-Reply-To: Your message "Mon, 03 Dec 2012 11:05:44 EST." <20121203160545.1B9A410E2C8@smtp.hushmail.com> Message-ID: <201212031701.qB3H10Of092689@fire.js.berklix.net> > [1] Instead of encrypting the entire USB, put several truecrypt voulmes on the USB, and leave a good amount of empty space on the USB , (e.g. 4 gig) , that you don't use for anything but the files you want to print or scan. Yes, USB Sticks all get sold with an MBR, but few end users seem to re-partition with Fdisk (or other), On an 8G stick on a key ring (thus risk of loss) I have: 1 G DOS FS, empty, first partition to make it easy for import/export when visiting, eg would be seen by OP's scanner at work) 4 G Bootable OS (FreeBSD), for rescuing other PCs, & running from live. 3 G Crypted file system with private data. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. From sks-devel-phil at spodhuis.org Mon Dec 3 01:59:58 2012 From: sks-devel-phil at spodhuis.org (Phil Pennock) Date: Sun, 2 Dec 2012 19:59:58 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> Message-ID: <20121203005958.GA82072@redoubt.spodhuis.org> On 2012-12-02 at 10:23 -0500, David Shaw wrote: > On Oct 6, 2012, at 10:20 PM, Phil Pennock wrote: > > GnuPG folks (since this is cross-posted, if my mail makes it through): > > > > there is a bug in GnuPG's SRV handling, I've identified where I think > > it is, it's in the second block of text from me; the first part of this > > mail relates to SKS and some policy issues around the new keyserver > > pool Kristian has added. > > Somehow I didn't notice this mail when it originally came through. Anyway, thanks for the report. Clearly the port supplied in the SRV should be honored. > > Can you try the attached patch (against 2.0)? Might be a sleep issue, but I'm having trouble persuading gpg2 to use gpgkeys_hkp instead of gpgkeys_curl, or even telling them apart from "--keyserver-options debug,verbose" output. I'm going to bail and grab coffee, but here's what I have for testing, which should make it easy for you to test too. For testing, I have: keyserver.spodhuis.org: A, AAAA, and SRV records _pgpkey-http/_pgpkey-https keytest.spodhuis.org: just the SRV records, pointing to keyserver.spodhuis.org all on non-standard ports: ----------------------------8< cut here >8------------------------------ keyserver IN A 94.142.241.93 keyserver IN AAAA 2a02:898:31:0:48:4558:73:6b73 _pgpkey-http._tcp.keyserver IN SRV 10 10 11374 keyserver _pgpkey-https._tcp.keyserver IN SRV 10 10 11373 keyserver _pgpkey-http._tcp.keytest IN SRV 10 10 11374 keyserver _pgpkey-https._tcp.keytest IN SRV 10 10 11373 keyserver ----------------------------8< cut here >8------------------------------ There is a proxy (nginx) listening on both ports, it will insert a correct identifying Via: header to confirm from the server-side which port was used, and the cert presented on 11373 is my normal cert, which should match names. You can grab the CA from: https://www.security.spodhuis.org/CA/globnixCA3.crt for use as --keyserver-options ca-cert-file=/.../globnixCA3.crt ----------------------------8< cut here >8------------------------------ % ls -ld =gpg2 -r-xr-xr-x 1 root wheel 685696 Dec 2 19:33 /usr/local/bin/gpg2 % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = GnuPG curl-shim Host: keytest.spodhuis.org Command: GET * HTTP proxy is "null" * HTTP URL is "http://keytest.spodhuis.org:11371/pks/lookup?op=get&options=mr&search=0x403043153903637F" * HTTP auth is "null" * HTTP method is GET gpg: key 0x403043153903637F: "Phil Pennock " not changed gpg: Total number processed: 1 gpg: unchanged: 1 ----------------------------8< cut here >8------------------------------ Yeah, I installed the patched version as the system gpg2. I built with FreeBSD Ports, which has gnupg-2.0.19, by doing: make patch patch -p1 <~/bug1446.patch make make FORCE_PKG_REGISTER=t install What am I doing wrong? Thanks, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From sks-devel-phil at spodhuis.org Mon Dec 3 07:01:07 2012 From: sks-devel-phil at spodhuis.org (Phil Pennock) Date: Mon, 3 Dec 2012 01:01:07 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> Message-ID: <20121203060107.GA17530@redoubt.spodhuis.org> On 2012-12-02 at 23:46 -0500, David Shaw wrote: > I tried talking to keytest.spodhuis.org to test, but all the ports > returned in the SRV were not listening. Or at least, not listening to > me ;) *blush* Fixed, sorry. -Phil From sks-devel-phil at spodhuis.org Mon Dec 3 08:00:47 2012 From: sks-devel-phil at spodhuis.org (Phil Pennock) Date: Mon, 3 Dec 2012 02:00:47 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> Message-ID: <20121203070047.GA29068@redoubt.spodhuis.org> On 2012-12-02 at 23:46 -0500, David Shaw wrote: > Hmm. Were you intending to test with the internal HTTP support or > with libcurl? You're currently built with internal support: Ah. I couldn't tell, since the helper binaries are installed and nothing explicitly said so. I used whatever FreeBSD Ports created by default. Looking at the Makefile, looks as though FreeBSD has a sense inversion in the curl option test for gnupg (2). If you build with the CURL option set, as it will be by default, then instead of "Use the real curl library (worked around if no)" Ports passes --without-libcurl to GnuPG2's build. Turned _off_ that option and gpg2keys_hkp gains a lot more link dependencies. > > gpgkeys: curl version = GnuPG curl-shim > > Looking at the internal support, it seems not to work on platforms > with getaddrinfo(), which is odd as that part works in the 1.4 code. > Anyway, try the attached patch in addition to the original one, and > you should hopefully have better results. Looks like the internal support still isn't working, but the external is picking up the port (and visibly sending the DNS-derived hostname). I've also just generated a new TLS cert for keytest.spodhuis.org, so that you get different certs for keytest.spodhuis.org (SRV-only DNS) and keyserver.spodhuis.org (SRV and A/AAAA records, the address records being used for keytest). Built with CURL set (so --without-libcurl): ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = GnuPG curl-shim Host: keytest.spodhuis.org Command: GET * HTTP proxy is "null" * HTTP URL is "http://keytest.spodhuis.org:11371/pks/lookup?op=get&options=mr&search=0x403043153903637F" * HTTP auth is "null" * HTTP method is GET gpg: key 0x403043153903637F: "Phil Pennock " not changed gpg: Total number processed: 1 gpg: unchanged: 1 ----------------------------8< cut here >8------------------------------ Built after switching the option to get the curl dependency: ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22 libssh2/1.4.1 librtmp/2.3 Host: keyserver.spodhuis.org Port: 11374 Command: GET * About to connect() to keyserver.spodhuis.org port 11374 (#0) * Trying 2a02:898:31:0:48:4558:73:6b73... * connected * Connected to keyserver.spodhuis.org (2a02:898:31:0:48:4558:73:6b73) port 11374 (#0) > GET /pks/lookup?op=get&options=mr&search=0x403043153903637F HTTP/1.1 Host: keyserver.spodhuis.org:11374 Accept: */* Pragma: no-cache Cache-Control: no-cache * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < Date: Mon, 03 Dec 2012 06:58:47 GMT < Content-Type: application/pgp-keys; charset=UTF-8 < Content-Length: 63475 < Connection: keep-alive < Server: sks_www/1.1.4 < Cache-Control: no-cache < Pragma: no-cache < Expires: 0 < X-HKP-Results-Count: 1 < Content-disposition: attachment; filename=gpgkey.asc < Via: 1.1 keyserver.spodhuis.org:11374 (nginx) < * Connection #0 to host keyserver.spodhuis.org left intact * Closing connection #0 gpg: key 0x403043153903637F: "Phil Pennock " not changed gpg: Total number processed: 1 gpg: unchanged: 1 ----------------------------8< cut here >8------------------------------ From c1.android at niftybox.net Mon Dec 3 07:25:41 2012 From: c1.android at niftybox.net (Miron (devrandom)) Date: Mon, 3 Dec 2012 06:25:41 +0000 (UTC) Subject: [guardian-dev] WOT and Authentication Research In-Reply-To: Message-ID: <1307183778.67.1354515941152.JavaMail.root@i3.hyper.to> Hi Patrick, Have you seen EFF's Sovereign Keys project? It attempts to establish a distributed single-mapping database of cert <-> domain. Also see the schemes in https://en.bitcoin.it/wiki/BIP_0015, altough they create new handles rather than try to capture existing ones. From patch at cs.ucsb.edu Tue Dec 4 00:55:40 2012 From: patch at cs.ucsb.edu (Patrick Baxter) Date: Mon, 3 Dec 2012 15:55:40 -0800 Subject: [guardian-dev] WOT and Authentication Research In-Reply-To: <1307183778.67.1354515941152.JavaMail.root@i3.hyper.to> References: <1307183778.67.1354515941152.JavaMail.root@i3.hyper.to> Message-ID: Yup, Sovereign Keys is awesome. I hadn't looked it up since thinking more about the importance of having a single mapping but on a quick re-read I understand it as follows: Sovereign keys has a very strict requirement for changing this mapping as domain names should. ie. Only a key revocation can change the mapping, and thus, a simple append only structure works great. If domain operator loses control for their domain name, they can revoke their key. This works as long as each party is trusted to never lose access to both their key AND revoke cert. You are also relying on these keyservers to establish validity of domain names through possibly DNSSEC and existing CAs. I'm OK with this and would gladly use it over the CA system and this would be an excellent start. I think you might be able to do more, but its up for debate. DNS is unique compared to common user-user authentications in that it is one-way authentication. A user validates a key for a TLS connection, but the TLS connection doesn't care what identity connects to it. Using a WOT between DNS owners and user keys could be used to find valid paths, but since the keyservers in this case already plan to maintain a fairly exhaustive list of domain names, it might not be that valuable. Particularly, because users don't have any meaningful way to capture strong validity of a Domain owners key ( maybe if they know the admin who captures verification with people he knows through ZTRP...) Although you could allow users to publish a special type of signature for every site they visit. It wouldn't establish validity, but you could see if their is a consenus among what users are seeing when they visit a website. Now you have a consensus on network perspectives. This could be used to prune any initial bad seeds in the mapping. If Google is seen all over the world as having cert X but the newly installed keyservers say its Y, I'm likely to believe the massive network perspective. One question I have about Sovereign Keys: 1) It might be an easy assumption to make that a small subset of domain admins might lose access to their revoke certificate and private key. How can they appeal this? If this append only structure is *absolutely* immutable in its mappings without a revocation cert, then they shouldn't be able to use DNSSEC or a CA to re-establish a mapping. Some resolution protocol is needed to not lock a domain out of all future TLS communication. The doc suggests just using extreme caution in preventing this. Storing revoke certs in key-escrow and things like this. Maybe this is a good/necessary security trade off? I'd like to see this enforcement of a single mapping applicable to each domain in a way that makes sense, I tend to agree that a WOT wouldn't make much sense for DNS, but I think it adds a lot of value for mediums with user-to-user interaction. So, ideally, you have a trusted set of keyservers to which you have somewhat sercurly bootstrapped (and pinned) keys to talk with. You trust them to be responsible in establishing single mappings in a way that balances the ability to change mappings with the ability to prevent malicious or bad mappings from being populated. You rely on a WOT built through user interaction to provide independent validity beyond "mapping exists on keyserver". A question I'm not sure about here though is: For a keyserver that is establishing mappings, what happens when someone in the mapping publishes a bad signature (ie a signature to a mapping that is not considered the standard)? Maybe keep track of these signatures, but don't present them for validation. This way you can have a reference count of what the communitiy is seeing as the mapping in real-ilfe. Again, this is the idea of consensus around a mapping. So I guess the point is that any project like convergence.io/tack.io and Soverign Keys that forces domain name owners to establish their own keys is a huge step in the right direction. I like the Soveirgn Keys approach of establishing a set of keyservers that check each other. Convergence captures network perspectives. Combine them? Also, I really like the idea of failing back to an .onion address of the public key in the presence of a MITM. Also, I just realized that when I've been trying to separate the different characteristics of email authentication vs domain authentication and referring to them as 'communication domains' for lack of a better reason. This is confusing. All the accounts are addressable by domain names. The difference is that an email account is a personal account separately authenticated that is just addressed with and @domain.tld. Its uniqueness is guaranteed by the provider and not the domain registration system. Overall, the separation of mappings is based on the communication medium that needs authentication. On Sun, Dec 2, 2012 at 10:25 PM, Miron (devrandom) wrote: > Hi Patrick, > > Have you seen EFF's Sovereign Keys project? It attempts to establish a distributed single-mapping database of cert <-> domain. > > Also see the schemes in https://en.bitcoin.it/wiki/BIP_0015, altough they create new handles rather than try to capture existing ones. From rjh at sixdemonbag.org Tue Dec 4 02:23:47 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 03 Dec 2012 20:23:47 -0500 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: <50B92E30.1000902@yahoo.de> References: <50B92E30.1000902@yahoo.de> Message-ID: <50BD50A3.107@sixdemonbag.org> On 11/30/2012 05:07 PM, Ben Staude wrote: > I'm thinking about a scenario for remote backup with gpg-encrypted files > (--symmetric, one by one). In addition to encrypting the files contents, > I'd like to hide their names also. There isn't enough entropy in a filename for an MD5 checksum to give much in the way of secrecy. From hka at qbs.com.pl Tue Dec 4 13:19:11 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 04 Dec 2012 13:19:11 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: <4887283.ocuTOb2Q7p@inno> References: <4887283.ocuTOb2Q7p@inno> Message-ID: <4442664.DNLrdXjRQU@k85hala03> On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: > Hello, > > are there arguments for preferring either > > a) having one RSA subkey for decryption only and one for signing only > > or > > b) having only one RSA subkey for both decryption and signing? > > Do any problems arise with the smartcard if the same key shall do different > tasks? Keys can become "used up" so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl From mailinglisten at hauke-laging.de Tue Dec 4 14:14:34 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 04 Dec 2012 14:14:34 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: <4442664.DNLrdXjRQU@k85hala03> References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> Message-ID: <1837262.AvDLrj7zKE@inno> Am Di 04.12.2012, 13:19:11 schrieb Hubert Kario: > Keys can become "used up" so it entirely depends on how often you use it. > > What I mean by that, is that any signing operation leaks some information > about the key used for signing (generally far less than few tens of a bit). > If you have signed tens of thousands of documents with it, an attacker can > recover substantial portion of the key and speed up the key recovery. I remembered having read something like that. But does this refer to signing only? Are decryption keys not affected by that? The advantage of separate subkeys would be then that the non-used up key could keep active longer. That may be an argument against signing emails by default ;-) or at least for longer signature keys. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From yyy at yyy.id.lv Tue Dec 4 13:40:22 2012 From: yyy at yyy.id.lv (yyy) Date: Tue, 4 Dec 2012 14:40:22 +0200 Subject: Is it safe to rename file.gpg to `md5sum file`? References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> Message-ID: <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> > There isn't enough entropy in a filename for an MD5 checksum to give > much in the way of secrecy. > It seems that MD5 checksum is computed from file contents, not name. From hka at qbs.com.pl Tue Dec 4 14:48:53 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 04 Dec 2012 14:48:53 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: <1837262.AvDLrj7zKE@inno> References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> <1837262.AvDLrj7zKE@inno> Message-ID: <1443905.6GMvM927sy@k85hala03> On Tuesday 04 of December 2012 14:14:34 Hauke Laging wrote: > Am Di 04.12.2012, 13:19:11 schrieb Hubert Kario: > > Keys can become "used up" so it entirely depends on how often you use it. > > > > What I mean by that, is that any signing operation leaks some information > > about the key used for signing (generally far less than few tens of a > > bit). > > If you have signed tens of thousands of documents with it, an attacker can > > recover substantial portion of the key and speed up the key recovery. > > I remembered having read something like that. But does this refer to signing > only? Are decryption keys not affected by that? The advantage of separate > subkeys would be then that the non-used up key could keep active longer. > That may be an argument against signing emails by default ;-) or at least > for longer signature keys. Leaking is caused by signing, if your using the same key for signing and encryption, then you can use the signatures to speed up the attack on encryption. If you're encrypting with one key and signing with other then the encryption key doesn't need to be changed, as the encryption is done with public part anyway -- you don't leak any information that's not already avaiable to the attacker. Signature keys should be changed regularly, every few hundred thousand signatures or so. In typical business deployments you don't have users that send over three hundred signed e-mails a day, every day (including holidays), and the certificates are valid only for a year. So you don't go over the "few hundred thousand signatures" limit. It is something you should keep in mind when you're using GPG and send lot of e-mails, though -- it is easy to use the same key for many years... Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl From peter at digitalbrains.com Tue Dec 4 17:50:23 2012 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 04 Dec 2012 17:50:23 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: <4887283.ocuTOb2Q7p@inno> References: <4887283.ocuTOb2Q7p@inno> Message-ID: <50BE29CF.3060601@digitalbrains.com> RFC 4880 says this in the "Security Considerations" part: > * Many security protocol designers think that it is a bad idea to use > a single key for both privacy (encryption) and integrity > (signatures). In fact, this was one of the motivating forces > behind the V4 key format with separate signature and encryption > keys. If you as an implementer promote dual-use keys, you should > at least be aware of this controversy. Where's your question coming from? As a theoretical musing, it's interesting. In practice, I don't see why you would ever create a subkey with both capabilities set.[1] Also note that it is useful to keep around (and backup) an encryption subkey, to decrypt old stuff. A primary key is useful to backup as it collects certifications. But a signing subkey is not useful to keep around. You might want to refresh your signing subkey more often than your encryption key for that reason. Peter. [1] That doesn't mean there is no reason. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From nicholas.cole at gmail.com Tue Dec 4 17:07:26 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 4 Dec 2012 16:07:26 +0000 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: <4442664.DNLrdXjRQU@k85hala03> References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> Message-ID: On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: >> Hello, >> >> are there arguments for preferring either >> >> a) having one RSA subkey for decryption only and one for signing only >> >> or >> >> b) having only one RSA subkey for both decryption and signing? >> >> Do any problems arise with the smartcard if the same key shall do different >> tasks? > > Keys can become "used up" so it entirely depends on how often you use it. > > What I mean by that, is that any signing operation leaks some information > about the key used for signing (generally far less than few tens of a bit). > If you have signed tens of thousands of documents with it, an attacker can > recover substantial portion of the key and speed up the key recovery. Do you have a reference for this? I thought the major reason to use separate signing/encryption keys was that if a user could be persuaded to sign a chosen encrypted text with the same key, the decryption key would be revealed. http://security.stackexchange.com/questions/1806/why-should-one-not-use-the-same-asymmetric-key-for-encryption-as-they-do-for-sig I've never read before that a key could be "used up" in this way. From hka at qbs.com.pl Tue Dec 4 18:20:41 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 04 Dec 2012 18:20:41 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> Message-ID: <6577206.5pskrmAplR@k85hala03> On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: > On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: > > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: > >> Hello, > >> > >> are there arguments for preferring either > >> > >> a) having one RSA subkey for decryption only and one for signing only > >> > >> or > >> > >> b) having only one RSA subkey for both decryption and signing? > >> > >> Do any problems arise with the smartcard if the same key shall do > >> different > >> tasks? > > > > Keys can become "used up" so it entirely depends on how often you use it. > > > > What I mean by that, is that any signing operation leaks some information > > about the key used for signing (generally far less than few tens of a > > bit). > > If you have signed tens of thousands of documents with it, an attacker can > > recover substantial portion of the key and speed up the key recovery. > > Do you have a reference for this? I don't have one at hand and can't find one through quick googling. I'm not sure where I've got this info from, it may have been in Applied Cryptography. Basically anything I have to back this is the general recommendation for TSA used in SignServer: http://www.signserver.org/manual/complete.en.html#Limiting%20the%20number%20of%20signatures but unfortunately they don't provide any rationale for this either. Logically though, if you have a known function that takes two parameters, A and B. You know B, function's output and size of A, then provided enough pairs of B and output you theoretically can say something about A (as A is constant). Of course, this works only because RSA is reversible and you know A' -- the public part of key. The problem is defining "enough pairs", probably the 100000 I mentioned is quite conservative. On one hand, such a limit is hardly a problem for anybody but automatic systems (which can be easily configured to rotate keys), on the other hand, this attack was described as purely theoretical AFAICR. > I thought the major reason to use > separate signing/encryption keys was that if a user could be persuaded > to sign a chosen encrypted text with the same key, the decryption key > would be revealed. How do you propose an attacker could force me to sign data I already encrypted? In both cases (encryption, signature) I don't process the data itself but either its hash or random data used as key for symmetric cipher. I may be wrong here, but I'm quite sure such situation is simply impossible to happen with GPG or other standard protocols (S/MIME, PKCS) > http://security.stackexchange.com/questions/1806/why-should-one-not-use-the- > same-asymmetric-key-for-encryption-as-they-do-for-sig See CodesInChaos comment Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl From hka at qbs.com.pl Tue Dec 4 18:32:07 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 04 Dec 2012 18:32:07 +0100 Subject: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> Message-ID: <3257627.pkT02k9CjV@k85hala03> On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: > On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: > > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: > >> Do any problems arise with the smartcard if the same key shall do > >> different > >> tasks? > > > > Keys can become "used up" so it entirely depends on how often you use it. > > > > Do you have a reference for this? Sorry for double posting, here's some reference: http://security.stackexchange.com/a/18242/3306 Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl From nicholas.cole at gmail.com Tue Dec 4 20:11:18 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 4 Dec 2012 19:11:18 +0000 Subject: Fwd: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> <6577206.5pskrmAplR@k85hala03> Message-ID: Meant to post this to the list. Blame gmail. ---------- Forwarded message ---------- From: Nicholas Cole Date: Tue, Dec 4, 2012 at 7:10 PM Subject: Re: Seperate RSA subkeys for decryption and signing or one for both? To: Hubert Kario > How do you propose an attacker could force me to sign data I already > encrypted? I think the attack merely specifies a chosen text - but at any rate, the point is that there might be a system (eg. a badly designed time-stamping service) that might naively sign data supplied by an attacker, and in those cases having a signing and encryption key that are the same would be a Bad Idea. Note, though, that PGP 2.6.3 did use the same key for both; the attack is a (mostly) theoretical one. From nicholas.cole at gmail.com Tue Dec 4 20:12:03 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 4 Dec 2012 19:12:03 +0000 Subject: Fwd: Seperate RSA subkeys for decryption and signing or one for both? In-Reply-To: References: <4887283.ocuTOb2Q7p@inno> <4442664.DNLrdXjRQU@k85hala03> <3257627.pkT02k9CjV@k85hala03> Message-ID: On Tue, Dec 4, 2012 at 5:32 PM, Hubert Kario wrote: > On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: >> On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario wrote: >> > On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: >> >> Do any problems arise with the smartcard if the same key shall do >> >> different >> >> tasks? >> > >> > Keys can become "used up" so it entirely depends on how often you use it. >> > >> >> Do you have a reference for this? > > Sorry for double posting, here's some reference: > http://security.stackexchange.com/a/18242/3306 > Ah. That's an attack on the Hash function, not the key. And even then, it seems far too difficult to be realistic, assuming that I read it correctly and assuming it is correct! N From sben1783 at yahoo.de Tue Dec 4 21:03:51 2012 From: sben1783 at yahoo.de (sben1783) Date: Tue, 04 Dec 2012 21:03:51 +0100 Subject: Is it safe to rename file.gpg to `md5sum =?UTF-8?Q?file=60=3F?= In-Reply-To: <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> Message-ID: <04938f097706d750e1e1eae27c2010fa@sun> On Tue, 4 Dec 2012 14:40:22 +0200, "yyy" wrote: >> There isn't enough entropy in a filename for an MD5 checksum to give >> much in the way of secrecy. >> > > It seems that MD5 checksum is computed from file contents, not name. Yes, I meant to use the MD5 checksum of the original file, not its original name. I'm still interested whether this would be "insecure"? I found a discussion on this list in 2011, where user atom wrote: > just make sure you're hashing the file-NAME, not it's contents. > of course, if you don't lose your db, then there's nothing wrong > with hashing the contents, or even a counter or random string. > hashing > the file-NAME is just an idea that makes recovery of the db possible > if > you know the format and range of the file-names (and any secret that > may be used). the real trick is to just do something secure and > consistent... sha1 does the job. (http://www.mail-archive.com/gnupg-users at gnupg.org/msg15110.html) He states it's not a problem to hash the files contents, but it seems to be thought of no different than "counter and random string" - this are completely different things IMHO. And, by the way, how could the hash of a filename be used to reconstruct the filename (as atom says "... makes recovery of the db possible ...") There is no such thing as inverse-md5sum, is there? You'd still need "brute force" to find the original name? Thanks Ben From crypto at artemicode.de Tue Dec 4 22:14:34 2012 From: crypto at artemicode.de (Selene Feigl) Date: Tue, 04 Dec 2012 22:14:34 +0100 Subject: Keypad support for PC/SC card readers? In-Reply-To: <87hao330eh.fsf@vigenere.g10code.de> References: <50BA32E4.4070302@artemicode.de> <16527463.zXm0jXBUG8@inno> <50BA7AE5.8080302@artemicode.de> <4256837.J9hvIsBDl6@inno> <50BB2607.4040107@artemicode.de> <87hao330eh.fsf@vigenere.g10code.de> Message-ID: <50BE67BA.5040802@artemicode.de> Hello I trid it with gnupg 2.0.19-1 from debian testing - PIN is not requested from the card reader. here is the log file. I did use testing keys and non-productive PIN so I hope I did not post anything sensitive 2012-12-04 22:05:10 scdaemon[16008] listening on socket `/tmp/gpg-iJ5FQq/S.scdaemon' 2012-12-04 22:05:10 scdaemon[16008] handler for fd -1 started 2012-12-04 22:05:11 scdaemon[16008] reader slot 0: not connected 2012-12-04 22:05:11 scdaemon[16008] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=6B00 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 4F 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=16 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:11 scdaemon[16008] AID: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 5F 52 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=10 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:11 scdaemon[16008] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 C4 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=7 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 00 20 20 20 03 00 03 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 5E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 2012-12-04 22:05:11 scdaemon[16008] Version-2 ......: yes 2012-12-04 22:05:11 scdaemon[16008] Get-Challenge ..: yes (2048 bytes max) 2012-12-04 22:05:11 scdaemon[16008] Key-Import .....: yes 2012-12-04 22:05:11 scdaemon[16008] Change-Force-PW1: yes 2012-12-04 22:05:11 scdaemon[16008] Private-DOs ....: yes 2012-12-04 22:05:11 scdaemon[16008] Algo-Attr-Change: yes 2012-12-04 22:05:11 scdaemon[16008] SM-Support .....: no 2012-12-04 22:05:11 scdaemon[16008] Max-Cert3-Len ..: 2048 2012-12-04 22:05:11 scdaemon[16008] Max-Cmd-Data ...: 2048 2012-12-04 22:05:11 scdaemon[16008] Max-Rsp-Data ...: 2048 2012-12-04 22:05:11 scdaemon[16008] Cmd-Chaining ...: no 2012-12-04 22:05:11 scdaemon[16008] Ext-Lc-Le ......: yes 2012-12-04 22:05:11 scdaemon[16008] Status Indicator: 05 2012-12-04 22:05:11 scdaemon[16008] GnuPG-No-Sync ..: no 2012-12-04 22:05:11 scdaemon[16008] GnuPG-Def-PW2 ..: no 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] Key-Attr-sign ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] Key-Attr-encr ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] Key-Attr-auth ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 7A 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=5 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 93 03 00 00 06 2012-12-04 22:05:11 scdaemon[16008] signatures created so far: 6 2012-12-04 22:05:11 scdaemon[16008] DBG: asking for PIN '||Please enter the PIN%0A[sigs done: 6]' 2012-12-04 22:05:12 scdaemon[16008] updating slot 0 status: 0x0000->0x0007 (0->1) 2012-12-04 22:05:14 scdaemon[16008] DBG: send apdu: c=00 i=20 p1=00 p2=81 lc=6 le=-1 em=0 2012-12-04 22:05:14 scdaemon[16008] DBG: PCSC_data: 00 20 00 81 06 31 32 33 34 35 36 2012-12-04 22:05:14 scdaemon[16008] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:14 scdaemon[16008] DBG: dump: 2012-12-04 22:05:14 scdaemon[16008] DBG: send apdu: c=00 i=2A p1=9E p2=9A lc=35 le=2048 em=1 2012-12-04 22:05:14 scdaemon[16008] DBG: PCSC_data: 00 2A 9E 9A 00 00 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 B7 01 33 13 E8 72 8F 69 DA B0 45 DD 7D 12 97 06 D9 08 6A F5 08 00 2012-12-04 22:05:15 scdaemon[16008] DBG: response: sw=9000 datalen=256 2012-12-04 22:05:15 scdaemon[16008] DBG: dump: 0A 7E BA B2 13 CB 3B D9 1D AE 2D 7D C5 E3 AA 88 6D AA 28 46 EE 09 64 A4 67 99 2D 2C 49 CA D0 E7 19 C1 F9 BF D5 A0 A3 9F 7A AB 6D 6B E4 CA B7 98 7E 6D DF E7 09 3D DC A9 34 F9 32 54 AB A5 D0 35 D4 69 C6 61 2F F2 8E 31 99 8D DA F5 D7 16 63 B4 59 C2 F0 DB E2 F4 32 C0 9F EA A2 27 16 96 29 58 66 DC 4A 36 28 CA A4 5F 0D 54 38 89 88 E7 EB 65 34 3E A9 9D 4F 29 48 D7 D7 AC 63 A1 27 31 52 2A 80 99 80 66 3F 53 56 44 40 CE C5 FF 66 5E FD 2B E5 03 6B 8E 45 F1 5D F6 B6 F0 74 FA 6B C7 54 AA D1 97 C7 F1 4C 8D D7 10 10 69 4F 13 78 D4 1D 96 E9 C7 2E 38 23 56 FA F0 2B 9B 4F ED 6C 35 87 93 29 E0 76 0A B5 E8 E4 11 B3 CD F2 DD EF 96 24 73 7D 66 39 E4 79 B1 3B 6B DD 78 14 52 AA DC F0 73 4F B4 A6 1A D5 36 44 46 C2 2B EA CA FB 17 ED D8 C0 DC DC E0 1A AC FB 10 06 02 72 D7 F4 F8 CB 2F 2012-12-04 22:05:15 scdaemon[16008] operation sign result: Success 2012-12-04 22:05:15 scdaemon[16008] handler for fd -1 terminated 2012-12-04 22:05:15 scdaemon[16008] scdaemon (GnuPG) 2.0.19 stopped 2012-12-04 22:05:27 scdaemon[16016] listening on socket `/tmp/gpg-U4sYi6/S.scdaemon' 2012-12-04 22:05:27 scdaemon[16016] handler for fd -1 started 2012-12-04 22:05:28 scdaemon[16016] reader slot 0: not connected 2012-12-04 22:05:28 scdaemon[16016] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=6B00 datalen=0 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 4F 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=16 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:28 scdaemon[16016] AID: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 5F 52 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=10 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:28 scdaemon[16016] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 C4 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=7 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 00 20 20 20 03 00 03 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 5E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 2012-12-04 22:05:28 scdaemon[16016] Version-2 ......: yes 2012-12-04 22:05:28 scdaemon[16016] Get-Challenge ..: yes (2048 bytes max) 2012-12-04 22:05:28 scdaemon[16016] Key-Import .....: yes 2012-12-04 22:05:28 scdaemon[16016] Change-Force-PW1: yes 2012-12-04 22:05:28 scdaemon[16016] Private-DOs ....: yes 2012-12-04 22:05:28 scdaemon[16016] Algo-Attr-Change: yes 2012-12-04 22:05:28 scdaemon[16016] SM-Support .....: no 2012-12-04 22:05:28 scdaemon[16016] Max-Cert3-Len ..: 2048 2012-12-04 22:05:28 scdaemon[16016] Max-Cmd-Data ...: 2048 2012-12-04 22:05:28 scdaemon[16016] Max-Rsp-Data ...: 2048 2012-12-04 22:05:28 scdaemon[16016] Cmd-Chaining ...: no 2012-12-04 22:05:28 scdaemon[16016] Ext-Lc-Le ......: yes 2012-12-04 22:05:28 scdaemon[16016] Status Indicator: 05 2012-12-04 22:05:28 scdaemon[16016] GnuPG-No-Sync ..: no 2012-12-04 22:05:28 scdaemon[16016] GnuPG-Def-PW2 ..: no 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:28 scdaemon[16016] Key-Attr-sign ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:28 scdaemon[16016] Key-Attr-encr ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:28 scdaemon[16016] Key-Attr-auth ..: RSA, n=2048, e=32, fmt=std 2012-12-04 22:05:28 scdaemon[16016] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:28 scdaemon[16016] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:28 scdaemon[16016] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:28 scdaemon[16016] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:28 scdaemon[16016] DBG: asking for PIN '||Please enter the PIN' 2012-12-04 22:05:29 scdaemon[16016] updating slot 0 status: 0x0000->0x0007 (0->1) 2012-12-04 22:05:31 scdaemon[16016] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=6 le=-1 em=0 2012-12-04 22:05:31 scdaemon[16016] DBG: PCSC_data: 00 20 00 82 06 31 32 33 34 35 36 2012-12-04 22:05:31 scdaemon[16016] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:31 scdaemon[16016] DBG: dump: 2012-12-04 22:05:31 scdaemon[16016] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=257 le=2048 em=1 2012-12-04 22:05:31 scdaemon[16016] DBG: PCSC_data: 00 2A 80 86 00 01 01 00 70 51 0F 0E 62 87 3E E1 BD F8 D1 AE EC D9 E8 1C CB B3 75 4E 92 7A 45 07 D9 26 98 DE A9 E0 02 95 DB C2 26 DE DD 53 C0 92 A1 83 FA 65 A9 B6 B2 3F 80 86 49 E2 9F D0 09 94 45 77 E6 1C 69 28 8F 75 C3 48 F5 C0 FE FC C2 33 3C C4 7D 76 73 9D 94 C8 81 C0 C5 B4 CE 2E 7C 2A 97 42 7D 78 98 39 B4 16 D7 34 1B 49 54 02 BE AE F6 0E BD 18 AC B7 19 10 D6 8C 5C 23 F6 AA 3C 02 5E 1B 20 62 C5 34 BC 0F B5 E4 74 6B CD AD 23 B8 6E EA AA 6C 47 B4 1D C0 20 41 D7 CB 78 5A A6 29 58 90 4B 2C 83 B1 2A 5A 07 DE DB 38 7C 4C 1E A8 A8 F1 FD 33 B5 EB 8A 2C 87 E5 D9 99 7D FE 4B 94 9A 55 1F B5 56 DA CD 22 72 91 3A B0 EC 46 3F 61 21 7E CE 6E 09 BB E5 CD 65 8C 82 C6 DD C0 EC 68 31 26 8D 4A BD 6E 9F 5D CC 35 C1 34 E9 F8 0F 00 80 64 97 8F 71 63 98 69 B0 5D 7E 31 0E 83 C2 49 12 2D 83 D6 B3 EF 9F B5 08 00 2012-12-04 22:05:32 scdaemon[16016] DBG: response: sw=9000 datalen=35 2012-12-04 22:05:32 scdaemon[16016] DBG: dump: 09 E6 14 B1 DA 9B A4 AF 78 01 4A FD 56 F9 2F 05 D1 F0 C4 8E 88 AB 69 CC AD AD 25 9D 4F D7 A4 D2 2B 12 14 2012-12-04 22:05:32 scdaemon[16016] operation decipher result: Success 2012-12-04 22:05:32 scdaemon[16016] handler for fd -1 terminated 2012-12-04 22:05:32 scdaemon[16016] scdaemon (GnuPG) 2.0.19 stoppe Greetings Selene Feigl Am 03.12.2012 11:17, schrieb Werner Koch: > On Sun, 2 Dec 2012 10:57, crypto at artemicode.de said: > >> I suppose gnupg tries to detect whether a keypad is available. Is that >> logged? Which debugging level would be needed. > > 2.0.19 has support for keypads via PC/SC. Add this to > ~/.gnupg/scdaemon.conf > > log-file /some/file > debug 2048 > > > > Shalom-Salam, > > Werner > From allen.schultz at gmail.com Tue Dec 4 22:18:15 2012 From: allen.schultz at gmail.com (Allen Schultz) Date: Tue, 04 Dec 2012 14:18:15 -0700 Subject: Seperate Master Key and signing/encrypting subkeys method Message-ID: <50BE6897.3080903@gmail.com> GnuPG-Users: I was wondering where that article was about seperating the master key from daily subkeys (both signing and encrypting). I can't seem to find it. Are there other articles on the similar methodologies that are still secure. And is it still recommended that I sign another's keys with the master signing key? Thanks in advance. Allen Schultz -------------- next part -------------- A non-text attachment was scrubbed... Name: allen_schultz.vcf Type: text/x-vcard Size: 172 bytes Desc: not available URL: From faramir.cl at gmail.com Wed Dec 5 00:56:50 2012 From: faramir.cl at gmail.com (Faramir) Date: Tue, 04 Dec 2012 20:56:50 -0300 Subject: Seperate Master Key and signing/encrypting subkeys method In-Reply-To: <50BE6897.3080903@gmail.com> References: <50BE6897.3080903@gmail.com> Message-ID: <50BE8DC2.3080407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 04-12-2012 18:18, Allen Schultz escribi?: > GnuPG-Users: > > I was wondering where that article was about seperating the master > key from daily subkeys (both signing and encrypting). I can't seem > to find it. Are there other articles on the similar methodologies > that are still I can't find it now, but found this: http://www.mentby.com/Group/gnupg-users/offline-primary-key.html It lacks the screen captures, but has the juicy information required to do it. > secure. And is it still recommended that I sign another's keys > with the master signing key? The master key is the only key that can sign other keys, and yes, your sub-keys must be signed by your master key (it is done automatically), if not, somebody can add rogue keys. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQvo3CAAoJEMV4f6PvczxA/MIH/AhYMkfT07fCqu6denLuSwQ6 O0+TE6KDFqOQazTiBB3B5Iy8w5xAnuUaqeRiP9uce+q2Kf12at2aOUNjvzDXBRTK DYDy48WBLXIs3E+FEAbagBUbqqNdJiGQV7EpbICVUxcGJRxHmCKs03tYB0yRS1O3 LNehI02WGKi5wS4TSyq6bmp3nvGJEjLXKnwqCDNi++YCW5yUyNtvvx0mD9BQSZg9 oaUq5wxM9Gk1gzzFlomR80y1GBgsop4dM4jqqv1PdrfM/b4BD3CMeqZRWa22BUUj IxNFKcswYnmxZyDYiOrpQT/Yl3A2DRBJSBOE4G4OMAOdRzf80ey/AQyOn4CVV50= =InEO -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 5 07:20:28 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 05 Dec 2012 01:20:28 -0500 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: <04938f097706d750e1e1eae27c2010fa@sun> References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> Message-ID: <50BEE7AC.6060203@sixdemonbag.org> On 12/4/2012 3:03 PM, sben1783 wrote: > Yes, I meant to use the MD5 checksum of the original file, not its > original name. I'm still interested whether this would be "insecure"? Let's not even use the word insecure, since that word is wholly subjective: there's no agreed-upon definition for what it means. Instead, let me ask a different question: what, precisely, are you trying to accomplish? > And, by the way, how could the hash of a filename be used to reconstruct > the filename (as atom says "... makes recovery of the db possible ...") > There is no such thing as inverse-md5sum, is there? You'd still need > "brute force" to find the original name? Sure, of course there's inverse-md5sum -- after a fashion. Many files bear names that are just a couple of short words: "Tuesday report.doc", for instance. So you go through a dictionary and compile a list of every one and two--word filename, separating by underscores and spaces, and using the top 100 file extensions. There are about 5,000 words in common usage in English. (A native speaker will have a larger vocabulary, but you can get by quite well on 5,000 words.) Every possible one and two-word combo from this list would amount to about 25 million entries in the database: multiply by, say, four, to represent different conventions for capitalization and spacing and whatnot, brings you to 100 million. Multiply by the top 100 file extensions and you get 10 billion. Each of those records would require about 100 bytes of storage, or 1 trillion bytes. You could easily store it on a $100 hard drive. This is what's called a "dictionary attack." There are other much better ways to attack it: rainbow tables, for instance. But this is enough to show you that MD5 is nowhere near as hard to reverse as you might think. If you're creating filenames based on the MD5 hash of the entire file, that would be (probably) nontrivial to reverse: if you're creating filenames based on the MD5 hash of the original filename, you're playing with fire. That said: please don't use MD5. Please use a better, stronger hash algorithm like SHA-256, SHA-512 or SHA-3 instead. From burn.till.skid at gmail.com Wed Dec 5 13:11:25 2012 From: burn.till.skid at gmail.com (Oscar Pereira) Date: Wed, 5 Dec 2012 12:11:25 +0000 Subject: Seperate Master Key and signing/encrypting subkeys method In-Reply-To: <50BE6897.3080903@gmail.com> References: <50BE6897.3080903@gmail.com> Message-ID: Do you mean this: http://tjl73.altervista.org/secure_keygen/en/en.html It's the only document I know of that provides the information you wanted. On Tue, Dec 4, 2012 at 9:18 PM, Allen Schultz wrote: > > > Thanks in advance. From tanguy.herrmann at gmail.com Wed Dec 5 16:06:40 2012 From: tanguy.herrmann at gmail.com (Tanguy Herrmann) Date: Wed, 5 Dec 2012 16:06:40 +0100 Subject: Seperate Master Key and signing/encrypting subkeys method In-Reply-To: References: <50BE6897.3080903@gmail.com> Message-ID: Or there is this one : http://wiki.debian.org/subkeys On Wed, Dec 5, 2012 at 1:11 PM, Oscar Pereira wrote: > Do you mean this: http://tjl73.altervista.org/secure_keygen/en/en.html > > It's the only document I know of that provides the information you wanted. > > On Tue, Dec 4, 2012 at 9:18 PM, Allen Schultz > wrote: > > > > > > Thanks in advance. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxp at pdx.edu Wed Dec 5 18:59:20 2012 From: maxp at pdx.edu (Max Parmer) Date: Wed, 5 Dec 2012 09:59:20 -0800 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: <04938f097706d750e1e1eae27c2010fa@sun> References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> Message-ID: On Tue, Dec 4, 2012 at 12:03 PM, sben1783 wrote: > On Tue, 4 Dec 2012 14:40:22 +0200, "yyy" wrote: > >> There isn't enough entropy in a filename for an MD5 checksum to give >>> much in the way of secrecy. >>> >>> >> It seems that MD5 checksum is computed from file contents, not name. >> > > Yes, I meant to use the MD5 checksum of the original file, not its > original name. I'm still interested whether this would be "insecure"? > If by insecure you mean, "could lead to exposing the contents of the file" or "could reveal my passphrase" that would depend (in part) on the size and contents of the file (i.e. very short files would less time consuming to brute force, files with very regular formats would be quicker to brute force, etc.) and the symmetric cipher used. Revealing the plaintext of some files could be fairly significant with the default symmetric cipher for GPG is CAST-128 which is potentially subject to key recovery via a chosen plaintext attack. AES doesn't have any presently known vulnerability of that sort. If you just need a unique key to refer to the file, you're already storing the source path in the "summary" file your tool generates. If you just need a guaranteed unique identifier for each file (because, say, you're storing them all flatly in a single directory), I would just hash the path (which is apparently not sensitive data, as you seem to be storing it in plaintext in the summary file) as it's guaranteed to be unique per-system. If you just need file integrity checking, the algorithm more-or-less takes care of that. I wouldn't use the md5 hash of the file's contents, if the contents are sensitive. > I found a discussion on this list in 2011, where user atom wrote: > > just make sure you're hashing the file-NAME, not it's contents. >> of course, if you don't lose your db, then there's nothing wrong >> with hashing the contents, or even a counter or random string. hashing >> the file-NAME is just an idea that makes recovery of the db possible if >> you know the format and range of the file-names (and any secret that >> may be used). the real trick is to just do something secure and >> consistent... sha1 does the job. >> > > (http://www.mail-archive.com/**gnupg-users at gnupg.org/**msg15110.html > ) > > He states it's not a problem to hash the files contents, but it seems > to be thought of no different than "counter and random string" - this > are completely different things IMHO. > > And, by the way, how could the hash of a filename be used to reconstruct > the filename (as atom says "... makes recovery of the db possible ...") > There is no such thing as inverse-md5sum, is there? You'd still need > "brute force" to find the original name? > > Thanks > Ben > > > > ______________________________**_________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/**mailman/listinfo/gnupg-users > -- Max Parmer 5D99 D929 93FE EE79 1645 D77A D771 E875 20CB D918 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patch at cs.ucsb.edu Wed Dec 5 23:15:14 2012 From: patch at cs.ucsb.edu (Patrick Baxter) Date: Wed, 5 Dec 2012 14:15:14 -0800 Subject: WOT and Authentication Research In-Reply-To: References: Message-ID: On Tue, Dec 4, 2012 at 5:29 AM, Melvin Carvalho wrote: > > Not sure I've grokked everything in this thread, but some thoughts. > I'm working on the TL;DR version :). > Tying a key to a 'domain' (aka URI) is something that can be done already > using linked data. > > I do so on my home page already: > > http://melvincarvalho.com/ > > This contains my GPG key, fingerprint, hex_id, modulus and exponent. > > Here is the data view of the same page: > > http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F I'm not sure I understand what it is that ties your key to the domain. So, for example, you know your public key and it that it is the proper public key for your website. However, from an outsider's perspective, anyone could publish a signature and claim ownership of your domain. If they control the network path to a user first looking at your webpage, then there is no consensus on which public key will get you MITM'd and which is your actual key if they choose to present a different one. You add strength by making it available on your website, but it only goes so far. My general idea is somewhat encompassing of the Sovereign Keys idea, but thats just part of the solution. Generally, I'd argue, you want a keysever infrastructure similar to the EFF's soverign keys that establish's a known single mapping. It widely distributes the public keys to that keyserver with software so that you have a secure connection into that data from the start. Now, you have to balance the needs of updating this mapping with the security of the infrastructure. There is lots of ways to capture meaningful data on validity and I'm for using as many ways as possible such that it still makes sense. Also, keeping a database of personally validated keys is still massively useful for things like email, phone, and chat. It can be used in conjunction with a better key server infrastructure to minimize the trust you place on it. You could probably also argue that the less authority a key-server infrastructure has, the more resistant it is to corruption. This lends strength to trying to not entirely relying on it even if it is distributed and replicated. Now, the idea is that with this infrastructure you are restricted to how you learn about new keys. So an active attacker on your network connection will not find it so trivial present an fake key to users that are connecting for the first time. > Scroll down to see the PKI fields. > > I can use this key to sign and encrypt mail, for s/MIME as an x.509 > certificate, to login via ssh and also encrypted chat on retroshare > > I also have links to other people storing keys in a kind of web of trust. > > What you call the WOT is really a Graph of Trust (GOT) or Network of Trust > (NOT) in so far as the Web is normally loosely associated with HTTP. Maybe, I'm confusing the issue by trying to tie too many things together, but the I think the problems all have a lot of fundamental things in common. Also, If a user can link to you through a WOT, then they have that initial validity that creates a much strong authentication and don't have to trust the first key servered over the network. I think there is a ton more potential for more effectively using WOT paths to establish validity as well. > > I think in terms of accessibility and usability we need a GPG equivalent of > what "hotmail" did to email. This is what we call "webizing". Then people > can make relations, sign and encrypt, over the web just as easily as they do > with desktop clients. Obviously a huge task and the crypto in the browser > group will help. Definitely a massive undertaking and I think the most relevant problem to the world of crypto. It is getting better and more transparent (OTR ect.) and I think one of the last difficult tasks is making it easy for users with little knowledge to not only use crypto, but also be strongly authenticated. Its not terribly difficult to make an app that opportunistically establishes encryption, how do we make the user capture strong validity by default? I think, its in the form of better keyservers (users might need a little initial work to establish their key and prove they own their email for example) and signing keys automatically when you determine you have captured some sort of validity on that key (See ZRTP's authentication or the social millionaire protocol for OTR). And of course the last issue is finding a sane way for user's to store and use private keys. Hence the PSST project and the eventual idea of PGP smart card type computing devices. From sben1783 at yahoo.de Wed Dec 5 22:39:04 2012 From: sben1783 at yahoo.de (Ben Staude) Date: Wed, 05 Dec 2012 22:39:04 +0100 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> Message-ID: <50BFBEF8.6080203@yahoo.de> Am 05.12.2012 18:59, schrieb Max Parmer: > On Tue, Dec 4, 2012 at 12:03 PM, sben1783 wrote: >> Yes, I meant to use the MD5 checksum of the original file, not its >> original name. I'm still interested whether this would be "insecure"? > If by insecure you mean, "could lead to exposing the contents of the file" > or "could reveal my passphrase" that would depend (in part) on the size and > contents of the file (i.e. very short files would less time consuming to > brute force, files with very regular formats would be quicker to brute > force, etc.) and the symmetric cipher used. Yes, that's exactly what I meant with "insecure". So I learn from your statement to better not use the md5 hashes. > Revealing the plaintext of some files could be fairly significant with the > default symmetric cipher for GPG is CAST-128 which is potentially subject > to key recovery via a chosen plaintext attack. AES doesn't have any > presently known vulnerability of that sort. While browsing for recommandations on what algorithm to use, I didn't come across the "vulerability" you mention above. I don't really understand what you're saying, but anyway plan to use AES because it a) seems to be the algorithm "more state of the art" and b) uses MDC by default. > If you just need a unique key to refer to the file, you're already storing > the source path in the "summary" file your tool generates. If you just need > a guaranteed unique identifier for each file (because, say, you're storing > them all flatly in a single directory), I would just hash the path (which > is apparently not sensitive data, as you seem to be storing it in plaintext > in the summary file) as it's guaranteed to be unique per-system. Well I do *not* want to reveal my private paths/filenames in the remote backup location. I won't upload the summary file as plaintext, but maybe encrypted as contents.gpg or the like. So I need another identifier for each file and some sort of mapping. That's why I came up with the md5sum of the files contents in the first place - I already have the mapping table (the summary file). If that's no good idea, I will probably just use a GUID for each file and create a separate mapping table (which also won't get uploaded without encryption:) If I wanted to have a fallback for loosing the mapping table, would there be a sane way to encrypt the filename with gpg? That way I could decrypt it in case I loose the mapping table (which isn't possible with the GUID solution). I tried echo '/path/to/original/filename' | gpg --armor -c but the result contains newlines and slashes which isn't good for use as filenames. There's no option like "--armor-only-alphanumeric"...? Thank you very much Ben From maxp at pdx.edu Thu Dec 6 00:10:19 2012 From: maxp at pdx.edu (Max Parmer) Date: Wed, 5 Dec 2012 15:10:19 -0800 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: <50BFBEF8.6080203@yahoo.de> References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> <50BFBEF8.6080203@yahoo.de> Message-ID: On Wed, Dec 5, 2012 at 1:39 PM, Ben Staude wrote: > Am 05.12.2012 18:59, schrieb Max Parmer: > >> On Tue, Dec 4, 2012 at 12:03 PM, sben1783 wrote: >> >>> Yes, I meant to use the MD5 checksum of the original file, not its >>> original name. I'm still interested whether this would be "insecure"? >>> >> > If by insecure you mean, "could lead to exposing the contents of the file" >> or "could reveal my passphrase" that would depend (in part) on the size >> and >> contents of the file (i.e. very short files would less time consuming to >> brute force, files with very regular formats would be quicker to brute >> force, etc.) and the symmetric cipher used. >> > > Yes, that's exactly what I meant with "insecure". So I learn from your > statement to better not use the md5 hashes. > > > Revealing the plaintext of some files could be fairly significant with the >> default symmetric cipher for GPG is CAST-128 which is potentially subject >> to key recovery via a chosen plaintext attack. AES doesn't have any >> presently known vulnerability of that sort. >> > > While browsing for recommandations on what algorithm to use, I didn't come > across the "vulerability" you mention above. I don't really understand what > you're saying, but anyway plan to use AES because it a) seems to be the > algorithm "more state of the art" and b) uses MDC by default. Here's my cite on the CAST weakness: http://www.schneier.com/paper-relatedkey.html > If you just need a unique key to refer to the file, you're already storing >> the source path in the "summary" file your tool generates. If you just >> need >> a guaranteed unique identifier for each file (because, say, you're storing >> them all flatly in a single directory), I would just hash the path (which >> is apparently not sensitive data, as you seem to be storing it in >> plaintext >> in the summary file) as it's guaranteed to be unique per-system. >> > > Well I do *not* want to reveal my private paths/filenames in the remote > backup location. I won't upload the summary file as plaintext, but maybe > encrypted as contents.gpg or the like. So I need another identifier for > each file and some sort of mapping. That's why I came up with the md5sum of > the files contents in the first place - I already have the mapping table > (the summary file). If that's no good idea, I will probably just use a GUID > for each file and create a separate mapping table (which also won't get > uploaded without encryption:) > If you're going to encrypt the summary file then you can store anything as sensitive as the rest of your backup data in it... -- Max Parmer 5D99 D929 93FE EE79 1645 D77A D771 E875 20CB D918 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Dec 6 00:28:35 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 05 Dec 2012 18:28:35 -0500 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> <50BFBEF8.6080203@yahoo.de> Message-ID: <50BFD8A3.6080205@sixdemonbag.org> On 12/5/2012 6:10 PM, Max Parmer wrote: > Here's my cite on the CAST weakness: > http://www.schneier.com/paper-relatedkey.html This falls squarely into the range of theoretical breaks. Notice that the attack requires 2**17 chosen plaintexts to all be encrypted with the same symmetric key. Since GnuPG uses disposable session keys, this is pretty much completely irrelevant to GnuPG usage. From vedaal at nym.hush.com Thu Dec 6 01:07:15 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 05 Dec 2012 19:07:15 -0500 Subject: Is it safe to rename file.gpg to `md5sum file`? Message-ID: <20121206000715.76221E6739@smtp.hushmail.com> Ben Staude sben1783 at yahoo.de wrote on Wed Dec 5 22:39:04 CET 2012 : > Well I do *not* want to reveal my private paths/filenames in the remote backup location. I won't upload the summary file as plaintext, but maybe encrypted as contents.gpg or the like. So I need another identifier for each file and some sort of mapping. That's why I came up with the md5sum of the files contents in the first place - I already have the mapping table (the summary file). If that's no good idea, I will probably just use a GUID for each file and create a separate mapping table (which also won't get uploaded without encryption:) ===== If you don't mind *really. really long* entries ;-) in your re-naming table, you can do something like the following, and never have to worry about the mapping table getting lost. Encrypt the actual filename symmetrically, add the resulting ciphertext to the end of the file, and then save the resultant encrypted file with encrypted ciphertext as fn1.asc and the ciphertext of the filename in the mapping table for fn1.asc i.e. after doing gpg --cipher-algo AES256 -c -a real_filename resulting in something like: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (Cygwin) LONG/ASCII/Armored/CIPHERTEXT =checksum -----END PGP MESSAGE----- do $ printf "real_filename" | gpg --cipher-algo AES256 -c -a Resulting in -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (Cygwin) jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew= =Yv5u -----END PGP MESSAGE----- (passphrase; sss) Add the above ciphertext, with the header and footer intact, to the bottom of the ciphertext of the encrypted actual file, i.e. -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (Cygwin) LONG/ASCII/Armored/CIPHERTEXT =checksum -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (Cygwin) Comment: encrypted real filename of above encrypted file jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew= =Yv5u -----END PGP MESSAGE----- and save the whole thing as fn1.asc, and similarly, for the rest, as fn2.asc, fn3.asc, ... , fnn.asc . In your mapping table, fn1.asc would be jA0ECQMCMu4SzytLjoFg0kIBlWVEKygTWNEjNi/sc/Anvc10SokQC9X6k2GZz1py a+GzL+/HcUkg8P97d197FGyqpPghYMqEcp6CtYpn6zYkVew= =Yv5u If your mapping table ever gets lost, you can easily recover the filename by decrypting the added ciphertext at the end of each encrypted file. vedaal From dshaw at jabberwocky.com Thu Dec 6 05:32:44 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 5 Dec 2012 23:32:44 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <20121203070047.GA29068@redoubt.spodhuis.org> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> <20121203070047.GA29068@redoubt.spodhuis.org> Message-ID: <1E2F9E89-B41B-4CC7-A64D-60EC259D126B@jabberwocky.com> On Dec 3, 2012, at 2:00 AM, Phil Pennock wrote: > On 2012-12-02 at 23:46 -0500, David Shaw wrote: >> Hmm. Were you intending to test with the internal HTTP support or >> with libcurl? You're currently built with internal support: > > Ah. I couldn't tell, since the helper binaries are installed and > nothing explicitly said so. I used whatever FreeBSD Ports created by > default. > > Looking at the Makefile, looks as though FreeBSD has a sense inversion > in the curl option test for gnupg (2). If you build with the CURL > option set, as it will be by default, then instead of "Use the real curl > library (worked around if no)" Ports passes --without-libcurl to > GnuPG2's build. > > Turned _off_ that option and gpg2keys_hkp gains a lot more link > dependencies. > >>> gpgkeys: curl version = GnuPG curl-shim >> >> Looking at the internal support, it seems not to work on platforms >> with getaddrinfo(), which is odd as that part works in the 1.4 code. >> Anyway, try the attached patch in addition to the original one, and >> you should hopefully have better results. > > Looks like the internal support still isn't working, but the external > is picking up the port (and visibly sending the DNS-derived hostname). It's working, it's just misleading since the SRV replacement happens after the debug logging so the actual URL that is hit is not the one that is being logged. If you look at netstat, you can see it's connecting to the right port. Try this new patch (by itself, not on top of an earlier one) - it logs before and after the SRV replacement so it's clear what is going on. David -------------- next part -------------- A non-text attachment was scrubbed... Name: bug1446.patch.3 Type: application/octet-stream Size: 9862 bytes Desc: not available URL: -------------- next part -------------- From wk at gnupg.org Thu Dec 6 09:24:59 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2012 09:24:59 +0100 Subject: Is it safe to rename file.gpg to `md5sum file`? In-Reply-To: <50BFBEF8.6080203@yahoo.de> (Ben Staude's message of "Wed, 05 Dec 2012 22:39:04 +0100") References: <50B92E30.1000902@yahoo.de> <50BD50A3.107@sixdemonbag.org> <3B9C0CB23274453989625CF1C085C6B7@ktf.rtu.lv> <04938f097706d750e1e1eae27c2010fa@sun> <50BFBEF8.6080203@yahoo.de> Message-ID: <878v9bsi3o.fsf@vigenere.g10code.de> On Wed, 5 Dec 2012 22:39, sben1783 at yahoo.de said: > If I wanted to have a fallback for loosing the mapping table, would > there be a sane way to encrypt the filename with gpg? That way I could --set-filename string Use string as the filename which is stored inside messages. This overrides the default, which is to use the actual filename of the file being encrypted. If you want later want gpg to output to this file, you may use --use-embedded-filename --no-use-embedded-filename Try to create a file with a name as embedded in the data. This can be a dangerous option as it allows to overwrite files. Defaults to no. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 6 09:28:06 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2012 09:28:06 +0100 Subject: WOT and Authentication Research In-Reply-To: (Patrick Baxter's message of "Wed, 5 Dec 2012 14:15:14 -0800") References: Message-ID: <874njzshyh.fsf@vigenere.g10code.de> On Wed, 5 Dec 2012 23:15, patch at cs.ucsb.edu said: > And of course the last issue is finding a sane way for user's to store > and use private keys. Hence the PSST project and the eventual idea of PSST? That used to be the working title for a free implementation of ssh back in 1997. iirc, I sent the first announcement of gpg to the psst mailing list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nathan at guardianproject.info Thu Dec 6 11:43:43 2012 From: nathan at guardianproject.info (Nathan of Guardian) Date: Thu, 06 Dec 2012 10:43:43 +0000 Subject: [guardian-dev] WOT and Authentication Research In-Reply-To: <874njzshyh.fsf@vigenere.g10code.de> References: <874njzshyh.fsf@vigenere.g10code.de> Message-ID: <50C076DF.3010000@guardianproject.info> Werner Koch: > On Wed, 5 Dec 2012 23:15, patch at cs.ucsb.edu said: >> And of course the last issue is finding a sane way for user's to store >> and use private keys. Hence the PSST project and the eventual idea of > > PSST? That used to be the working title for a free implementation of > ssh back in 1997. iirc, I sent the first announcement of gpg to the > psst mailing list. I think we all tend to make some similar bad jokes in the crypto community. PSST in our case is Portable Shared Security Tokens, which is meant to be our concept for syncing private and public keys of all sorts between different devices and apps. Best, Nathan From melvincarvalho at gmail.com Thu Dec 6 14:40:18 2012 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Thu, 6 Dec 2012 14:40:18 +0100 Subject: WOT and Authentication Research In-Reply-To: References: Message-ID: On 5 December 2012 23:15, Patrick Baxter wrote: > On Tue, Dec 4, 2012 at 5:29 AM, Melvin Carvalho > wrote: > > > > Not sure I've grokked everything in this thread, but some thoughts. > > > I'm working on the TL;DR version :). > > > Tying a key to a 'domain' (aka URI) is something that can be done already > > using linked data. > > > > I do so on my home page already: > > > > http://melvincarvalho.com/ > > > > This contains my GPG key, fingerprint, hex_id, modulus and exponent. > > > > Here is the data view of the same page: > > > > > http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F > > I'm not sure I understand what it is that ties your key to the domain. > > So, for example, you know your public key and it that it is the proper > public key for your website. However, from an outsider's perspective, > anyone could publish a signature and claim ownership of your domain. > If they control the network path to a user first looking at your > webpage, then there is no consensus on which public key will get you > MITM'd and which is your actual key if they choose to present a > different one. You add strength by making it available on your > website, but it only goes so far. > The domain is tied to the information via DNS, which is the main web paradigm. Semantic tags let you make assertions in machine readable form. Yes, in theory I could add an SSL cert to my homepage, though I havent paid for one yes. There's a theoretical attack from MITM, but this is the case for much of the web. I'm working on something that can provide extra strength by recording your public keys over time: http://publickey.info/ But I havent really had time to maintain it yet. > > My general idea is somewhat encompassing of the Sovereign Keys idea, > but thats just part of the solution. Generally, I'd argue, you want a > keysever infrastructure similar to the EFF's soverign keys that > establish's a known single mapping. It widely distributes the public > keys to that keyserver with software so that you have a secure > connection into that data from the start. Now, you have to balance the > needs of updating this mapping with the security of the > infrastructure. There is lots of ways to capture meaningful data on > validity and I'm for using as many ways as possible such that it still > makes sense. Also, keeping a database of personally validated keys is > still massively useful for things like email, phone, and chat. It can > be used in conjunction with a better key server infrastructure to > minimize the trust you place on it. > I need to read up on sovereign keys a bit more. Has there been any serious critiques of it yet? > > You could probably also argue that the less authority a key-server > infrastructure has, the more resistant it is to corruption. This lends > strength to trying to not entirely relying on it even if it is > distributed and replicated. > > Now, the idea is that with this infrastructure you are restricted to > how you learn about new keys. So an active attacker on your network > connection will not find it so trivial present an fake key to users > that are connecting for the first time. > > > Scroll down to see the PKI fields. > > > > I can use this key to sign and encrypt mail, for s/MIME as an x.509 > > certificate, to login via ssh and also encrypted chat on retroshare > > > > I also have links to other people storing keys in a kind of web of trust. > > > > What you call the WOT is really a Graph of Trust (GOT) or Network of > Trust > > (NOT) in so far as the Web is normally loosely associated with HTTP. > > Maybe, I'm confusing the issue by trying to tie too many things > together, but the I think the problems all have a lot of fundamental > things in common. > > Also, If a user can link to you through a WOT, then they have that > initial validity that creates a much strong authentication and don't > have to trust the first key servered over the network. I think there > is a ton more potential for more effectively using WOT paths to > establish validity as well. > Yes, trust should be additive, rather than one WOT to rule them all. There's no perfect trust system, but you can do things to increase the confidence interval. You can generate a lot of functionality with limited trust too. The thing I dont like is when trust creates a barrier to entry that does NOT allow you to do things. Users should have freedom to choose, imho. > > > > > I think in terms of accessibility and usability we need a GPG equivalent > of > > what "hotmail" did to email. This is what we call "webizing". Then > people > > can make relations, sign and encrypt, over the web just as easily as > they do > > with desktop clients. Obviously a huge task and the crypto in the > browser > > group will help. > > Definitely a massive undertaking and I think the most relevant problem > to the world of crypto. It is getting better and more transparent (OTR > ect.) and I think one of the last difficult tasks is making it easy > for users with little knowledge to not only use crypto, but also be > strongly authenticated. Its not terribly difficult to make an app that > opportunistically establishes encryption, how do we make the user > capture strong validity by default? I think, its in the form of better > keyservers (users might need a little initial work to establish their > key and prove they own their email for example) and signing keys > automatically when you determine you have captured some sort of > validity on that key (See ZRTP's authentication or the social > millionaire protocol for OTR). > > And of course the last issue is finding a sane way for user's to store > and use private keys. Hence the PSST project and the eventual idea of > PGP smart card type computing devices. > I was at TPAC a couple of months ago and Mozilla did an impressive demo of crypto in the browser to generate keys and encrypt/decrypt. The W3C Crypto working group will hopefully provide some great API for those that wish to work with the web and with PKI. I think in this way it may be possible to scale the great features of GPG to a wider audience. But as I say, most groups are lite on resources, so it takes 1-2 people to make theory a reality... -------------- next part -------------- An HTML attachment was scrubbed... URL: From box500 at inbox.com Thu Dec 6 13:32:20 2012 From: box500 at inbox.com (JB JB) Date: Thu, 6 Dec 2012 04:32:20 -0800 Subject: OT: USB key with hardware encryption? In-Reply-To: <50BBAE1E.6020608@gmail.com> References: <50bba8c6.3050409@gmail.com> Message-ID: <181D058FDAD.00000BB7box500@inbox.com> You can find a small list of USB thumbdrives that use hardware encryption here: http://www.hacker10.com/usb-encryption/ ____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth From wk at gnupg.org Thu Dec 6 15:44:11 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Dec 2012 15:44:11 +0100 Subject: [admin] Mailing lists outage notice Message-ID: <87txrzp7er.fsf@vigenere.g10code.de> Hi, please be prepared that the mailing lists will be down for a few days due to a server upgrade. It would be too much work to move them temporary to another server. FTP will be down as well. The Web, Git, and the BTS should continue to work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dougb at dougbarton.us Fri Dec 7 04:17:13 2012 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 06 Dec 2012 19:17:13 -0800 Subject: WOT and Authentication Research In-Reply-To: References: Message-ID: <50C15FB9.4090104@dougbarton.us> On 12/06/2012 05:40 AM, Melvin Carvalho wrote: > Yes, in theory I could add an SSL cert to my homepage, though I havent > paid for one yes. You can get a free one at https://www.startssl.com/ From sks-devel-phil at spodhuis.org Fri Dec 7 08:40:19 2012 From: sks-devel-phil at spodhuis.org (Phil Pennock) Date: Fri, 7 Dec 2012 02:40:19 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <1E2F9E89-B41B-4CC7-A64D-60EC259D126B@jabberwocky.com> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> <20121203070047.GA29068@redoubt.spodhuis.org> <1E2F9E89-B41B-4CC7-A64D-60EC259D126B@jabberwocky.com> Message-ID: <20121207074019.GA33071@redoubt.spodhuis.org> On 2012-12-05 at 23:32 -0500, David Shaw wrote: > It's working, it's just misleading since the SRV replacement happens > after the debug logging so the actual URL that is hit is not the one > that is being logged. If you look at netstat, you can see it's > connecting to the right port. Sorry for the delay getting back to you. > Try this new patch (by itself, not on top of an earlier one) - it logs > before and after the SRV replacement so it's clear what is going on. Using Curl: So, I do see the correct port being used (bug 1446), I don't see the correct hostname (bug 1447) ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22 libssh2/1.4.1 librtmp/2.3 Host: keyserver.spodhuis.org Port: 11374 Command: GET * About to connect() to keyserver.spodhuis.org port 11374 (#0) * Trying 2a02:898:31:0:48:4558:73:6b73... * connected * Connected to keyserver.spodhuis.org (2a02:898:31:0:48:4558:73:6b73) port 11374 (#0) > GET /pks/lookup?op=get&options=mr&search=0x403043153903637F HTTP/1.1 Host: keyserver.spodhuis.org:11374 Accept: */* Pragma: no-cache Cache-Control: no-cache * additional stuff not fine transfer.c:1037: 0 0 * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < Date: Fri, 07 Dec 2012 07:26:05 GMT < Content-Type: application/pgp-keys; charset=UTF-8 < Content-Length: 63475 < Connection: keep-alive < Server: sks_www/1.1.4 < Cache-Control: no-cache < Pragma: no-cache < Expires: 0 < X-HKP-Results-Count: 1 < Content-disposition: attachment; filename=gpgkey.asc < Via: 1.1 keyserver.spodhuis.org:11374 (nginx) < * Connection #0 to host keyserver.spodhuis.org left intact * Closing connection #0 [gpg output for key] ----------------------------8< cut here >8------------------------------ Without Curl: The diagnostics confuse as to what is actually going to be sent; if you know the code well enough to know where the messages come from, I'm confident it's clear, but myself? I had to use tcpdump to satisfy myself that the "Host:" line coming _before_ the "original" line was what actually got sent. But it looks as though the non-Curl case is now fixed for both bugs 1446 & 1447. Interesting that the HTTP request itself got split into two packets. ----------------------------8< cut here >8------------------------------ % gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org gpgkeys: curl version = GnuPG curl-shim Host: keytest.spodhuis.org Command: GET * HTTP proxy is "null" * Original HTTP URL is "http://keytest.spodhuis.org:11371/pks/lookup?op=get&options=mr&search=0x403043153903637F" * SRV tag is "pgpkey-http": URL may be overridden * HTTP auth is "null" * HTTP method is GET * HTTP host:port post-SRV is "keyserver.spodhuis.org:11374" ----------------------------8< cut here >8------------------------------ ----------------------------8< cut here >8------------------------------ 02:35:22.942405 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 136) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: P, cksum 0x131c (correct), 1:105(104) ack 1 win 32844 0x0000: 6009 380b 0088 0640 2a02 0898 0031 0000 `.8....@*....1.. 0x0010: 0048 4558 0073 6b73 2a02 0898 0031 0000 .HEX.sks*....1.. 0x0020: 0048 4558 0073 6b73 ffa4 2c6e e223 9b76 .HEX.sks..,n.#.v 0x0030: 1ab3 cf49 8018 804c 131c 0000 0101 080a ...I...L........ 0x0040: e6e7 24a3 3b1e 017c 4745 5420 2f70 6b73 ..$.;..|GET./pks 0x0050: 2f6c 6f6f 6b75 703f 6f70 3d67 6574 266f /lookup?op=get&o 0x0060: 7074 696f 6e73 3d6d 7226 7365 6172 6368 ptions=mr&search 0x0070: 3d30 7834 3033 3034 3331 3533 3930 3336 =0x4030431539036 0x0080: 3337 4620 4854 5450 2f31 2e30 0d0a 486f 37F.HTTP/1.0..Ho 0x0090: 7374 3a20 6b65 7974 6573 742e 7370 6f64 st:.keytest.spod 0x00a0: 6875 6973 2e6f 7267 3a31 3133 3731 0d0a huis.org:11371.. 02:35:22.942487 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 77) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: FP, cksum 0xe48f (correct), 105:150(45) ack 1 win 32844 0x0000: 6009 380b 004d 0640 2a02 0898 0031 0000 `.8..M.@*....1.. 0x0010: 0048 4558 0073 6b73 2a02 0898 0031 0000 .HEX.sks*....1.. 0x0020: 0048 4558 0073 6b73 ffa4 2c6e e223 9bde .HEX.sks..,n.#.. 0x0030: 1ab3 cf49 8019 804c e48f 0000 0101 080a ...I...L........ 0x0040: e6e7 24a3 3b1e 017c 4361 6368 652d 436f ..$.;..|Cache-Co 0x0050: 6e74 726f 6c3a 206e 6f2d 6361 6368 650d ntrol:.no-cache. 0x0060: 0a50 7261 676d 613a 206e 6f2d 6361 6368 .Pragma:.no-cach 0x0070: 650d 0a0d 0a e.... ----------------------------8< cut here >8------------------------------ Regards, -Phil From dshaw at jabberwocky.com Fri Dec 7 21:32:55 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 7 Dec 2012 15:32:55 -0500 Subject: [Sks-devel] SRV records and HKPS requests In-Reply-To: <20121207074019.GA33071@redoubt.spodhuis.org> References: <507052E8.7040807@sumptuouscapital.com> <20121007022039.GB57007@redoubt.spodhuis.org> <62B43472-317D-4BE3-B132-4736D8C550DA@jabberwocky.com> <20121203005958.GA82072@redoubt.spodhuis.org> <4A5D5C55-04CA-4C3D-BDED-F2E8627A31D1@jabberwocky.com> <20121203070047.GA29068@redoubt.spodhuis.org> <1E2F9E89-B41B-4CC7-A64D-60EC259D126B@jabberwocky.com> <20121207074019.GA33071@redoubt.spodhuis.org> Message-ID: <1A0E63D3-3EF4-4176-84BF-3625D67CB3B0@jabberwocky.com> On Dec 7, 2012, at 2:40 AM, Phil Pennock wrote: > On 2012-12-05 at 23:32 -0500, David Shaw wrote: >> It's working, it's just misleading since the SRV replacement happens >> after the debug logging so the actual URL that is hit is not the one >> that is being logged. If you look at netstat, you can see it's >> connecting to the right port. > > Sorry for the delay getting back to you. > >> Try this new patch (by itself, not on top of an earlier one) - it logs >> before and after the SRV replacement so it's clear what is going on. > > Using Curl: > > So, I do see the correct port being used (bug 1446), I don't see the > correct hostname (bug 1447) Yes. This is just a fix for 1446. Thanks, David From stephen at missouri.edu Sat Dec 8 17:07:28 2012 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Sat, 08 Dec 2012 10:07:28 -0600 Subject: corrupted trustdb Message-ID: <50C365C0.6080209@missouri.edu> I inherited a key that was created in 2000. I have used it to create signatures for emails and files for a long time. But for some reason it fails to work with any version of gpg greater than 1.0.4. Anyway, I am now running into problems that sometimes this key fails to properly sign large files. So I would like to recreate the trusted key so that (a) it will work with gpg greater than 1.0.4, and (b) sign large files. I tried the command "gpg --export-ownertrust" and nothing came out. Here are the files I am trying to sign (in case you are interested): ftp://ftp.freebsd.org/pub/FreeBSD/CTM/svn-cur/ - it is the file svn-cur.01000xEmpty.xz whose signature fails. Almost all the other files have good signatures. Does anyone have any other suggestions as to how I can fix my trusted keys? Or should I go ahead and create completely new keys? I'll be happy to provide more details upon request. Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Sat Dec 8 18:28:37 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 08 Dec 2012 18:28:37 +0100 Subject: corrupted trustdb In-Reply-To: <50C365C0.6080209@missouri.edu> References: <50C365C0.6080209@missouri.edu> Message-ID: <2976783.jKszFKIklq@inno> Am Sa 08.12.2012, 10:07:28 schrieb Stephen Montgomery-Smith: > I inherited a key that was created in 2000. I have used it to create > signatures for emails and files for a long time. But for some reason it > fails to work with any version of gpg greater than 1.0.4. > > Anyway, I am now running into problems that sometimes this key fails to > properly sign large files. So I would like to recreate the trusted key > so that (a) it will work with gpg greater than 1.0.4, and (b) sign large > files. That sounds a bit strange to me. What exactly is "fails to work" supposed to mean? It's a huge difference whether a) a key cannot create good signatures b) a key (and thus its signatures) is not trusted > Does anyone have any other suggestions as to how I can fix my trusted > keys? Or should I go ahead and create completely new keys? You can easily set the trust level for a key: gpg --edit-key 0x12345678 trust But that affects your local installation only. That gpg --export-ownertrust fails may be a hint that the file is corrupted. You could delete / rename it and run gpg --update-trustdb afterwards. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From stephen at missouri.edu Sat Dec 8 19:20:21 2012 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Sat, 08 Dec 2012 12:20:21 -0600 Subject: corrupted trustdb In-Reply-To: <2976783.jKszFKIklq@inno> References: <50C365C0.6080209@missouri.edu> <2976783.jKszFKIklq@inno> Message-ID: <50C384E5.8020600@missouri.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/2012 11:28 AM, Hauke Laging wrote: > Am Sa 08.12.2012, 10:07:28 schrieb Stephen Montgomery-Smith: >> I inherited a key that was created in 2000. I have used it to >> create signatures for emails and files for a long time. But for >> some reason it fails to work with any version of gpg greater than >> 1.0.4. >> >> Anyway, I am now running into problems that sometimes this key >> fails to properly sign large files. So I would like to recreate >> the trusted key so that (a) it will work with gpg greater than >> 1.0.4, and (b) sign large files. > > That sounds a bit strange to me. What exactly is "fails to work" > supposed to mean? It's a huge difference whether a) a key cannot > create good signatures b) a key (and thus its signatures) is not > trusted I am using it to create detached signatures. gpg-1.0.4 creates detached signatures, but when someone else tries to verify the signature, it says "BAD signature." Most files I generate detached signatures for work in that verification works, saying "Good signature from "CTM Generator "". But for a couple of very large files, it creates "BAD signature." gpg-2.0.19 does not create signatures at all, instead coming up with error messages like gpg: [don't know]: invalid packet (ctb=73) gpg: keydb_search failed: Invalid packet gpg: error checking usability status of C380B4D8 gpg: [don't know]: invalid packet (ctb=73) gpg: keydb_search failed: Invalid packet gpg: key C380B4D8: secret key without public key - skipped gpg: no default secret key: No secret key gpg: signing failed: No secret key > > >> Does anyone have any other suggestions as to how I can fix my >> trusted keys? Or should I go ahead and create completely new >> keys? > > You can easily set the trust level for a key: gpg --edit-key > 0x12345678 trust > > But that affects your local installation only. That gpg > --export-ownertrust fails may be a hint that the file is corrupted. > You could delete / rename it and run gpg --update-trustdb > afterwards. The issue is that it seems that my private key is corrupted. I probably should have said "private" instead of "trusted." (Gpg is rather new to me, and I probably don't get the lingo correct.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQw4TkAAoJEC3xK9GaktgHMZYH/1m87jsMXxxWAfHwXKIPSPG+ K/xwL562XFv0t6gDnFgSAkiz9E0dKDefRCgc/ccxdCIuGX7gCYPOmzoIpxhdgtri 3R/fbMNaTW7DA6Ew6hkIDePvjb3ZKKM2B5pdXWA3bzmr+LODVNoaTpUsuwLlOBPY iT8rTMkhQ+dNJMm62P4TT09MeLPL16SWjNbwQAWL2LxlS9oeMmgJR6eklZ5ZJDFC La1wnlmyXHXgrMf55rTsJFGI1vXCypB4ue9HIAVJvdYkU0RA5sMs5dxhyIaKSOdt mE/RGGWquvLDVcnnWbQx3usDTLPTzPuQeM+zzOXpdt+zCfIvayBsJtZYuwNIv5E= =kH5L -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Dec 11 13:46:07 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 11 Dec 2012 07:46:07 -0500 Subject: A Probabilistic Trust Model for GnuPG (2006) In-Reply-To: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> References: <1371764.14111355211590324.JavaMail.webmail@bluewin.ch> Message-ID: <50C72B0F.5060505@sixdemonbag.org> On 12/11/2012 2:39 AM, remo.hertig at bluewin.ch wrote: > Why was this functionality never implemented? Forgive the snarky response, but: because no one, yourself included, has bothered to implement it. Looking over this paper, it does not seem to pass my sniff test for academic works. For instance, there's no thesis statement anywhere on the first page: they say "In this paper, we will first give a short overview of the PGP trust model ... to point out some of its inherent weaknesses and deficiencies." Okay, fine: but if they can't give a one-sentence description of what problem they found, it makes me think they didn't find much of a problem. This view of mine is mostly confirmed by page two. The first "major deficiency" of the WoT they present -- and remember, standard writing style is to start off with the big things, so we can reasonably infer this is the major takeaway -- is "the limited levels of trust in PGP [are] clearly insufficient to reflect possible varying opinions about an introducer's trustworthiness. In real life, it may be that among two marginally trustworthy introducers one of them is twice more trustworthy than the other. Unfortunately, the PGP trust model does not support such a distinction." I've been using PGP since 1991. I've used it professionally, I've set up and deployed sites that use hundreds of certificates. And never, not once, have I ever lamented the lack of fine-grained trust decisions in the WoT. More to the point, I don't think fine-grained trust is possible. You can't say, "Bob is 53% trustworthy and Alice is 55% trustworthy." Trust is a human concept, and as such it finds its manifestation in qualitative rather than quantitative terms. "Marginal trust" is a qualitative term: "53% trust" is a quantitative term. So, their biggest objection to the WoT is, IMO, a dog that won't hunt. I also agree with Nicholas, who said that he didn't find their "counter-intuitive" example to be at all counter-intuitive. I'll go one step further: anyone who expects to analyze the behavior of a formal system by means of intuition is living in sin. Describing the behavior of a formal system as "counter-intuitive" is sort of like the old joke about a philosopher who justified a really bad decision on the grounds that it "felt like the logical thing to do." So, yeah. I see this paper as solving a nonexistent problem. I don't think it's something the GnuPG developers should tackle: we have other more important things to spend our limited developer resources on. From roy.sindre at norangshol.no Wed Dec 12 19:28:18 2012 From: roy.sindre at norangshol.no (Roy Sindre Norangshol) Date: Wed, 12 Dec 2012 19:28:18 +0100 Subject: A few newbie questions, I'am doing this right? Message-ID: <20121212182818.GA7449@phobos.home.sonpro.no> Hello list! I'm trying to setup my gpg setup properly for the first time, and wondering if this setup seems fine: Master keypair with only the ?certificate? as it's only role, this master keypair I'll only use for: * signing someone else's key * creating a new subkey * revoking a subkey as mentioned on debian's wiki[1] and will be stored offline on my private encrypted usb thumbdrive and only used on my own secure equipment (fully encrypted laptop or home computer) (planning to buy a cryptostick[2] after new years) So I've created 3 seperate subkeys for each role: * sign (2y expire) * auth (2y expire) * encryption (never) I assume two year expire on sign and auth is good and requirements me to redo sign and auth subkeypairs every each year to ?show I'am alive and kicking?. Encryption is set to never, if it gets compromised I'll have to reencrypt all my stuff that I want to keep safe anyway and wipe existing old copies. Encryption key I will only have at home, laptop and server stationed at my parents (used for mutt) which are all fully encrypted. I've attached two identities (roy.sindre at norangshol.no and my current identity at work.) I thought I could create two additional subkeys (sign and auth) for use at work for my work identity, in case these subkeys gets compromised I can easily revoke these two keys and create new ones to use at work and don't need to worry about building a whole new web-of-trust since signing happens with my master key which is securly stored offline. Is this partly okey as long as I use those additional work subkeys only at work and not my other ones? (planning to store them on my workstation which I guess is insecure as techies can remotly access it.)) If an encryption shows up as a requirement later at work, I guess there is no problems later to add an additional encryption subkey to use at work if I understand this correctly? Since I'm using subkeys I don't have to ?redo? the web-of-trust/signing when renewing my subkeys, right? I'am missing something huge or does this setup look okey? :-) Kinda want to properly setup this before attending any kind of signing parties. Thank you in advance! [1] http://wiki.debian.org/subkeys [2] http://www.crypto-stick.com/ -- Roy Sindre Norangshol roy.sindre at norangshol.no From mailinglisten at hauke-laging.de Thu Dec 13 02:21:06 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 13 Dec 2012 02:21:06 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <20121212182818.GA7449@phobos.home.sonpro.no> References: <20121212182818.GA7449@phobos.home.sonpro.no> Message-ID: <12324641.X2PPAQHPhD@inno> Am Mi 12.12.2012, 19:28:18 schrieb Roy Sindre Norangshol: > I'm trying to setup my gpg setup properly for the first time, and wondering > if this setup seems fine: "Best practice" is often subjective. > Master keypair with only the ?certificate? as it's only role, this master > keypair I'll only use for: > > * signing someone else's key > * creating a new subkey > * revoking a subkey I would add signing ability at any rate and (depending on the circumstances perhaps) even encryption. This allows you to make very secure signatures. This is very useful for a key policy document (--set-policy-url). If you do not have another key another key which is more secure then your mainkey allows you encrypt data more safely which from time to time can be useful. > as mentioned on debian's wiki[1] and will be stored offline on my private > encrypted usb thumbdrive and only used on my own secure equipment (fully > encrypted laptop or home computer) You can put your private mainkey on your website. A passphrase like 02NWL7YLKTa9uUhosA is harder than the key itself (at 2048 bit). Just never enter the passphrase in an unsecure system. And don't forget ist. :-) Full disk encryption does not make a system secure. Get a safe boot medium. (And store it physically secure... ;-) ) > (planning to buy a cryptostick[2] after new years) Security is much better with a card reader which has a PIN pad. > So I've created 3 seperate subkeys for each role: > > * sign (2y expire) > * auth (2y expire) > * encryption (never) > > I assume two year expire on sign and auth is good and requirements me to > redo sign and auth subkeypairs every each year to ?show I'am alive and > kicking?. This can be shown by extending the expiration date of existing keys, too. One argument for expiration dates is that they stop others from using your key if you have lost the private (main) key. I use a time limit of one year. > Encryption is set to never, if it gets compromised I'll have to > reencrypt all my stuff that I want to keep safe anyway and wipe existing > old copies. This has nothing to do with the expiration date, does it? > Encryption key I will only have at home, laptop and server > stationed at my parents (used for mutt) which are all fully encrypted. The real danger should be online attacks. I would not consider a system secure which is used for WWW or email. > I've attached two identities (roy.sindre at norangshol.no and my current > identity at work.) Is roy.sindre at norangshol.no a private address? In general I would not mix private and business addresses within a key. > I thought I could create two additional subkeys (sign and auth) for use at > work for my work identity, in case these subkeys gets compromised I can > easily revoke these two keys and create new ones to use at work One more reason to create different mainkeys. Subkeys are not bound to UIDs. Both subkeys and UIDs are bound to the mainkey. And what if someone wants to send encrypted mail to your work account? I do not see any advantage in mixing the IDs (and environments), just problems. > Since I'm using subkeys I don't have to ?redo? the web-of-trust/signing when > renewing my subkeys, right? Right. The WoT refers to mainkeys and UIDs only. > Kinda want to properly setup this before attending any kind of signing > parties. Thank you in advance! Further recommendations for a "proper setup": ? add a UID without email (just your name and a comment; this will be valid "forever") ? configure a preferred keyserver (--default-keyserver-url) ? configure a policy URL (even if you write the real document later; --set- policy-url) ? configure your cipher and digest preferences (--default-preference-list) ? don't make non-local (lsign) certifications before you have finished your certification policy ? If you create two keys then create your work key with your personal key as designated revoker ? After key creation make small slips of paper with your name, email and fingerprint and always have some with you, like ---------------------------- | Hauke Laging | | hauke at laging.de | | 7D82 FB9F D25A 2CE4 5241 | | 6C37 BF4B 8EEF 1A57 1DF5 | ---------------------------- Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ricul77 at gmail.com Thu Dec 13 08:43:53 2012 From: ricul77 at gmail.com (Richi Lists) Date: Thu, 13 Dec 2012 08:43:53 +0100 Subject: Same key on different smart cards Message-ID: <1355384633.2868.8.camel@onenc> Hi, I want to have a second and third smart card as fallback. For full disk encryption and ssh it would be ok to have different keys. But as far as I understand, for eMail signing and decryption, it needs to be the same key on all cards. I set up two crypto sticks to contain the same sub keys. But the unique id of the card seems to be stored in the private key stub (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an error telling me to insert the correct card. Is it possible to manage the same identity with multiple smart cards? Of course I could use a separate smart card with every computer and have the stub match the card, but I want to be able to use whatever smart card I have closest. And in case one breaks, just use the next one. An what is the best approach for this? Rgds Richard From wk at gnupg.org Thu Dec 13 10:30:32 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Dec 2012 10:30:32 +0100 Subject: Same key on different smart cards In-Reply-To: <1355384633.2868.8.camel@onenc> (Richi Lists's message of "Thu, 13 Dec 2012 08:43:53 +0100") References: <1355384633.2868.8.camel@onenc> Message-ID: <874njqcn9j.fsf@vigenere.g10code.de> On Thu, 13 Dec 2012 08:43, ricul77 at gmail.com said: > (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an > error telling me to insert the correct card. You need to delete the secret key stub and then gpg should be able to re-create it using the current card. I am not sure about the details because I am using 2.1 for a long time now. 2.1 works a bit different in this regard Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Thu Dec 13 10:43:56 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 13 Dec 2012 10:43:56 +0100 Subject: Same key on different smart cards In-Reply-To: <1355384633.2868.8.camel@onenc> References: <1355384633.2868.8.camel@onenc> Message-ID: <1984739.xfj0eWKZZh@inno> Am Do 13.12.2012, 08:43:53 schrieb Richi Lists: > But as far as I understand, for eMail signing and decryption, it needs > to be the same key on all cards. I have not checked that but I don't think so. Wouldn't make sense. When using key A, why should gpg-agent care, where key B is stored? > I set up two crypto sticks to contain the same sub keys. But the unique > id of the card seems to be stored in the private key stub > (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an > error telling me to insert the correct card. What do you want? The signing key on one smartcard, the decryption key on the other? If so, why have you stored both keys on the same card? > Is it possible to manage the same identity with multiple smart cards? That is a different problem. This is not directly supported by GnuPG but possible by a workaround: After changing the smartcard you can delete the secret keys and register the smartcard afterwards. Then the card reference is "updated". Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From roy.sindre at norangshol.no Thu Dec 13 11:03:07 2012 From: roy.sindre at norangshol.no (Roy Sindre Norangshol) Date: Thu, 13 Dec 2012 11:03:07 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <12324641.X2PPAQHPhD@inno> References: <20121212182818.GA7449@phobos.home.sonpro.no> <12324641.X2PPAQHPhD@inno> Message-ID: <20121213100307.GC7449@phobos.home.sonpro.no> On 12/13/12 at 02:21am, Hauke Laging wrote: > Am Mi 12.12.2012, 19:28:18 schrieb Roy Sindre Norangshol: > > > I'm trying to setup my gpg setup properly for the first time, and wondering > > if this setup seems fine: > > "Best practice" is often subjective. Indeed, fighting between security vs usability. > > > Master keypair with only the ?certificate? as it's only role, this master > > keypair I'll only use for: > > > > * signing someone else's key > > * creating a new subkey > > * revoking a subkey > > I would add signing ability at any rate and (depending on the circumstances > perhaps) even encryption. This allows you to make very secure signatures. This > is very useful for a key policy document (--set-policy-url). I was orginally only thinking of having 1 main key pair, hence having the main key with certificate ability. Signing I will do with my assigned signing subkey. > > If you do not have another key another key which is more secure then your > mainkey allows you encrypt data more safely which from time to time can be > useful. I don't, my plan was to have the main key to be this most secured item, which have the ability to create myself a new subkeypair if I've been unlucky and compromised. > Full disk encryption does not make a system secure. Get a safe boot medium. > (And store it physically secure... ;-) ) Not a bad idea :-) > > > > (planning to buy a cryptostick[2] after new years) > > Security is much better with a card reader which has a PIN pad. Any recommendations? cryptostick was recommended by fellow friends at the university as it was open source and fully open. And if using a cryptostick, even if attaching it to a compromised computer they will never be able to access the private key, so that's why I'm thinking of ordering one. > > > So I've created 3 seperate subkeys for each role: > > > > * sign (2y expire) > > * auth (2y expire) > > * encryption (never) > > > > I assume two year expire on sign and auth is good and requirements me to > > redo sign and auth subkeypairs every each year to ?show I'am alive and > > kicking?. > > This can be shown by extending the expiration date of existing keys, too. One > argument for expiration dates is that they stop others from using your key if > you have lost the private (main) key. I use a time limit of one year. > > > > Encryption is set to never, if it gets compromised I'll have to > > reencrypt all my stuff that I want to keep safe anyway and wipe existing > > old copies. > > This has nothing to do with the expiration date, does it? It just sounds weird for me having to renew the encryption key, what about old documents encrypted with the old subkey? Kind of usabilty vs security. > > > > Encryption key I will only have at home, laptop and server > > stationed at my parents (used for mutt) which are all fully encrypted. > > The real danger should be online attacks. I would not consider a system secure > which is used for WWW or email. Again a usability vs security, if I want to start using GPG actively I don't want having to write my email at my local pc, encrypt it and send it over to my private server to attach it. > > > > I've attached two identities (roy.sindre at norangshol.no and my current > > identity at work.) > > Is roy.sindre at norangshol.no a private address? In general I would not mix > private and business addresses within a key. Yes, that's my private address (first name at last name) and I doubt I'll ever change that in my life time. Is it that bad? You could simply revoke the identity if you no longer use it. I'm just afraid if I choose a too complex setup I end up not using it at all. > > > I thought I could create two additional subkeys (sign and auth) for use at > > work for my work identity, in case these subkeys gets compromised I can > > easily revoke these two keys and create new ones to use at work > > One more reason to create different mainkeys. Subkeys are not bound to UIDs. > Both subkeys and UIDs are bound to the mainkey. And what if someone wants to > send encrypted mail to your work account? I do not see any advantage in mixing > the IDs (and environments), just problems. Not able to generate a own dedicated subkeypair for encryption if the requirements shows up for using encryption at work? (if I end up using only one main key pair) > > Kinda want to properly setup this before attending any kind of signing > > parties. Thank you in advance! > > Further recommendations for a "proper setup": > > ? add a UID without email (just your name and a comment; this will be valid > "forever") Still suggesting this even if I doubt I'll ever in my life time swap out my private email? (see comment above) > ? configure a preferred keyserver (--default-keyserver-url) > ? configure a policy URL (even if you write the real document later; --set- > policy-url) > ? configure your cipher and digest preferences (--default-preference-list) Thanks for info, I'll dig into the manual and set these. > ? don't make non-local (lsign) certifications before you have finished your > certification policy Thought of fetching 3 local close co-workers signatures before leaving for xmas vacation, does that affect the --set-policy-url if set later? > ? If you create two keys then create your work key with your personal key as > designated revoker Still thinking about this one. (in regards of the follow up encryption question). Anyway a good thing to do if I go for two separate main key pairs. > ? After key creation make small slips of paper with your name, email and > fingerprint and always have some with you, like :-) -- Roy Sindre Norangshol roy.sindre at norangshol.no From mailinglisten at hauke-laging.de Thu Dec 13 13:10:35 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 13 Dec 2012 13:10:35 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <20121213100307.GC7449@phobos.home.sonpro.no> References: <20121212182818.GA7449@phobos.home.sonpro.no> <12324641.X2PPAQHPhD@inno> <20121213100307.GC7449@phobos.home.sonpro.no> Message-ID: <4265438.anoHMM7euF@inno> Am Do 13.12.2012, 11:03:07 schrieb Roy Sindre Norangshol: > > I would add signing ability at any rate and (depending on the > > circumstances > > perhaps) even encryption. This allows you to make very secure signatures. > > This is very useful for a key policy document (--set-policy-url). > > I was orginally only thinking of having 1 main key pair, hence having the > main key with certificate ability. Signing I will do with my assigned > signing subkey. Sure you will. But that has nothing to do with my argument. There are arguments against giving the main key decryption capability (because you do not control what is encrypted for this key). But as you completely control which signatures you make I don't think there is any serious argument against signing capability. > > If you do not have another key another key which is more secure then your > > mainkey allows you encrypt data more safely which from time to time can be > > useful. > > I don't, my plan was to have the main key to be this most secured item, OK but you unnecessarily limit your benifit of this higher security to certifications. Why? > > Security is much better with a card reader which has a PIN pad. > > Any recommendations? I have a SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader. I have never had problems with it. It seems to me that this is a popular product among GnuPG users. This is the only card reader I have used so I cannot compare it to others. > cryptostick was recommended by fellow friends at the > university as it was open source and fully open. Doesn't replace a PIN pad... > And if using a cryptostick, > even if attaching it to a compromised computer they will never be able to > access the private key, so that's why I'm thinking of ordering one. They will not be able to steal the key from the stick, that's correct. But the attacker is capable of using the stick without limit. Unfortunately (I don't know the reason for this policy difference) the same is true for PIN pads and encryption. But for signatures the damage can be limited. > It just sounds weird for me having to renew the encryption key, what about > old documents encrypted with the old subkey? I don't understand the question. The expiration date is relevant for the public keys only. OpenPGP applications refuse to encrypt for an expired key. But you can always use it for decryption. > Again a usability vs security, if I want to start using GPG actively I don't > want having to write my email at my local pc, encrypt it and send it over > to my private server to attach it. Of course. That's why you create a key with subkeys which have limited security. That is perfectly OK. The key security has to meet the key usage and it should be well known to anyone who is affected. The aim of keys is not to increase the security requirements for the respective application. > Is it that bad? You could simply revoke the identity if you no longer use > it. You lose the certifications for this UID which may damage your position in the Web of Trust. > I'm just afraid if I choose a too complex setup I end up not using it > at all. I don't see that risk. Why should you not use OpenPGP or use it less just because you have an additional UID? Or because your key has a policy URL, preference settings and a mainky with signing ability? The only possible problem I can imagine is that you fail in creating such a key (which is very improbable IMHO). But after creation all that does not make a relevant difference in everyday use. > Not able to generate a own dedicated subkeypair for encryption if the > requirements shows up for using encryption at work? No. You are capable of generating a new subkey for encryption but you cannot generate one which is dedicated to work. Usually the newest subkey (the one with the newest self signature) will be chosen by all senders (both to your private and work account). The UID bound preferences don't cover the subkey to be used, just the symmetric cipher. > > ? add a UID without email (just your name and a comment; this will be > > valid > > "forever") > > Still suggesting this even if I doubt I'll ever in my life time swap out my > private email? (see comment above) I still suggest that because I promote all keys to have this structure. So even if especially you don't have to be afraid of problems you can still be an example for others. > > ? don't make non-local (lsign) certifications before you have finished > > your > > certification policy > > Thought of fetching 3 local close co-workers signatures before leaving for > xmas vacation, does that affect the --set-policy-url if set later? I am not sure what you mean by "fetch signatures". You can have them verify and publicly certify your key, that's not a problem. And you can verify their keys and even certify them: either locally or regularly as long as you don't export your signature to anyone. My general advice is to create a dedicated key for local signatures because it is quite unconvenient to always have to use the real mainkey in a secure environment. My strategy is: Use the lsign key for making other keys valid quickly (just for yourself) and use the safe mainkey for active participation in the Web of Trust. > > ? If you create two keys then create your work key with your personal key > > as designated revoker > > Still thinking about this one. I would guess that your thinking has not brought up a single good reason for sharing one key with personal use and work. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From roy.sindre at norangshol.no Thu Dec 13 14:43:39 2012 From: roy.sindre at norangshol.no (Roy Sindre Norangshol) Date: Thu, 13 Dec 2012 14:43:39 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <12324641.X2PPAQHPhD@inno> References: <20121212182818.GA7449@phobos.home.sonpro.no> <12324641.X2PPAQHPhD@inno> Message-ID: <20121213134339.GD7449@phobos.home.sonpro.no> On 12/13/12 at 02:21am, Hauke Laging wrote: > *snip* > This is very useful for a key policy document (--set-policy-url). Could you please show me an example of how you set such a key policy document? I tried ?gpg2 --edit-key 0xMyPublicKey --set-policy-url static-www-link-to-my-gpg-policy-webpage-which-is-blank-atm? without any success. Kinda had the same issues with setting my keyserver, but at least I could do it interactivly in gpg-shell. (I'll follow up rest of your questions later this evening hopefully, again: thanks for your input!) -- Roy Sindre Norangshol roy.sindre at norangshol.no From roy.sindre at norangshol.no Thu Dec 13 16:39:46 2012 From: roy.sindre at norangshol.no (Roy Sindre Norangshol) Date: Thu, 13 Dec 2012 16:39:46 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <20121213134339.GD7449@phobos.home.sonpro.no> References: <20121212182818.GA7449@phobos.home.sonpro.no> <12324641.X2PPAQHPhD@inno> <20121213134339.GD7449@phobos.home.sonpro.no> Message-ID: <20121213153946.GE7449@phobos.home.sonpro.no> On 12/13/12 at 02:43pm, Roy Sindre Norangshol wrote: > On 12/13/12 at 02:21am, Hauke Laging wrote: > > *snip* > > This is very useful for a key policy document (--set-policy-url). > > Could you please show me an example of how you set such a key policy document? > I tried ?gpg2 --edit-key 0xMyPublicKey --set-policy-url > static-www-link-to-my-gpg-policy-webpage-which-is-blank-atm? without any > success. Figured this out, it should be used when signing others public key. Doh :-) -- Roy Sindre Norangshol roy.sindre at norangshol.no From ilf at zeromail.org Fri Dec 14 22:02:29 2012 From: ilf at zeromail.org (ilf) Date: Fri, 14 Dec 2012 22:02:29 +0100 Subject: mutt message "skipped: public key already present" Message-ID: <20121214210228.GM15965@zeromail.org> I am using GnuPG (1.4.11) with mutt (1.5.21) and the following muttrc settings: > set crypt_autosign > set pgp_encrypt_only_command="/usr/lib/mutt/pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" When encrypting a mail with myself in Cc:, I get the following: > skipped: public key already present > Press any key to continue. How can I disable having to press a key after this message or disable it completely? -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From expires2012 at rocketmail.com Sat Dec 15 16:07:48 2012 From: expires2012 at rocketmail.com (MFPA) Date: Sat, 15 Dec 2012 15:07:48 +0000 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <4265438.anoHMM7euF@inno> References: <20121212182818.GA7449@phobos.home.sonpro.no> <12324641.X2PPAQHPhD@inno> <20121213100307.GC7449@phobos.home.sonpro.no> <4265438.anoHMM7euF@inno> Message-ID: <14410293447.20121215150748@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 13 December 2012 at 12:10:35 PM, in , Hauke Laging wrote: > But as you completely > control which signatures you make I don't think there > is any serious argument against signing capability. Since key compromise is possible however careful you intend to be, isn't it better for the non-expiring main key to have the minimum possible capability set? > OK but you unnecessarily limit your benifit of this > higher security to certifications. There is no real limitation here. If a need arose for "higher security" signing or encryption keys, new subkeys with those capabilities could be created and circulated, and the secret subkeys stored offline just like the main key. > Unfortunately (I don't know the reason for this policy > difference) the same is true for PIN pads and > encryption. But for signatures the damage can be > limited. Maybe because encryption uses the public key, so no passphrase or PIN would be required? >> > ? add a UID without email (just your name and a >> comment; this will be > valid > "forever") Really? In many countries it is traditional for one or or both partner(s) to change their name on marriage. And it is not all that rare for people to change their name at other times for personal or professional reasons. >> if I doubt I'll ever in my >> life time swap out my private email? (see comment >> above) But it could happen. How do you know what email addresses and domain names will look like in several decades? Or whether somebody may offer to purchase your domain name for a vast sum of money? Or whether you may at some point forget to renew the domain, or have it stolen from you by illicit action on behalf of some corporate or government agency? > My general advice is to create a dedicated key for > local signatures because it is quite unconvenient to > always have to use the real mainkey in a secure > environment. My strategy is: Use the lsign key for > making other keys valid quickly (just for yourself) and > use the safe mainkey for active participation in the > Web of Trust. That strikes me as good advice even if your main key is not stored offline. >> > ? If you create two keys then create your work key >> with your personal key > as designated revoker Sounds like a sensible precaution if work policy allows. - -- Best regards MFPA mailto:expires2012 at rocketmail.com If you can't convince them, confuse them. -----BEGIN PGP SIGNATURE----- iQCVAwUBUMySSqipC46tDG5pAQr3rgP+NE6MwPkNbOs3qgfkcWMZ9Dj3YqtvNE9M Axle6onKP5qfw3Dx/SFZj6Q3aPI11lpgdhboEJH+0OlMYsY2wgDupeGo8Uej+YUx cssLRgA7barXOAb7M6OZO5dR8OsYREDkcf9zuMAF3qCbU+f3n1lTEvLAJUACbU2f HmqTdmx9Vhg= =OsLz -----END PGP SIGNATURE----- From christian at quelltextlich.at Sat Dec 15 17:44:43 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sat, 15 Dec 2012 17:44:43 +0100 Subject: mutt message "skipped: public key already present" In-Reply-To: <20121214210228.GM15965@zeromail.org> References: <20121214210228.GM15965@zeromail.org> Message-ID: <20121215164443.GA13555@quelltextlich.at> Hi ilf, On Fri, Dec 14, 2012 at 10:02:29PM +0100, ilf wrote: > I am using GnuPG (1.4.11) with mutt (1.5.21) and the following muttrc > settings: > > > set crypt_autosign > > set pgp_encrypt_only_command="/usr/lib/mutt/pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" > > When encrypting a mail with myself in Cc:, I get the following: > > > skipped: public key already present > > Press any key to continue. > > How can I disable having to press a key after this message or disable it > completely? That problem may stem from having an "encrypt-to" line with your key/email address in your GnuPG configuration. Upon encryption GnuPG tries to obtain a list of keys to encrypt to. GnuPG adds each recipient's key to this list (This includes your key, due to the Cc). GnuPG adds the encrypt-to key (if one is given) to this list. So if you set encrypt-to to your own key, and Cc to yourself, your key would be added twice to this list, and GnuPG warns against this. mutt in turn sees that pgp_encrypt_only_command resulted in some output on stderr and therefore pauses so you can read the output. IIRC, mutt does not allow to skip the waiting (as $wait_key does not apply here). pgpewrap does not allow to mangle stderr. GnuPG does not allow to turn this logging off. So either you insert some code to filter out this line of stderr somewhere between those three programs, you patch either of those three programs, or you get rid of the "encrypt-to" setting. Maybe mutt's fcc_clear covers your use case? Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From ilf at zeromail.org Sat Dec 15 18:49:47 2012 From: ilf at zeromail.org (ilf) Date: Sat, 15 Dec 2012 18:49:47 +0100 Subject: mutt message "skipped: public key already present" In-Reply-To: <20121215164443.GA13555@quelltextlich.at> References: <20121214210228.GM15965@zeromail.org> <20121215164443.GA13555@quelltextlich.at> Message-ID: <20121215174947.GO15965@zeromail.org> Christian Aistleitner: >>> skipped: public key already present >>> Press any key to continue. >> How can I disable having to press a key after this message or disable it >> completely? > So if you set encrypt-to to your own key, and Cc to yourself, your key > would be added twice to this list, and GnuPG warns against this. > mutt in turn sees that pgp_encrypt_only_command resulted in some > output on stderr and therefore pauses so you can read the output. > IIRC, mutt does not allow to skip the waiting (as $wait_key does not > apply here). pgpewrap does not allow to mangle stderr. GnuPG does not > allow to turn this logging off. Right. I would like to disable this warning in GnuPG. Back in 2001, Werner Koch said on this list: > I should better output thsoe messages only in verbose mode. http://lists.gnupg.org/pipermail/gnupg-users/2001-May/008354.html Has that ever happened? Does anyone know how to do that? > Maybe mutt's fcc_clear covers your use case? Thanks for that hint. But I prefer keeping mails sent encrypted also encrypted locally. -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From mailinglisten at hauke-laging.de Sun Dec 16 06:03:42 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 16 Dec 2012 06:03:42 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <14410293447.20121215150748@my_localhost> References: <20121212182818.GA7449@phobos.home.sonpro.no> <4265438.anoHMM7euF@inno> <14410293447.20121215150748@my_localhost> Message-ID: <7064600.aJxIxBHWNB@inno> Am Sa 15.12.2012, 15:07:48 schrieb MFPA: > Since key compromise is possible however careful you intend to be, > isn't it better for the non-expiring main key to have the minimum > possible capability set? I don't think that makes sense. There is no general difference between a mainkey and a subkey. Why should there be a difference in the damage whether the one or the other is compromised? The real difference is the security level, at least for those who use offline mainkeys. The security level is the amount of effort by an attacker in order to compromise your key. But why should one prefer a compromised subkey over a compromised mainkey if both are on the same security level? Think of two keys. One everyday key with a highly secure mainkey and one key which is completely kept at high security level. How is a compromised offline mainkey worse that a compromised high security subkey? The practical difference is that probably most people don't have a high security key so limiting the mainkey's capability set limits their options (without increasing security). With a compromised mainkey it shouldn't be a problem to create a certificate with a modified capability set anyway. I don't know how keyservers and GnuPG react to such a change, though. > There is no real limitation here. If a need arose for "higher > security" signing or encryption keys, new subkeys with those > capabilities could be created and circulated, and the secret subkeys > stored offline just like the main key. That's right but makes the whole thing even more complicated ? without explaining what the advantage should be. And complicated is bad as understanding is critical to the practical value of crypto. The concept of a more secure mainkey is relatively commonly known. > > Unfortunately (I don't know the reason for this policy > > difference) the same is true for PIN pads and > > encryption. But for signatures the damage can be > > limited. > > Maybe because encryption uses the public key, so no passphrase or PIN > would be required? That was not precise enough by me. That (I though) obviously referred to decryption. Once unlocked the OpenPGP card does as many decryptions as you want. I do not see any reason for that. It cannot be the precious storage of one more flag. And nobody would be forced to use this feature. > >> > ? add a UID without email (just your name and a > >> > >> comment; this will be > valid > "forever") > > Really? In many countries it is traditional for one or or both > partner(s) to change their name on marriage. That's true for Germany, too, but I would not call such a "depricated" name "invalid". The person can still be identified by the old name. > That strikes me as good advice even if your main key is not stored > offline. In that case it makes sense IMHO only if the certification procedure (for the "real" key) is somewhat complicated because the key owner follows a good certification policy. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From phonetree.oo at gmail.com Mon Dec 17 03:14:49 2012 From: phonetree.oo at gmail.com (Thomas Demers) Date: Sun, 16 Dec 2012 21:14:49 -0500 Subject: Elliptic curves in gnupg status?(ECC support) Message-ID: Hey, I found the discussion in this newsgroup linked to below. It was last posted to in 2010. Looked like ECC support was coming, but as far as I can tell GPG doesn't support ECC yet. Is it on it's way? I was just thinking maybe the messages could be short enough yet moderately secure, to send over SMS, due to the shorter key sizes? You wouldn't get much payload space, but maybe a little? In any case ECC is the way of the future for public key crypto is it not? So it's really a pretty desirable feature. I just found out bitcoin is based on ECC. http://lists.gnupg.org/pipermail/gnupg-users/2010-April/038647.html From johanw at vulcan.xs4all.nl Mon Dec 17 17:04:37 2012 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 17 Dec 2012 17:04:37 +0100 Subject: Elliptic curves in gnupg status?(ECC support) In-Reply-To: References: Message-ID: <50CF4295.20109@vulcan.xs4all.nl> On 17-12-2012 3:14, Thomas Demers wrote: > I was just thinking maybe the messages could be short enough yet > moderately secure, to send over SMS, due to the shorter key sizes? There is an open source Java application that implements ECC public key encryption with SMS: http://cryptosms.org/ (don't mistake it with http://www.cryptosms.com/, which is closed-source and not free). It apears not to have been updated since 2009 though, but it does work on my Nokia Symbian phones. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From gnupg at lists.grepular.com Mon Dec 17 17:17:19 2012 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Mon, 17 Dec 2012 16:17:19 +0000 Subject: Elliptic curves in gnupg status?(ECC support) In-Reply-To: <50CF4295.20109@vulcan.xs4all.nl> References: <50CF4295.20109@vulcan.xs4all.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/12/12 16:04, Johan Wevers wrote: >> I was just thinking maybe the messages could be short enough yet >> moderately secure, to send over SMS, due to the shorter key >> sizes? > > There is an open source Java application that implements ECC public > key encryption with SMS: http://cryptosms.org/ (don't mistake it > with http://www.cryptosms.com/, which is closed-source and not > free). > > It apears not to have been updated since 2009 though, but it does > work on my Nokia Symbian phones. There is also TextSecure for Android, which uses ECC and is still getting regular updates (last commit 9 days ago). It was initially written by Moxie Marlinspike under his company "Whisper Systems", which was later bought out by Twitter. It was released under the GPLv3 and you can get it on github here: https://github.com/WhisperSystems/TextSecure It's also available as a compiled binary on the Google Android Market Place. - -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -----BEGIN PGP SIGNATURE----- iQGGBAEBCgBwBQJQz0WPMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGlu Z0BwZ3AuY29tcGdwbWltZTgUgAAAAAAVABpwa2EtYWRkcmVzc0BnbnVwZy5vcmdt aWtlLmNhcmR3ZWxsQGdyZXB1bGFyLmNvbQAKCRCdJiMBwdHnBHbACADTtTOUaPMd hytm/tp7g97tlLbiEa4KhTwgob/ajdwk58Q02gh8+92zv2pqDSqG4/ioQfMqos8G +owx2D44BesEZR3t9mz6cNs1AxUMaTJA7Uf0gKYlCCd+DtPPDJNix9tcgecEO8ws 3mbihL60gAUTPTekP+qDQTrU11yB8DN+fH/Cd01irYhf/7ZeHXv7zG5G4XUb7iaa Hd8WIzD77uTShu8CXkUlVMHJFXKsGJ80S/qA/bb4WYN11QnTapMX5+NhjyKXfwgH q9plM8kBmjwc2+N7eFeQCDlCLGgzCVTErr1u1pmJiX5I6jxQoyiCLAHdlr6LUel9 PQNQ1WIjG2uv =2VFt -----END PGP SIGNATURE----- From klaus at vink-slott.dk Mon Dec 17 20:46:33 2012 From: klaus at vink-slott.dk (klaus) Date: Mon, 17 Dec 2012 20:46:33 +0100 Subject: Web frontend Message-ID: <6f30bbdee8886276f2890bcce722c598@vink-slott.dk> Hi I am looking for at system to handle signing and verifying documents (not mail) on a document repository on a webserver. I imaging a system who should be able to show the document, and tell who and when it was signed by. It should also enable the user to sign the document by uploading a separate signature file. I am fully aware that a a solution like that can easily be compromised. But it allows the suspicious user to save the document and the signature to files, transfer both to a "known clean" pc and verify the signature. Have anybody build a web front like that? -- Regards Klaus From branko at majic.rs Mon Dec 17 22:44:03 2012 From: branko at majic.rs (Branko Majic) Date: Mon, 17 Dec 2012 22:44:03 +0100 Subject: Web frontend In-Reply-To: <6f30bbdee8886276f2890bcce722c598@vink-slott.dk> References: <6f30bbdee8886276f2890bcce722c598@vink-slott.dk> Message-ID: <20121217224403.02353874@zetkin.int.primekey.se> On Mon, 17 Dec 2012 20:46:33 +0100 klaus wrote: > Hi > > I am looking for at system to handle signing and verifying documents > (not mail) on a document repository on a webserver. I imaging a > system who should be able to show the document, and tell who and when > it was signed by. It should also enable the user to sign the document > by uploading a separate signature file. > > I am fully aware that a a solution like that can easily be > compromised. But it allows the suspicious user to save the document > and the signature to files, transfer both to a "known clean" pc and > verify the signature. > > Have anybody build a web front like that? > It's not OpenPGP-based, but maybe you could have a look at SignServer (http://www.signserver.org/). It's using X.509 certificates. P.S. Small disclaimer - I'm working for PrimeKey, so I don't guarantee I'm not biased. :) -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From expires2012 at rocketmail.com Tue Dec 18 00:37:33 2012 From: expires2012 at rocketmail.com (MFPA) Date: Mon, 17 Dec 2012 23:37:33 +0000 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <7064600.aJxIxBHWNB@inno> References: <20121212182818.GA7449@phobos.home.sonpro.no> <4265438.anoHMM7euF@inno> <14410293447.20121215150748@my_localhost> <7064600.aJxIxBHWNB@inno> Message-ID: <12442906.20121217233733@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 16 December 2012 at 5:03:42 AM, in , Hauke Laging wrote: > With a compromised mainkey it > shouldn't be a problem to create a certificate with a > modified capability set anyway. Yes, I didn't think that through properly. MFPA: >> There is no real limitation here. If a need arose for >> "higher security" signing or encryption keys, new >> subkeys with those capabilities could be created and >> circulated, and the secret subkeys stored offline just >> like the main key. > That's right but makes the whole thing even more > complicated ? without explaining what the advantage > should be. I disagree. What you see as added complication, I see as simplification. Most keys having a single use but one having several uses is more complicated to me than each key having a single use. > And complicated is bad as understanding is > critical to the practical value of crypto. Agreed. > Once unlocked the > OpenPGP card does as many decryptions as you want. I do > not see any reason for that. Convenience. (Which is often the opposite of security.) > I would not call such > a "depricated" name "invalid". The person can still be > identified by the old name. They can, and some people routinely are (such as solicitors who use their former name for work and their current name for non-work matters). But hanging on to the old identity whilst also taking up the new one sends mixed messages and seems like a contradiction. > In that case it makes sense IMHO only if the > certification procedure (for the "real" key) is > somewhat complicated because the key owner follows a > good certification policy. It means a lapse in competence, such as accidentally exporting your local signatures, does not compromise your good certification policy. - -- Best regards MFPA mailto:expires2012 at rocketmail.com Wait. You think I'm right? -----BEGIN PGP SIGNATURE----- iQCVAwUBUM+s2qipC46tDG5pAQrrFAQAsm4aNNztmgSyd/LtszsJ6tnkCoR20rDQ w+XqivqaMQtJLBFqAwDIQItoxEAnCpBGoTb6fYo9hQ/sv3WZ25mqwMXd0WifW0G6 IpFkiT0GhO93aKlIXs12OMTrmQiJ7LfQZWVR5trVao7z7RVQanTcaLmnz7bMzG/e j14QU8Ixwlw= =wsyt -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Dec 18 01:06:07 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 18 Dec 2012 01:06:07 +0100 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <12442906.20121217233733@my_localhost> References: <20121212182818.GA7449@phobos.home.sonpro.no> <7064600.aJxIxBHWNB@inno> <12442906.20121217233733@my_localhost> Message-ID: <3648600.GeDBtTJJqm@inno> Am Mo 17.12.2012, 23:37:33 schrieb MFPA: > > Once unlocked the > > OpenPGP card does as many decryptions as you want. I do > > not see any reason for that. > > Convenience. (Which is often the opposite of security.) No. Allowing(!) you to do so would be convinience. Even making this the default may be considered such. Forcing(!) you to act this way is far from a positive attribute like "convenience". Enforcing a reduction of security is in a security context strange at best. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From expires2012 at rocketmail.com Tue Dec 18 01:28:13 2012 From: expires2012 at rocketmail.com (MFPA) Date: Tue, 18 Dec 2012 00:28:13 +0000 Subject: A few newbie questions, I'am doing this right? In-Reply-To: <3648600.GeDBtTJJqm@inno> References: <20121212182818.GA7449@phobos.home.sonpro.no> <7064600.aJxIxBHWNB@inno> <12442906.20121217233733@my_localhost> <3648600.GeDBtTJJqm@inno> Message-ID: <120795317.20121218002813@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 18 December 2012 at 12:06:07 AM, in , Hauke Laging wrote: > Enforcing a reduction of > security is in a security context strange at best. That is what I meant by observing that convenience is often the opposite of security. It is convenient to not have to lock/unlock doors, just like it is convenient to not have to keep on entering passwords. In both those cases, the price paid for that convenience is a reduction in security. I make no comment about whether it may be a good or a bad thing, since that depends on the threat model. - -- Best regards MFPA mailto:expires2012 at rocketmail.com During an eruption - move away from the volcano - not towards it -----BEGIN PGP SIGNATURE----- iQCVAwUBUM+4pKipC46tDG5pAQqJKgP/RbtxHXImcwzHL9cGAv3cWWkh0YmRz48J j2nG9y8E5wvWEFo1i/UfXrVKAIyqYnHrDUNlRJkPt+MB5ucQbD8aQwtr/udDrqNN Nf0xtYcozwIWbI7ddJeqePUgLtrkT7WQD61rtnxrDP0I1ZU64Rhna8q/ea5R3oHY ajbK5c2vF7g= =zmAK -----END PGP SIGNATURE----- From wk at gnupg.org Tue Dec 18 11:00:15 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Dec 2012 11:00:15 +0100 Subject: Elliptic curves in gnupg status?(ECC support) In-Reply-To: (Thomas Demers's message of "Sun, 16 Dec 2012 21:14:49 -0500") References: Message-ID: <87fw333ck0.fsf@vigenere.g10code.de> On Mon, 17 Dec 2012 03:14, phonetree.oo at gmail.com said: > Hey, I found the discussion in this newsgroup linked to below. It > was last posted to in 2010. Looked like ECC support was coming, but > as far as I can tell GPG doesn't support ECC yet. Is it on it's way? It is supported since 2.1.0beta2 (2011-03-08) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Tue Dec 18 20:13:06 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 18 Dec 2012 20:13:06 +0100 Subject: mutt message "skipped: public key already present" In-Reply-To: <20121215174947.GO15965@zeromail.org> References: <20121214210228.GM15965@zeromail.org> <20121215164443.GA13555@quelltextlich.at> <20121215174947.GO15965@zeromail.org> Message-ID: <20121218191305.GA21994@quelltextlich.at> Hi ilf, On Sat, Dec 15, 2012 at 06:49:47PM +0100, ilf wrote: > Christian Aistleitner: > >>> skipped: public key already present > > [ 2001 quote of Werner Koch wanting to output those lines only in > verbose mode ] > > Has that ever happened ? Not that I know of. > Does anyone know how to do that? Either compile GnuPG yourself after applying the patch from http://lists.gnupg.org/pipermail/gnupg-devel/2012-December/027216.html ... or bribe someone with commit access to push it and wait for a new GnuPG release. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From phonetree.oo at gmail.com Tue Dec 18 20:21:21 2012 From: phonetree.oo at gmail.com (Thomas Demers) Date: Tue, 18 Dec 2012 14:21:21 -0500 Subject: Elliptic curves in gnupg status?(ECC support) Message-ID: I was not able to find anything in the manual about it though. I searched and searched for the details on how to get on with using it, can't find them anywhere. I mean included and useable in the main release as a tool to move ahead with... ----- Original Message ----- From: "Werner Koch" To: Thomas Demers , gnupg-users at gnupg.org Date: Tue, Dec 18, 2012 at 5:00 AM Subject: Elliptic curves in gnupg status?(ECC support) > On Mon, 17 Dec 2012 03:14, phonetree.oo at gmail.com said: > > Hey, I found the discussion in this newsgroup linked to below. It > > was last posted to in 2010. Looked like ECC support was coming, but > > as far as I can tell GPG doesn't support ECC yet. Is it on it's way? > > It is supported since 2.1.0beta2 (2011-03-08) > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From patch at cs.ucsb.edu Wed Dec 19 05:29:05 2012 From: patch at cs.ucsb.edu (Patrick Baxter) Date: Tue, 18 Dec 2012 20:29:05 -0800 Subject: [guardian-dev] WOT and Authentication Research In-Reply-To: <50C441AF.9090707@riseup.net> References: <50C441AF.9090707@riseup.net> Message-ID: Thanks for the response! I'm glad you have similar interests in this. I have some responses inline: On Sat, Dec 8, 2012 at 11:45 PM, elijah wrote: > If I read correctly, a few of your main points are: > > (1) We need well defined and expanded trust metrics > (2) Everything would be better if we enforced a 1:1 mapping of public > keys and UIDs (e.g. alice at example.org) > (3) There are many different behaviors users engage in that demonstrate > trust, and many different cryptographic formats this can take. Why not > combine them in order to build a much more complete sense of trust? > I think that is a really good summary. I could also divide this into two goals, by stating. 1) We must improve the ability for anyone to participate in end-to-end encryption WITH strong authentication: a. This means leveraging many different social interactions and protocols that can capture key validation. b. Improved ability to manage a private key c. When possible, rely less on public key servers. 2) Must create a flexible standard for a public data structure that enforces this one-to-one mapping: a. It needs to balance the flexibility and usability tradeoff intelligently. b. Least possible authority c. Is adaptable to different types of identities d. "Trust agnostic" e. Keys can be duplicated among multiple types of identities. Use this to opportunistically to increase ability to enforce and update mapping by using the validations from each domain > If I understand correctly, another way to think of this same problem is > in terms of Zooko's triangle: > *snip* Agreed! > Essentially, I think the goal is decentralized human > memorable public keys. No one wants to type an OpenPGP fingerprint as a > destination address! Agreed as well, having a key to encrypt and sign should be a natural thing to possess for every UID you have. People shouldn't have to think much about keys, but can probably understand it as a password that must be physically available. "you are using an unsecure connection on this login because you do not have access to your password" > I probably missed a few, but it is a good starting list. Ideas that rely > on a single central authority are excluded. As a side, unless you consider something like Sovereign Keys a centralized solution, I'd actually make the argument AGAINST federation. Rather, I think having a single 'centralized structure' that is replicated under distributed control is more desirable. Federation puts a single authority in place of a certain group of people. A central solution controlled by varying groups arguably must be more accountable and must collude to violate user's trust. Still, a key server should only be responsible for keeping track of valid mappings. A user can do that on their own to varying degrees and accept changes in identity only if they want. Ultimately, keyservers must still present valid user signatures to be validated by a user. > WOT: Alone, the current approach to WOT has problems with usability, > reachability, and what exactly counts as trust. Despite this, it works. > In my mind, however, WOT should not be considered as the primary method > of proof of control if the signatures are made public. Otherwise, the > user has exposed their entire social graph--data that can be more > sensitive in many cases than even the content of communication. WOT > might be very useful in modified form and in conjunction with other > schemes. Systems for automating key signing with mobile devices could > make WOT more practical in the real world. This can be a tough trade off. I am aware of the problem of exposing social graphs thanks to William Binney. This is partially a different problem then solving authentication, but it matters to most people. However, I think anonymity is better solved in other ways that don't cost us the ability to make public signatures. Too many things expose you social graph to make it worth it to not publish signatures. 1) Exposing your social graph as a list of people you've signed isn't as problematic as the real-time data of how often you contact a person, when, and what location is associated with that communication link. 2) All that real-time information is still exposed for the time being. When you email someone you will never encrypt the headers and so hiding signatures is a moot point until a general anonymous routing is fully in place. Even hiding your IP with Tor won't help this since you exit to the general internet and still expose you headers. Unless some sort of anonymity system for each type of communication is made or a general darknet replacement for the Internet becomes viable I don't see this going away. CJDNS seems like a promising idea. 3) I think the correct way to obtain anonymity/privacy would be to use strict psuedonyms that are only accessed/created over something that anonymizes your TCP/IP layer (Tor). This way you may still expose you social graph, but if you always use encryption, that pseudonym should be able to fully separate from your 'real' identity you wish to protect. Definitely not perfect though. 4) Without making public signatures, third parties really can't help authenticate you and you are left with a fully distributed system or a system that completely relies on third parties to authenticate you. If going the distributed route it would look similar to GPG without the keyservers. This works locally, but anytime you need to authenticate with a person you haven't met, you most likely don't have a path to that person. 5) Since this is such a small scope of the anonymity problem you could almost label it as a privacy problem. One alternative is to send signatures to the person you signed and let them choose to publish them. This way no one publishes that they signed your key unless you are OK with it. > DNSSEC: There are RFCs for discovery of user's public keys via DNS, > could be use with DNSSEC... If you love the idea of putting trust in the > domain name system. Ugh. It seems necessary and inevitable to work with DNSSEC for the time being. Its been in the making for so long and if DNSSEC provides at least some faith in which keys belong to which domains then that may be useful as another authority to help enforce an initial mappings in the DNS world. Convergence and Sovereign Keys both provide methods for relying on this. > Biometric Feedback: In synchronous communication, you can use non-verbal > clues (like the sound of someone's voice) for both parties to mutually > validate identities (when used in combination with a challenge, like in > ZRTP). > Shared Secret Yes! I think this type of stuff is really fascinating. The more valid protocols like this that are available to people, The more people can sign keys with out knowing precisely whats going on. If using a WOT this means more paths. If you just collect signatures, this means a stronger consensus on a mapping. > Mail-back Verification: > Network Perspective: > Authority Binding: Agreed, all good things! > Federated WOT: Rather than force users to practice good WOT hygiene, the > idea with a Federated WOT is to force service providers to do proper > key-signing and then have service providers sign the keys of their > users. This allows for end-to-end WOT trust path without exposing the > social graph, although it requires cooperation from the service > providers (but not faith in them, see network perspective). Interesting Idea! This puts some structure on the WOT. I'm not sure though. Could a single federated structure corrupt/MITM a path for one of its users? > I have labeled what I think you are proposing "Trust Agnosticism". No > doubt, you have a better name, but I needed something to call it > something for the purpose of this email. I have no better name, thats as good as any :) > I agree with #1 and #2, but ultimately have some reservations about > parts of #3. > I absolutely agree that some linkage between different key formats would > be a big improvement, as proposed by PSST. As for improving the WOT by > including different sources of linkages, ultimately I think the WOT is a > dead end for the use cases that many of us would like to support. > > Specifically: > > (1) To be useful, a WOT exposes a user's social graph. See the other response about this above. > (2) In order to address the rapid rise of mass surveillance, in either > repressive or democratic contexts, we need to dramatically increase the > rate of adoption of end-to-end message encryption. I think there is a > lot of evidence that current schemes are too complex (since so few > people use them correctly). My claim is that this complexity cannot be > fixed with better tools, but is a problem in the inherent conceptual > complexity of OpenPGP and OTR, etc. A lot of people will take issue with > that last statement, but these people have probably never tried to get > activists in the field to use existing secure communication tools > correctly and consistently. But our goal cannot just be to achieve > adoption among people who are motivated enough to pay a privacy-tax. To > be effective against mass-surveillance, we must work to reduce the > privacy-tax to nothing. Most definitely. I think the accessibility is what is really interesting about LEAP. However, I still think you can make a WOT usable by updating our keyserver structure and changing the end-user software to be a better experience. Remove trust decisions and automatically capture signatures through some of the aforementioned things. I'm not convinced the WOT is bad, but its still a bit open as to the correct way to use it. I like the idea of preserving the ability for users to authenticate without any trust in a third party when possible. > We are early in our design and coding process, and would absolutely love > to dialog and collaborate with other people interested in this problem > space. Depending on what funding we are able to put together, our work > in this area may progress faster or slower. Cool stuff, lets keep up the dialog! -Patrick From ricul77 at gmail.com Wed Dec 19 11:03:49 2012 From: ricul77 at gmail.com (Richi Lists) Date: Wed, 19 Dec 2012 11:03:49 +0100 Subject: Same key on different smart cards In-Reply-To: <1984739.xfj0eWKZZh@inno> References: <1355384633.2868.8.camel@onenc> <1984739.xfj0eWKZZh@inno> Message-ID: <1355911429.3396.17.camel@onenc> Ok, let me try to explain my problem/wish a bit more elaborate. I have a smart card (crypto-stick) where my private sub-keys are stored for signing emails and debian packages, decrypting emails and authenticating ssh. I have multiple computers that are set up to use this smart card for all these tasks. My notebook also has full disk encryption set up to use the decryption key on that smart card to decrypt the luks key in the init ramdrive. So far so good. But now I'm afraid of what happens if my smart card breaks or I loose it. So, I prepared another smart card with the exact same sub keys in the hope to use both smart cards seamlessly interchangeable. As you just told me, I have to delete the stubs and prepare for the other card. That sounds good enough for the signing, email decryption and ssh tasks. It's a bit more work intensive for the full disk encryption part. And it's not really what I had in mind with seamlessly interchangeable. Now, another solution would be to have different keys on the cards, so I didn't have to delete the stubs each time I switch the smart card. This would work well for the full disk encryption and ssh part. But for the signing and email decryption part, that would now be two different identities. I hope my intents are a bit clearer now. Rgds Richard On Do, 2012-12-13 at 10:43 +0100, Hauke Laging wrote: > Am Do 13.12.2012, 08:43:53 schrieb Richi Lists: > > > But as far as I understand, for eMail signing and decryption, it needs > > to be the same key on all cards. > > I have not checked that but I don't think so. Wouldn't make sense. When using > key A, why should gpg-agent care, where key B is stored? > > > > I set up two crypto sticks to contain the same sub keys. But the unique > > id of the card seems to be stored in the private key stub > > (~/.gnupg/secring.gpg). Thus if I try to use the second card, I get an > > error telling me to insert the correct card. > > What do you want? The signing key on one smartcard, the decryption key on the > other? If so, why have you stored both keys on the same card? > > > > Is it possible to manage the same identity with multiple smart cards? > > That is a different problem. This is not directly supported by GnuPG but > possible by a workaround: After changing the smartcard you can delete the > secret keys and register the smartcard afterwards. Then the card reference is > "updated". > > > Hauke From ricul77 at gmail.com Wed Dec 19 11:08:37 2012 From: ricul77 at gmail.com (Richi Lists) Date: Wed, 19 Dec 2012 11:08:37 +0100 Subject: smart card OpenId Message-ID: <1355911717.3396.21.camel@onenc> Has anybody here used an OpenPGP card for authenticating OpenId? There are lots of options on http://www.crypto-stick.com/en/certificate-authentication And browsing them branches into even more options, and at some point I lose track of the link to OpenPGP cards. So, If anybody uses such a setup, I would be glad to know which route you took. Rgds Richard From ilf at zeromail.org Wed Dec 19 17:47:53 2012 From: ilf at zeromail.org (ilf) Date: Wed, 19 Dec 2012 17:47:53 +0100 Subject: mutt message "skipped: public key already present" In-Reply-To: <20121218191305.GA21994@quelltextlich.at> References: <20121214210228.GM15965@zeromail.org> <20121215164443.GA13555@quelltextlich.at> <20121215174947.GO15965@zeromail.org> <20121218191305.GA21994@quelltextlich.at> Message-ID: <20121219164753.GA23723@zeromail.org> Christian Aistleitner: > http://lists.gnupg.org/pipermail/gnupg-devel/2012-December/027216.html > ... or bribe someone with commit access to push it and wait for a new > GnuPG release. Thanks a lot! Werner pushed something like it (swapping --quiet and non --verbose) here: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=8325d616593187ff227853de0295e3269b96edcb -- ilf ?ber 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes f?r Tastaturbenutzung -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From klaus at vink-slott.dk Wed Dec 19 18:20:41 2012 From: klaus at vink-slott.dk (Klaus Vink Slott) Date: Wed, 19 Dec 2012 18:20:41 +0100 Subject: Web frontend In-Reply-To: <20121217224403.02353874@zetkin.int.primekey.se> References: <6f30bbdee8886276f2890bcce722c598@vink-slott.dk> <20121217224403.02353874@zetkin.int.primekey.se> Message-ID: <50D1F769.4020502@vink-slott.dk> Den 17-12-2012 22:44, Branko Majic skrev: > On Mon, 17 Dec 2012 20:46:33 +0100 klaus > wrote: > >> I am looking for at system to handle signing and verifying >> documents (not mail) on a document repository on a webserver.... >> Have anybody build a web front like that? > > It's not OpenPGP-based, but maybe you could have a look at > SignServer (http://www.signserver.org/). It's using X.509 > certificates. Hmm.. Although The Signserver project seems very interesting I have difficult to see what it really does. I think I was searching for something more simple. -- Klaus From wk at gnupg.org Thu Dec 20 19:02:00 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2012 19:02:00 +0100 Subject: Elliptic curves in gnupg status?(ECC support) In-Reply-To: (Thomas Demers's message of "Tue, 18 Dec 2012 14:21:21 -0500") References: Message-ID: <87mwx8txev.fsf@vigenere.g10code.de> On Tue, 18 Dec 2012 20:21, phonetree.oo at gmail.com said: > I was not able to find anything in the manual about it though. I > searched and searched for the details on how to get on with using it, $ gpg2 --expert --gen-key gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECDSA and ECDH (10) ECDSA (sign only) (11) ECDSA (set your own capabilities) Your selection? We have always used the expert switch to allow the use of new algorithms. The idea is that we first want to have a wide base of installed versions with support for a given algorithms, before we make a new algorithm visible to the non-experts. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rmartinez at netcontac.com Thu Dec 20 20:32:50 2012 From: rmartinez at netcontac.com (Roberto) Date: Thu, 20 Dec 2012 13:32:50 -0600 Subject: Unable to run GPG from PHP gpg: WARNING: unsafe ownership on homedir Message-ID: Hi, I made and script in PHP to encrypt information with GPG. It works fine until I move it from a Plesk server to a cPanel server. I adjusted paths, permissions and users but I get this errors: gpg: keyblock resource `/home/USER/.gnupg/pubring.gpg': General error gpg: failed to create temporary file `/home/USER/.gnupg/.#lk0x9b1b580.HOST.1614': Permission denied gpg: keyblock resource `/home/USER/.gnupg/secring.gpg': General error gpg: failed to create temporary file `/home/USER/.gnupg/.#lk0x9b1b580.HOST.1614': Permission denied gpg: WARNING: unsafe ownership on homedir `/home/USER/.gnupg' Where: USER is the same user in Plesk (Where it works) than in cPanel. HOST is the name of the host server. Here is the PHP script: $message = "Message"; $gnupg = "/usr/bin/gpg"; $gnupghome = "/home/USER/.gnupg"; $uid = "UID"; $command = "echo ". $message ." | ". $gnupg ." -a -t --batch --no-secmem-warning --homedir ". $gnupghome ." -e -r ". $uid ." --compress-algo 1 --cipher-algo cast5"; $messageCodified = shell_exec($command); I am missing something obvious, but I can not tell. I tried a lot of configurations without success. Please help. Kind Regards, Roberto From wk at gnupg.org Thu Dec 20 21:20:32 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2012 21:20:32 +0100 Subject: [Announce] GnuPG 1.4.13 released Message-ID: <87d2y4tqzz.fsf@vigenere.g10code.de> Hello! 15 years after the first release we are now pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.13. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.19) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Add support for the old cipher algorithm IDEA. * Minor bug fixes. * Small changes to better cope with future OpenPGP and GnuPG features. Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.13 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.13.tar.bz2 (3599k) gnupg-1.4.13.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.13.tar.gz (4966k) gnupg-1.4.13.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.12-1.4.13.diff.bz2 (284k) A patch file to upgrade a 1.4.12 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.13.exe (1557k) gnupg-w32cli-1.4.13.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.13.tar.bz2 you would use this command: gpg --verify gnupg-1.4.13.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 1CE0C630 is signed by the well known keys 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.13.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.12.tar.bz2 and check that the output matches the first line from the following list: 17a75c54d292bd0923f0a1817a1b02ded37d1de1 gnupg-1.4.13.tar.bz2 9f2696f3b61cb771053db599e884952c80d2a6e7 gnupg-1.4.13.tar.gz ba200314de0e6e4fc507a16da96261f22e3b0874 gnupg-1.4.12-1.4.13.diff.bz2 852666756ae96dee667eccdd619689c18d662b4a gnupg-w32cli-1.4.13.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dkg at fifthhorseman.net Thu Dec 20 21:48:51 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Dec 2012 15:48:51 -0500 Subject: Unable to run GPG from PHP gpg: WARNING: unsafe ownership on homedir In-Reply-To: References: Message-ID: <50D379B3.4020108@fifthhorseman.net> Hi Roberto! On 12/20/2012 02:32 PM, Roberto wrote: > I made and script in PHP to encrypt information with GPG. It works fine > until I move it from a Plesk server to a cPanel server. I adjusted > paths, permissions and users but I get this errors: is your web server user running as the same user account you expect it to be? often, on shared servers, the web server runs as www-data or some other user. Fortunately, www-data does not have write privileges inside other users' gnupg home directories. And making ~/.gnupg writable by www-data would open your account up to a whole new level of other problems if anyone else can write scripts that run as the web server user. I suspect what you want is to get the web server to run as a dedicated user specifically for your account. I don't know how to do that from within cpanel (and i'm sure you can find a better cpanel forum than gnupg-users). > $command = "echo ". $message ." | ". $gnupg ." -a -t --batch --no-secmem-warning --homedir ". $gnupghome ." -e -r ". $uid ." --compress-algo 1 --cipher-algo cast5"; I understand that this is a test script, so i will not enumerate the ways in which the above can go horribly wrong if any of the relevant variables are replaced by user-supplied data. I just hope you don't plan on using anything like this in production. Shell script injection vulnerabilities are bad news. Do the above explanations and concerns make sense? Good luck with your project! Regards, --dkg From rmartinez at netcontac.com Thu Dec 20 22:56:51 2012 From: rmartinez at netcontac.com (Roberto Martinez) Date: Thu, 20 Dec 2012 15:56:51 -0600 Subject: Unable to run GPG from PHP gpg: WARNING: unsafe ownership on homedir In-Reply-To: <50D379B3.4020108@fifthhorseman.net> References: <50D379B3.4020108@fifthhorseman.net> Message-ID: > Hi Roberto! > > On 12/20/2012 02:32 PM, Roberto wrote: >> I made and script in PHP to encrypt information with GPG. It works fine >> until I move it from a Plesk server to a cPanel server. I adjusted >> paths, permissions and users but I get this errors: > > is your web server user running as the same user account you expect it > to be? Yes However, certainly I am missing something. If you suggest a check list, it would make me very happie. often, on shared servers, the web server runs as www-data or > some other user. Fortunately, www-data does not have write privileges > inside other users' gnupg home directories. And making ~/.gnupg > writable by www-data would open your account up to a whole new level of > other problems if anyone else can write scripts that run as the web > server user. > > I suspect what you want is to get the web server to run as a dedicated > user specifically for your account. I don't know how to do that from > within cpanel (and i'm sure you can find a better cpanel forum than > gnupg-users). > >> $command = "echo ". $message ." | ". $gnupg ." -a -t --batch >> --no-secmem-warning --homedir ". $gnupghome ." -e -r ". $uid ." >> --compress-algo 1 --cipher-algo cast5"; > > I understand that this is a test script, so i will not enumerate the > ways in which the above can go horribly wrong if any of the relevant > variables are replaced by user-supplied data. I just hope you don't > plan on using anything like this in production. Shell script injection > vulnerabilities are bad news. You are right, I simplify the command for testing purposes, but again, any security advice is welcome. > > Do the above explanations and concerns make sense? > > Good luck with your project! > > Regards, > > --dkg From mailinglisten at hauke-laging.de Thu Dec 20 23:04:47 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 20 Dec 2012 23:04:47 +0100 Subject: signature state wording: good, valid, trusted Message-ID: <5874313.3o7rGdyzOc@inno> Hello, I just tried to check what the "correct" (i.e. established) wording for the difference between successful signature validation and the (trust related) validity of the signing key is. My guess was "correct signature" vs. "valid signature". I had a look at the /usr/share/doc/packages/gpg2/DETAILS file. And now I am confused. It says that both GOODSIG and VALIDSIG refer to the success of the purely technical signature validation with the public key. So "valid" in the context of signatures seems to mean something different from "valid" in the context of keys. Which is not good in general but however. The I read in that file: ################################# TRUST_UNDEFINED TRUST_NEVER TRUST_MARGINAL [0 []] TRUST_FULLY [0 []] TRUST_ULTIMATE [0 []] For good signatures one of these status lines are emitted to indicate the validity of the key used to create the signature. ################################# which is coherent to what I wrote above. But at the end of that block it says: ################################# Note that we use the term "TRUST_" in the status names for historic reasons; we now speak of validity. ################################# OMG. Now the term "valid" / "validity" refers to both verification success and the trust state of the signing key? I guess that is really bad in terms of understanding. And the whole OpenPGP subject is already hard enough to understand for new users. I am writing information documents for new users thus I am very interested in getting this right. The best explaination for all I know now (and have stated above) is that the term VALIDSIG simply was quite a bad choice (but impossible to change) and that "valid" ? despite of the exception VALIDSIG ? is used for the trust state both with keys and with signatures. So we have (besides bad and expires signatures, of course) "good" signatures which can be "valid" signatures. Can you confirm this? BTW: It is probably not a GnuPG specific term but I consider "ownertrust" to be a bad choice, too, because it simply isn't that. The value is key dependant and may vary between keys with the same owner (due to the key's security level or the respective key's certification policy). Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From gnupg-users at spodhuis.org Fri Dec 21 00:23:19 2012 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Thu, 20 Dec 2012 18:23:19 -0500 Subject: OT: "PGP Keyservers" Google+ Community Message-ID: <20121220232319.GA67837@redoubt.spodhuis.org> [ Somewhat, but not completely, off-topic. ] Hey, if anyone here cares about the sorts of people who care about PGP Keyservers, and if you use Google+, then there's now a G+ Community which will help you find others with tastes as strange as yours. ;) I've created "PGP Keyservers", tagline "Public keys, public". The About section reads: PGP software typically retrieves PGP keys from keyservers. This community is for people who care about such things. SKS, PKS, Hockeypuck, and more. Direct link: https://plus.google.com/communities/104994356174608794654 or redirector: http://gplus.to/keyservers Regards, -Phil, occasional SKS coder and pesterer of GnuPG devs on HKP issues From laurent.jumet at skynet.be Fri Dec 21 06:56:30 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Fri, 21 Dec 2012 06:56:30 +0100 Subject: GnuPG 1.4.13 released In-Reply-To: <87d2y4tqzz.fsf@vigenere.g10code.de> Message-ID: Hello Werner ! Werner Koch wrote: > 15 years after the first release we are now pleased to announce the > availability of a new stable GnuPG-1 release: Version 1.4.13. > What's New > =========== > * Add support for the old cipher algorithm IDEA. So, that means that we don't need any more the load-extension idea.dll in the gpg.conf Am I right? -- Laurent Jumet KeyID: 0xCFAF704C From laurent.jumet at skynet.be Fri Dec 21 08:34:10 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Fri, 21 Dec 2012 08:34:10 +0100 Subject: Manual... Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello ! Here you can download the manual digest for GnuPG 1.4.13 in a 12 pages convenient mode for printing: In PDF: http://www.pointdechat.net/MyMan_GnuPG-1413.pdf In .DOC: http://www.pointdechat.net/MyMan_GnuPG-1413.doc (In doubt, look in gpg.man) - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iHEEAREDADEFAlDUEqoqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMHeAAoPE5Pr02Es94rNubbhd4k/9UVbkmAKCD XLLSIrpwLxaYy/LxECzDJwpCQA== =Dbo/ -----END PGP SIGNATURE----- From johanw at vulcan.xs4all.nl Fri Dec 21 11:56:10 2012 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 21 Dec 2012 11:56:10 +0100 Subject: GnuPG 1.4.13 released In-Reply-To: References: Message-ID: <50D4404A.5080507@vulcan.xs4all.nl> On 21-12-2012 6:56, Laurent Jumet wrote: > So, that means that we don't need any more the > > load-extension idea.dll > > in the gpg.conf > Am I right? Indeed. Is the IDEA patent expired or so, that this algorithm is now included? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Fri Dec 21 12:18:11 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Dec 2012 12:18:11 +0100 Subject: GnuPG 1.4.13 released In-Reply-To: <50D4404A.5080507@vulcan.xs4all.nl> (Johan Wevers's message of "Fri, 21 Dec 2012 11:56:10 +0100") References: <50D4404A.5080507@vulcan.xs4all.nl> Message-ID: <87bodnslfw.fsf@vigenere.g10code.de> On Fri, 21 Dec 2012 11:56, johanw at vulcan.xs4all.nl said: > Indeed. Is the IDEA patent expired or so, that this algorithm is now > included? * Patents on IDEA have expired: * Europe: EP0482154 on 2011-05-16, * Japan: JP3225440 on 2011-05-16, * U.S.: 5,214,703 on 2012-01-07. IDEA is now included to get rid of all the questions from folks either trying to decrypt old data or migrating keys from PGP to GnuPG. It is more or less a read-only algorithm, in that it won't go into the key preferences of new keys by default. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Sun Dec 23 13:01:25 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 23 Dec 2012 12:01:25 +0000 Subject: OpenPGP Authentication Protocol? Message-ID: Dear List, Is there a protocol documented anywhere for using PGP Keys for client-server authentications? I assume that various naive approaches have all sorts of serious problems. Best wishes, N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlisten at hammernoch.net Sun Dec 23 15:01:38 2012 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sun, 23 Dec 2012 15:01:38 +0100 Subject: [Announce] GnuPG 1.4.13 released In-Reply-To: <87d2y4tqzz.fsf@vigenere.g10code.de> References: <87d2y4tqzz.fsf@vigenere.g10code.de> Message-ID: <50D70EC2.8000305@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On 20.12.12 21:20, Werner Koch wrote: > Hello! > > 15 years after the first release we are now pleased to announce > the availability of a new stable GnuPG-1 release: Version 1.4.13. Thanks! I'm having linker errors on Mac OS 10.8.2 regarding iconv/libiconv: ./configure && make results in: Undefined symbols for architecture x86_64: "_iconv", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) "_iconv_close", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) "_iconv_open", referenced from: _utf8_to_native in libutil.a(strgutil.o) _native_to_utf8 in libutil.a(strgutil.o) _set_native_charset in libutil.a(strgutil.o) __nl_find_msg in libintl.a(dcigettext.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [gpg] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ./configure --disable-gnupg-iconv && make results in: Undefined symbols for architecture x86_64: "_iconv", referenced from: __nl_find_msg in libintl.a(dcigettext.o) "_iconv_open", referenced from: __nl_find_msg in libintl.a(dcigettext.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [gpg] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Compiler is: gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Usage of clang instead of gcc doesn't make a difference. Could somebody please help me? Thanks! Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJQ1w7CAAoJEA52XAUJWdLjozIH/Rug8DsTD4gSX43XLSM5h6Dw yjmDBER0WcTwiAtxyU/GfRxYQxEJbKU93M288BSiFBTpkaPBYso8k057nEZnr1tv 1VIJ8N5Ds/fiw7EUmpfVY9yNZupxHS/hFXIclaWo5TPM/GRTFrUQ3bPhWZrwRt8L 1TkUE12mlwnzqBLP6f6bVyGQPOTv5/x5Fcnpzv+APtzK4wKTyG3qWr+xwxZoTX2f u7B3pU/Vnjl1CdTKsGS/dB6hwMHFnxTtnoKLQE0bba3pjkrejL3oLB/d2w9H8DCm owO/SWQ5tH/DMlGWhisKoe8cS/beP+IUBQmP6tkW7nm3Lorc6Z3m7PqB6UrH9+k= =atBH -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Dec 23 17:11:13 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 23 Dec 2012 11:11:13 -0500 Subject: OpenPGP Authentication Protocol? In-Reply-To: References: Message-ID: <50D72D21.7080405@sixdemonbag.org> On 12/23/2012 7:01 AM, Nicholas Cole wrote: > Is there a protocol documented anywhere for using PGP Keys for > client-server authentications? I assume that various naive > approaches have all sorts of serious problems. Sure, but most of these documented protocols have all sorts of serious problems, too: most of them are painfully ad-hoc. If you mean a protocol that's undergone peer review and is considered by the community to be a best practice, then no, I'm unaware of any. If you're able to come up with one I hope you'll share it with the rest of us! From mailinglisten at hauke-laging.de Sun Dec 23 19:23:42 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 23 Dec 2012 19:23:42 +0100 Subject: OpenPGP Authentication Protocol? In-Reply-To: References: Message-ID: <7180127.sdu3Hi5870@inno> Am So 23.12.2012, 12:01:25 schrieb Nicholas Cole: > Is there a protocol documented anywhere for using PGP Keys for client-server > authentications? SSH? :-) -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From shavital at gmail.com Sun Dec 23 19:04:14 2012 From: shavital at gmail.com (Charly Avital) Date: Sun, 23 Dec 2012 13:04:14 -0500 Subject: [Announce] GnuPG 1.4.13 released In-Reply-To: <50D70EC2.8000305@hammernoch.net> References: <87d2y4tqzz.fsf@vigenere.g10code.de> <50D70EC2.8000305@hammernoch.net> Message-ID: <50D7479E.7070600@gmail.com> Ludwig H?gelsch?fer wrote on 12/23/12 9:01 AM: [...] > Could somebody please help me? Thanks! > > Ludwig Hi Ludwig, here's copy of the message I sent to Werner only without including the list, my bad: > Werner Koch wrote on 12/20/12 3:20 PM: >> Hello! >> >> 15 years after the first release we are now pleased to announce the >> availability of a new stable GnuPG-1 release: Version 1.4.13. > > [...] > >> >> gpg --verify gnupg-1.4.13.tar.bz2.sig > > Verifies. > > [...] > > >> Thanks >> ====== >> >> We have to thank all the people who helped with this release, be it >> testing, coding, translating, suggesting, auditing, donating money, >> spreading the word, or answering questions on the mailing lists. >> >> >> Happy Hacking, >> >> The GnuPG Team (David, Werner and the other contributors) > Version info: gnupg 1.4.13 > Configured for: Darwin (x86_64-apple-darwin12.2.0) > > $ gpg --version > gpg (GnuPG) 1.4.13 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > 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, CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > ==================== > > Thank you Werner. > Charly > -------------------------- When compiling from source, I didn't experiment any problem. Best regards, Charly 0x15E4F2EA Mac OS X 10.8.2 (12C54) MacBook Intel C2Duo 2GHz. GnuPG v2.0.19 (Darwin) - gpg (GnuPG) 1.4.13 TB 17.0 Enigmail 1.4.6 (20121105-0019) From mlisten at hammernoch.net Sun Dec 23 21:02:23 2012 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sun, 23 Dec 2012 21:02:23 +0100 Subject: [Announce] GnuPG 1.4.13 released In-Reply-To: <50D70EC2.8000305@hammernoch.net> References: <87d2y4tqzz.fsf@vigenere.g10code.de> <50D70EC2.8000305@hammernoch.net> Message-ID: <50D7634F.6060604@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On 23.12.12 15:01, Ludwig H?gelsch?fer wrote: > Undefined symbols for architecture x86_64: "_iconv" (...) Temporarily moving /opt out of the way did solve the issue. Not sure what gpg configure script found there which was not usable as intended. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJQ12NPAAoJEA52XAUJWdLjj9wH/Ai5O/OVUVYdAevuJ9kooFYj 7Az8/uGynB26tD+bLTz2cTWU0ua4cxJB6QZ/1wIZCDwIxleFgI6FTDO02x2JSiXo b4T9DZZVfzmqVxqf8zr9Giq3IlYXJ20QpWAQHxvOIhmD5LAnguQzVoODAA7uoO/T oKDFdkajPyHZdma4bTY9IMUdNfseql8IpJpOvbtuWhFM+VENci6818bmM6yVZ3Tl TCec3uoDdNwDHsS8IeDKkcXNVHmrKi27tMB3pIm24/L/yCW97a/nj7t/QTipoCcj bKa6I1ATzPmag9JAfQLiOkubiXU5CLXuxaueigXXLoa3dW3OwzlrlvxxndfCcsw= =0vcB -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sun Dec 23 22:31:01 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 23 Dec 2012 16:31:01 -0500 Subject: OpenPGP Authentication Protocol? In-Reply-To: <7180127.sdu3Hi5870@inno> References: <7180127.sdu3Hi5870@inno> Message-ID: <50D77815.5080908@fifthhorseman.net> On 12/23/2012 01:23 PM, Hauke Laging wrote: > Am So 23.12.2012, 12:01:25 schrieb Nicholas Cole: > >> Is there a protocol documented anywhere for using PGP Keys for client-server >> authentications? > > SSH? :-) the ssh specification declares the use pgp-style certificates: https://tools.ietf.org/html/rfc4253#section-6.6 but does little to indicate how peers should consider them for authentication purposes. the majority of OpenPGP-verified ssh connections in use on the net today are probably using raw keys on the wire, but certifying them out-of-band via tools like the Monkeysphere. RFC 6091 documents a mechanism for using OpenPGP certificates as peer endpoints for a TLS session. http://tools.ietf.org/html/rfc6091 But similarly to the ssh situation, it may be simpler to pass "dummy" public key placeholders (e.g. those that are well-formed X.509 certificates) and do the conversion to OpenPGP certificates on the backend/out of band. --dkg From mailinglisten at hauke-laging.de Sun Dec 23 22:42:20 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 23 Dec 2012 22:42:20 +0100 Subject: OpenPGP Authentication Protocol? In-Reply-To: <50D77815.5080908@fifthhorseman.net> References: <7180127.sdu3Hi5870@inno> <50D77815.5080908@fifthhorseman.net> Message-ID: <1716504.shBFhxGtMd@inno> Am So 23.12.2012, 16:31:01 schrieb Daniel Kahn Gillmor: > the ssh specification declares the use pgp-style certificates: > > https://tools.ietf.org/html/rfc4253#section-6.6 > > but does little to indicate how peers should consider them for > authentication purposes. Is that different from "pure" SSH keys or even X.509 client certificates? Why should a session protocol define which keys a user should trust? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Sun Dec 23 23:17:35 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 23 Dec 2012 17:17:35 -0500 Subject: OpenPGP Authentication Protocol? In-Reply-To: <1716504.shBFhxGtMd@inno> References: <7180127.sdu3Hi5870@inno> <50D77815.5080908@fifthhorseman.net> <1716504.shBFhxGtMd@inno> Message-ID: <50D782FF.9060206@fifthhorseman.net> On 12/23/2012 04:42 PM, Hauke Laging wrote: > Am So 23.12.2012, 16:31:01 schrieb Daniel Kahn Gillmor: > >> the ssh specification declares the use pgp-style certificates: >> >> https://tools.ietf.org/html/rfc4253#section-6.6 >> >> but does little to indicate how peers should consider them for >> authentication purposes. > > Is that different from "pure" SSH keys or even X.509 client certificates? The key format is different than "pure" (i would call "raw") SSH keys -- but these OpenPGP certificates still act as a carrier for RSA or DSA key objects, which are mathematically and conceptually the same beasts as "raw" SSH keys. In SSH, the signature each peer provides when offering an OpenPGP certificate is expected to be an OpenPGP binary signature format (instead of a stock SSH-formatted RSA signature). Beyond that, the rest of the SSH protocol remains the same. I don't know of any ssh implementations that support the openpgp certificate format specification, or of anyone who uses it actively. otoh, as a monkeysphere developer, i can attest to the existence of ssh peers that use OpenPGP certificates during authentication/authorization while still handling "raw" SSH keys and signatures on the wire. With RFC 6091, even the handshake signature data itself is unchanged -- only the certificate format differs, and the rest of the TLS handshake remains the same. ? Why should a session protocol define which keys a user should trust? Beware of the term "trust" in this context -- it's a slippery one, and it is very easy cause confusion with it. I think you mean "which keys a peer should consider for authentication and authorization". For example, when i ssh to evilhost.example.org, i might verify the host's identity successfully via an OpenPGP certificate, and i might even go ahead and connect to it with SSH, but that wouldn't mean i "trust" the host in any broader or more human sense of the term "trust". Anyway, I agree with your implication that a session protocol specification has no business mandating a specific policy for authorization or authentication. But many people considering these challenges assume that authn/z policies should be bundled with the protocol spec; so i wanted to make that distinction clear. Regards, --dkg From melvincarvalho at gmail.com Sun Dec 23 23:35:52 2012 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Sun, 23 Dec 2012 23:35:52 +0100 Subject: OpenPGP Authentication Protocol? In-Reply-To: <50D782FF.9060206@fifthhorseman.net> References: <7180127.sdu3Hi5870@inno> <50D77815.5080908@fifthhorseman.net> <1716504.shBFhxGtMd@inno> <50D782FF.9060206@fifthhorseman.net> Message-ID: On 23 December 2012 23:17, Daniel Kahn Gillmor wrote: > On 12/23/2012 04:42 PM, Hauke Laging wrote: > > Am So 23.12.2012, 16:31:01 schrieb Daniel Kahn Gillmor: > > > >> the ssh specification declares the use pgp-style certificates: > >> > >> https://tools.ietf.org/html/rfc4253#section-6.6 > >> > >> but does little to indicate how peers should consider them for > >> authentication purposes. > > > > Is that different from "pure" SSH keys or even X.509 client certificates? > > The key format is different than "pure" (i would call "raw") SSH keys -- > but these OpenPGP certificates still act as a carrier for RSA or DSA key > objects, which are mathematically and conceptually the same beasts as > "raw" SSH keys. In SSH, the signature each peer provides when offering > an OpenPGP certificate is expected to be an OpenPGP binary signature > format (instead of a stock SSH-formatted RSA signature). Beyond that, > the rest of the SSH protocol remains the same. > > I don't know of any ssh implementations that support the openpgp > certificate format specification, or of anyone who uses it actively. > otoh, as a monkeysphere developer, i can attest to the existence of ssh > peers that use OpenPGP certificates during authentication/authorization > while still handling "raw" SSH keys and signatures on the wire. > > With RFC 6091, even the handshake signature data itself is unchanged -- > only the certificate format differs, and the rest of the TLS handshake > remains the same. > > ? Why should a session protocol define which keys a user should trust? > > Beware of the term "trust" in this context -- it's a slippery one, and > it is very easy cause confusion with it. I think you mean "which keys a > peer should consider for authentication and authorization". For > example, when i ssh to evilhost.example.org, i might verify the host's > identity successfully via an OpenPGP certificate, and i might even go > ahead and connect to it with SSH, but that wouldn't mean i "trust" the > host in any broader or more human sense of the term "trust". > > Anyway, I agree with your implication that a session protocol > specification has no business mandating a specific policy for > authorization or authentication. But many people considering these > challenges assume that authn/z policies should be bundled with the > protocol spec; so i wanted to make that distinction clear. > +1 We came to a similar conclusion with the WebID [1], where in fact, I do actually use my GPG master key as my X.509 and WebID key. You may be interested in looking at WebID for client server interactions, currently there are working demos over TLS, tho many people say that the UI for certificates in browsers make them unusable. That three concepts should be considered as topics in their own right: A) identification, B) authentication and C) authorization. Which (B) and (C) are often separated, (A) and (B) are often coupled together. After about 5 years of work, WebID is being rewritten into new specs which contain solutions to A,B,C separately. [1] http://webid.info > > Regards, > > --dkg > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From expires2012 at rocketmail.com Mon Dec 24 12:47:42 2012 From: expires2012 at rocketmail.com (MFPA) Date: Mon, 24 Dec 2012 11:47:42 +0000 Subject: GnuPG 1.4.13 released In-Reply-To: <87bodnslfw.fsf@vigenere.g10code.de> References: <50D4404A.5080507@vulcan.xs4all.nl> <87bodnslfw.fsf@vigenere.g10code.de> Message-ID: <881896598.20121224114742@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 21 December 2012 at 11:18:11 AM, in , Werner Koch wrote: > IDEA is now included to get rid of all the questions > from folks either trying to decrypt old data or > migrating keys from PGP to GnuPG. Will you be including IDEA in the 2.x branch as well? - -- Best regards MFPA mailto:expires2012 at rocketmail.com Always forgive your enemies; nothing annoys them so much -----BEGIN PGP SIGNATURE----- iQCVAwUBUNhA46ipC46tDG5pAQo02wP/ZjQS2WTNKXpuvuQ5cYmKQFfkIiClH7R3 IR+DZWc/X5KWP96Zgib2s8hL0R95oaNO5mDpBiuMpNvCvgV4fhnMkMuarIF4xzG0 FV/jiSR8LuvRIsFUuvpnbfG4eYHF9hMTP/48dtjRpEOYOn5NZsR6y2eEi2V+PuvO dAt64pY6s5U= =4NBY -----END PGP SIGNATURE----- From phonetree.oo at gmail.com Tue Dec 25 01:30:15 2012 From: phonetree.oo at gmail.com (Thomas Demers) Date: Mon, 24 Dec 2012 19:30:15 -0500 Subject: ASCII armor plus? - a main reason I find I and some others do not use encryption is that the messages get garbled Message-ID: The insertion of hard returns, blank lines, hyphens and so on is an issue I and others I have been trying to get to use encryption multiple times. It is one of the main reasons I don't use encryption as much as I could; I cannot be sure that my message will actually get through because these ascii armored blocks are so easily corrupted. I suggest as a future feature that the ascii armoring option have built into it more resistance to corruption in the face of this sort of thing. If hard returns are not used anyway in the encoding scheme, why not simply have GPG ignore them when parsing an armored message, instead of being unable to read the message? Also the ----begin pgp message---- or whatever header has been broken at times by the mere insertion of an extra hyphen on the left by an email system. Something I was only able to determine by sending myself test messages, not something most casual users have time for. Why not make it so that only the human readable part is essential, with the hyphens only for readabilit? From wk at gnupg.org Wed Dec 26 11:54:21 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Dec 2012 11:54:21 +0100 Subject: GnuPG 1.4.13 released In-Reply-To: <881896598.20121224114742@my_localhost> (MFPA's message of "Mon, 24 Dec 2012 11:47:42 +0000") References: <50D4404A.5080507@vulcan.xs4all.nl> <87bodnslfw.fsf@vigenere.g10code.de> <881896598.20121224114742@my_localhost> Message-ID: <87han9ozhe.fsf@vigenere.g10code.de> On Mon, 24 Dec 2012 12:47, expires2012 at rocketmail.com said: > Will you be including IDEA in the 2.x branch as well? Yes, if you use the development version of Libgcrypt. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 26 12:01:19 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Dec 2012 12:01:19 +0100 Subject: ASCII armor plus? - a main reason I find I and some others do not use encryption is that the messages get garbled In-Reply-To: (Thomas Demers's message of "Mon, 24 Dec 2012 19:30:15 -0500") References: Message-ID: <87d2xxoz5s.fsf@vigenere.g10code.de> On Tue, 25 Dec 2012 01:30, phonetree.oo at gmail.com said: > The insertion of hard returns, blank lines, hyphens and so on is an > issue I and others I have been trying to get to use encryption > multiple times. It is one of the main reasons I don't use encryption Actually the OpenPGP armor format is pretty robust to the extend it can be. However, you are likely talking about mail. Here I can only suggest to use PGP/MIME - it is part of the MIME standard and should be supported by all sane mail clients. It is a *16 year* old standard and has been implemented even earlier. Thus instead of trying to come up with some changed ascii armor, it will be way better to use an established standard. If your mail software messes things up, you know what to fix. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Dec 26 13:42:02 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 26 Dec 2012 07:42:02 -0500 Subject: ASCII armor plus? In-Reply-To: <87d2xxoz5s.fsf@vigenere.g10code.de> References: <87d2xxoz5s.fsf@vigenere.g10code.de> Message-ID: <50DAF09A.8070609@sixdemonbag.org> On 12/26/2012 6:01 AM, Werner Koch wrote: > Actually the OpenPGP armor format is pretty robust to the extend it can > be. However, you are likely talking about mail. Here I can only > suggest to use PGP/MIME - it is part of the MIME standard and should be > supported by all sane mail clients. It is a *16 year* old standard and > has been implemented even earlier. A word of caution may be in order: PGP/MIME is a fragile format and does not play nice with mailers (remailers, mailing list software, MTAs, anything in the chain) that plays with attachments. There are a surprising lot of these out there: for instance, the PGP-Basics mailing list at Yahoo! Groups is configured to strip all attachments, which means that PGP/MIME signatures on that mailing list are simply impossible. GnuPG-Users and Enigmail-Users have each within recent memory had mailing list software (GNU Mailman) which broke PGP/MIME signatures. When the community's flagship mailing lists cannot reliably use PGP/MIME, I'm a little cautious about recommending PGP/MIME as a general-purpose, ready-for-the-end-user solution. From josef at netpage.dk Wed Dec 26 08:42:19 2012 From: josef at netpage.dk (Josef Schneider) Date: Wed, 26 Dec 2012 08:42:19 +0100 Subject: OpenPGP card decryption with 4096bit keys bugfix?? Message-ID: <50DAAA5B.6060604@netpage.dk> Hello, first thing: I am not subscribed to this list, so please CC me in replies. I recently bought a OpenPGP smart card and want to use 4096bit keys and Windows. This doesn't work for decrypting with any released gpg version! There seems to be a patch to make it work at http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044868.html Is this one line change the only thing that has to be changed to make it work? Compiling gpg2 for Windows is really hard it seems. I haven't got the Gpg4win compilation to work because it needs some packages not available on my debian sid based machine. I am using the Gpg4win 2.1.1 Beta installer and want to change as little as possible. I compiled libgpg-error and libassuan and switched out the libassuan-0.dll If this one line is the only change, this should be enough?! (except if libassuan is also statically linked somewhere) But the problem is still the same after the switch. The only commands getting sent to the card when starting gpg --decrypt are: > scdaemon[208]: chan_000001BC <- SERIALNO openpgp > scdaemon[208]: chan_000001BC -> S SERIALNO D27600012401020000050000XXXXXXXX 0 > scdaemon[208]: chan_000001BC -> OK > scdaemon[208]: chan_000001BC <- RESTART > scdaemon[208]: chan_000001BC -> OK Even if I have to compile gpg2 as a whole I don't want to use the git working copy, but the 2.0.19 source with only the patch to make decryption with 4096bit Keys work. So can someone tell me if this is the only change (then I probably am doing something wrong) or if something else, and what, has to be changed. Thanks, Josef From rjh at sixdemonbag.org Wed Dec 26 14:22:44 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 26 Dec 2012 08:22:44 -0500 Subject: OpenPGP card decryption with 4096bit keys bugfix?? In-Reply-To: <50DAAA5B.6060604@netpage.dk> References: <50DAAA5B.6060604@netpage.dk> Message-ID: <50DAFA24.5020908@sixdemonbag.org> On 12/26/2012 2:42 AM, Josef Schneider wrote: > first thing: I am not subscribed to this list, so please CC me in replies. You will have better luck if you join the list. I can almost guarantee you that somewhere in this thread someone will have useful thoughts to contribute and they will not remember to cc you. > I recently bought a OpenPGP smart card and want to use 4096bit keys and > Windows. > This doesn't work for decrypting with any released gpg version! The easiest way to fix your problem is to consider whether 3072-bit crypto is sufficient for your purposes. It almost certainly is. 4096-bit crypto does not give you very much of an edge over 3072-bit crypto. Per NIST: Asymmetric size Equivalent symmetric size 1024 bits 80 bits 2048 bits 112 bits 3072 bits 128 bits 4096 bits -------- NIST doesn't even give an estimate for 4096-bit keys. My suspicion is they would come in around 134 bits or so, but that's just a hunch. This makes 4kbit keys the "odd man out." If 128-bit crypto is sufficient for your purposes (and it's sufficient for virtually all purposes!), then a 3072-bit key is also sufficient. If you're in one of the rare niches where 256-bit crypto is necessary then you've got two choices: use a 15,000-bit RSA key or else switch to elliptical-curve cryptography. Either way, there are very few cases where RSA-4096 is necessary. (I've personally never seen or heard of one, but I'm not going to claim they don't exist at all.) From wk at gnupg.org Wed Dec 26 19:23:24 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Dec 2012 19:23:24 +0100 Subject: ASCII armor plus? In-Reply-To: <50DAF09A.8070609@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 26 Dec 2012 07:42:02 -0500") References: <87d2xxoz5s.fsf@vigenere.g10code.de> <50DAF09A.8070609@sixdemonbag.org> Message-ID: <87pq1woeoz.fsf@vigenere.g10code.de> On Wed, 26 Dec 2012 13:42, rjh at sixdemonbag.org said: > When the community's flagship mailing lists cannot reliably use > PGP/MIME, I'm a little cautious about recommending PGP/MIME as a > general-purpose, ready-for-the-end-user solution. It is a sad time for standards, I know. Let's get rid of them all and use FB or GM and we don't need to care about that all anymore. BTW, we have patches for Mailman to fix the problem in most cases but they never made it to upstream. The funny thing is that Outlook has become better in this regard over time. But Mailman: no useful archive, no proper MIME support, arghh. I am not sure whether this reflects badly on standard Python modules or at the diminishing use of mailing lists. Salam-Shalom, Werner p.s. I guess I better configure Gnus to include your PGP/MIME disclaimer automagically if RFC-3156 is mentioned :-) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Dec 26 19:58:43 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 26 Dec 2012 13:58:43 -0500 Subject: ASCII armor plus? In-Reply-To: <87pq1woeoz.fsf@vigenere.g10code.de> References: <87d2xxoz5s.fsf@vigenere.g10code.de> <50DAF09A.8070609@sixdemonbag.org> <87pq1woeoz.fsf@vigenere.g10code.de> Message-ID: <50DB48E3.2050107@sixdemonbag.org> On 12/26/2012 1:23 PM, Werner Koch wrote: > It is a sad time for standards, I know. Let's get rid of them all and > use FB or GM and we don't need to care about that all anymore. In my defense, I never said I thought PGP/MIME had no place in the OpenPGP ecosystem. I just said I was reluctant to recommend it as a general-purpose solution, given how dodgy the support for it is in a great number of different venues. I readily concur that we have a pretty sorry state of "standards" nowadays. A standard that's not widely conformed to is not much of a standard. > BTW, we have patches for Mailman to fix the problem in most cases but > they never made it to upstream. The funny thing is that Outlook has > become better in this regard over time. But Mailman: no useful archive, > no proper MIME support, arghh. I am not sure whether this reflects > badly on standard Python modules or at the diminishing use of mailing > lists. The alternative would be to roll our own, and maybe the time has come for a Mailman replacement. I've long wanted some piece of software that allows for threads to be handled either via email or via web forums: after all, viewing is orthogonal to the content itself. Content can be stored in a back-end, and the front-end can/should be a replaceable component. From dkg at fifthhorseman.net Thu Dec 27 17:14:12 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Dec 2012 11:14:12 -0500 Subject: ASCII armor plus? In-Reply-To: <87pq1woeoz.fsf@vigenere.g10code.de> References: <87d2xxoz5s.fsf@vigenere.g10code.de> <50DAF09A.8070609@sixdemonbag.org> <87pq1woeoz.fsf@vigenere.g10code.de> Message-ID: <50DC73D4.10305@fifthhorseman.net> On 12/26/2012 01:23 PM, Werner Koch wrote: > BTW, we have patches for Mailman to fix the problem in most cases but > they never made it to upstream. This isn't the case, as far as i can tell. Recent versions of mailman all play fine with PGP/MIME. See, for example: https://bugs.launchpad.net/mailman/+bug/265967 Regards, --dkg From lenharo at gmail.com Sat Dec 29 05:35:30 2012 From: lenharo at gmail.com (Marcos Aurelio Lenharo) Date: Sat, 29 Dec 2012 02:35:30 -0200 Subject: OpenPGP card decryption with 4096bit keys bugfix?? In-Reply-To: <50DAAA5B.6060604@netpage.dk> References: <50DAAA5B.6060604@netpage.dk> Message-ID: <50DE7312.3090901@gmail.com> Hi, I posted that patch but it was a quick&dirty solution. The final code was changed by Werner, can be found in the following commit but no official gpg version was released yet: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=ab4ea45f54006eba55db11263431c4c0c4f557dc Best Regards, Marcos A. Lenharo On 26-12-2012 05:42, Josef Schneider wrote: > Hello, > > first thing: I am not subscribed to this list, so please CC me in replies. > > I recently bought a OpenPGP smart card and want to use 4096bit keys and > Windows. > This doesn't work for decrypting with any released gpg version! > There seems to be a patch to make it work at > http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044868.html > Is this one line change the only thing that has to be changed to make it > work? > Compiling gpg2 for Windows is really hard it seems. I haven't got the > Gpg4win compilation to work because it needs some packages not available > on my debian sid based machine. > I am using the Gpg4win 2.1.1 Beta installer and want to change as little > as possible. I compiled libgpg-error and libassuan and switched out the > libassuan-0.dll > If this one line is the only change, this should be enough?! (except if > libassuan is also statically linked somewhere) > But the problem is still the same after the switch. The only commands > getting sent to the card when starting gpg --decrypt are: > >> scdaemon[208]: chan_000001BC <- SERIALNO openpgp >> scdaemon[208]: chan_000001BC -> S SERIALNO > D27600012401020000050000XXXXXXXX 0 >> scdaemon[208]: chan_000001BC -> OK >> scdaemon[208]: chan_000001BC <- RESTART >> scdaemon[208]: chan_000001BC -> OK > Even if I have to compile gpg2 as a whole I don't want to use the git > working copy, but the 2.0.19 source with only the patch to make > decryption with 4096bit Keys work. > So can someone tell me if this is the only change (then I probably am > doing something wrong) or if something else, and what, has to be changed. > > Thanks, > Josef > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From klaus at vink-slott.dk Sat Dec 29 16:22:55 2012 From: klaus at vink-slott.dk (Klaus Slott) Date: Sat, 29 Dec 2012 16:22:55 +0100 Subject: Privacy selection Was: ASCII armor plus In-Reply-To: <87d2xxoz5s.fsf@vigenere.g10code.de> References: <87d2xxoz5s.fsf@vigenere.g10code.de> Message-ID: <20121229162255.3316eb28@zap.vink-slott.dk> I have just switched to use Claws mail and this gives me 3 options in "Privacy System": PGP inline, PGP Mime and S Mime. On Wed, 26 Dec 2012 12:01:19 +0100 Werner Koch wrote in another tread: > Here I can only > suggest to use PGP/MIME - it is part of the MIME standard and should > be supported by all sane mail clients. It is a *16 year* old > standard and has been implemented even earlier. So I guess the recommended selection should be "PGP Mime" like this? -- Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jerry at seibercom.net Sat Dec 29 18:30:32 2012 From: jerry at seibercom.net (Jerry) Date: Sat, 29 Dec 2012 12:30:32 -0500 Subject: Privacy selection Was: ASCII armor plus In-Reply-To: <20121229162255.3316eb28@zap.vink-slott.dk> References: <87d2xxoz5s.fsf@vigenere.g10code.de> <20121229162255.3316eb28@zap.vink-slott.dk> Message-ID: <20121229123032.127a71e5@scorpio> On Sat, 29 Dec 2012 16:22:55 +0100 Klaus Slott articulated: > So I guess the recommended selection should be "PGP Mime" like this? Unless you want to mess up signatures, etc. Seriously, while "PGP inline" is not dead, it is only utilized by some very old MUAs. Modern MUAs handle "PGP Mime" just fine. -- Jerry ? Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From rjh at sixdemonbag.org Sat Dec 29 20:03:30 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 29 Dec 2012 14:03:30 -0500 Subject: Privacy selection Was: ASCII armor plus In-Reply-To: <20121229123032.127a71e5@scorpio> References: <87d2xxoz5s.fsf@vigenere.g10code.de> <20121229162255.3316eb28@zap.vink-slott.dk> <20121229123032.127a71e5@scorpio> Message-ID: <50DF3E82.30202@sixdemonbag.org> On 12/29/2012 12:30 PM, Jerry wrote: > Unless you want to mess up signatures, etc. Seriously, while "PGP > inline" is not dead, it is only utilized by some very old MUAs. Modern > MUAs handle "PGP Mime" just fine. Modern MUAs, yes. Modern MTAs, no. The "mail servers play hob with attachments" issue is very real. I've personally seen it affect GMail, Exchange and Mailman, along with half-a-dozen poorly-configured sendmail and postfix installations. I'm not telling people to not use PGP/MIME. I am saying that PGP/MIME is not as reliable as its proponents would like to believe. My best advice is that if you use PGP/MIME, be ready to fall back to inline traffic.