dirmngr failes with missing file
When gpg -recv-key ID is used with the line hkps://hkps.pool.sks-keyservers.net enabled in dirmngr.conf, it failes with an error message saying dirmngr not found. The solution to this is to add the empty file ~/.gnupg/dirmngr_ldapservers.conf Shouldn't this be added automatically to avoid this error? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SHA1 collision found
Am 23.02.2017 um 20:09 schrieb ved...@nym.hush.com: > The Openpgp standards group is working on this. Yes but who know how many years it will take until a new standard is accepted... > > The link you give for the collision used 2 PDF's. > Using a PDF is sort-of 'cheating', and does not extrapolate to being > 'completely broken'. > > Assuming that it is possible to find a pre-image collision, i.e: > > [1] m1.txt 1 has an SHA1 hash of H1 > [2] m2.txt will now have the same SHA1 hash H1 > > What will happen to in order to generate m2.txt is that there will be > many trials of a gibberrish string added to the plaintext of m2.txt > until one is found that has the same SHA1 hash as m1.txt > BUT > This will be quite visible in the plaintext of m2.txt, and won't fool > anyone. > > With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the > actual PDF the receiver reads, only in the meta-data, the appended PDF > 'Suffix'. Not sure about you but I am not able to see the difference between a valid pgp key and "gibberish" ;) > > While this is *do-able* and a good reason to move on to a future > SHA256 hash, it would not be transferable (at this time, based on the > PDF collision data), to find a fingerprint collision for any v4 key. > vedaal The question is how many tries it takes until a colliding key is found that is accepted by common pgp implementations when imported, is it not? As said, if it is as easy as i think it is, providing an option for different hash algos to generate fingerprints would be a nice solution until a new standard is established. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SHA1 collision found
Am 23.02.2017 um 19:48 schrieb Peter Lebbing: > On 23/02/17 19:24, si...@web.de wrote: >> After researching how the fingerprint is generated, I think it would >> be easy to include a new option in gnupg to print a fingerprint using >> sha256. Would that be something that will/can be included in future >> versions of gnupg? > > It wouldn't help because of all the places SHA-1 is used internally if > you just change how it is displayed to the user. Disclaimer: I'm not a > developer, but this is my understanding of it. I can't say for sure. > I would rather see this as a means to manually check the key to enable users to potentially discover fake keys. Since I did not find a simple way to generate the fingerprint and identifying the key contents to be hashed seems really tricky, putting an additional option in gnupg to generate a longer fingerprint seems like the easiest solution. Having an option like --fingerprint would allow users to use any hash they want until a new openpgp standard is published. This is not something that needs to be used by default, just something that can be used by those who look for it. After looking into second-preimage attacks the issue does not seem to be that critical though. Still it would be a nice feature and if I did not misunderstand the how the fingerprint is generated it could be implemented by adding very little code. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
SHA1 collision found
Today was announced that SHA1 is now completely broken https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html A few weeks back it was mentioned that there is a new proposal for a openpgp standart including a new algorithm for pgp fingerprints. As this is currently not applicable in practice, I would like to know what this new development means for pgp-gnupg and the use of SHA1 for key identification. After researching how the fingerprint is generated, I think it would be easy to include a new option in gnupg to print a fingerprint using sha256. Would that be something that will/can be included in future versions of gnupg? That way users could publish both the sha1 and sha256 finderprint in the future. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
Am 17.02.2017 um 21:57 schrieb Kristian Fiskerstrand: > On 02/17/2017 09:46 PM, si...@web.de wrote: >> Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: >>> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: > > >>> >>> That change would also be consistent with >>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 >>> >> >>> >> Not quite sure I get this. >> >> So what this means is that effectively gnupg still uses plaintext >> connections to update public keys by default, does it not? > > Yes (if not a tor configuration locally) > >> If the >> change I suggested is not correct, shouldn't we find another way to >> use secure connection by default whenever possible? > > Probably nitpick, but it would likely increase privacy - not security. > That was the goal all along, as mentioned in the initial post some weeks ago. Especially when the complete keyring is updated, this leaks the complete contact list to the network, which is kinda bad. And privacy is kinda also somthing people use gnupg for isn't it. So I don't know the best way to change this but I would like to suggest that future versions use https only by default, e.g. by changing the skel file. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: > On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: >> On 02/17/2017 07:00 PM, si...@web.de wrote: >>> keyserver hkps://jirk5u4osbsr34t5.onion >>> keyserver hkps://keys.gnupg.net >>> >>> would solve this I guess. >> >> No, that'd result in certificate errors and non-responsive servers >> > > That said, you are indeed correct, and skel file is used to create > dirmngr.conf on other systems as well (it has been a while since > starting with a fresh homedir :) ) ... if wanting hkps the latter should > be switched to hkps://hkps.pool.sks-keyservers.net ,the former is > protected already as tor usage would be to an endpoint running a tor > hidden service. > > That change would also be consistent with > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 > Not quite sure I get this. So what this means is that effectively gnupg still uses plaintext connections to update public keys by default, does it not? If the change I suggested is not correct, shouldn't we find another way to use secure connection by default whenever possible? As it is now, the default fallback mentioned in the referenced commit never takes effect as long as the skel file is used. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Download of public keys
Am 17.02.2017 um 17:31 schrieb Kristian Fiskerstrand: > On 02/17/2017 01:37 PM, si...@web.de wrote: >> Is there something I missed or is this unintended? > > gnupg does not ship an installed dirmngr.conf, when no keyserver is > specified it defaults to hkps://hkps.pool.sks-keyservers.net, the > existence of a (I presume) arch installed dirmngr.conf changes this > behavior. > > Whether that is intended or not is a question for your distribution's > package maintainer. > Arch does not ship a dirmngr.conf either as far as I can see. When running the gpg command for the first time on a new system, the dirmngr.conf file is creates together with some other files. I just tested it again on ubuntu 16.04.2 and the same file appear in the gnupg directory, so it does not seem to be a distribution issue. It seems that gnupg does ship this template file as dirmngr-conf.skel although I am not sure if the distributions have anything to do with it being copied to the user directory. In any case, it might be a good idea to change the template gnupg ships Changing the lines: keyserver hkp://jirk5u4osbsr34t5.onion keyserver hkp://keys.gnupg.net to keyserver hkps://jirk5u4osbsr34t5.onion keyserver hkps://keys.gnupg.net would solve this I guess. I will although check with the arch maintainer about this to be sure but I do not think this is a distro issue ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Download of public keys
Some time ago I asked about the unencrypted download of public keys. The answer was that the current gnupg does use https by default to fetch the keys. I found the time to retest this on a new setup and found that gnupg 2.1.18 still uses http connections to fetch the keys. I uses a newly installes arch linux setup with basically nothing but the base linux tools and downloaded a public key whil sniffing on the network. All requests, first to keys.gnupg.net and tehn to some other keyservers were in plaintext. The default dirmngr.conf file provided by arch, which seems to use gnupg 2.1.18 without changes, contains the followging lines: # If exactly two keyservers are configured and only one is a Tor hidden # service, Dirmngr selects the keyserver to use depending on whether # Tor is locally running or not (on a per session base). keyserver hkp://jirk5u4osbsr34t5.onion keyserver hkp://keys.gnupg.net This would explain why no encryption is used. Is there something I missed or is this unintended? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unecrypted download of public keys
Am 04.02.2017 um 23:27 schrieb Daniel Kahn Gillmor: > On Sat 2017-02-04 15:14:50 -0500, sivmu wrote: >> I suppose this config did not change after upgrading from 2.1.17. >> Just tested it on 2.1.18 using arch and it still uses http on my setup. > > it's not a config change -- it's a defaults change. > > in the old arrangement, if you didn't specify a keyserver, you couldn't > get anything at all, so many people put some keyserver in their > configuration manually. > > if you have a "keyserver" listed in your config manually, then you are > *overriding* the default. And yes, if you list foo.example.com, it will > connect to that server in the clear (just as if you put > hkps://foo.example.com then it would connect using TLS). > > Did you try this with no explicit "keyserver" directive? > >> But this would be rather an issue with the distro, correct? > > It may be an issue with your distro, i don't know how arch has packaged > 2.1.18. > > all the best, > > --dkg > This is the script for the arch gnupg package: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gnupg But I do not see any sign of overriding the defaults and I never changed the settings either. I might just setup a new arch system in a VM and test this on a clean installation to make sure I did not mess something up. Could it be that installing gpa changed the defaults? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unecrypted download of public keys
Am 04.02.2017 um 08:18 schrieb Daniel Kahn Gillmor: > On Sat 2017-02-04 01:33:56 -0500, sivmu wrote: >> When using --revc-key or the gpa frontend, I noticed that the >> target public keys are still downloded using unencrypted http. While the >> trnasmitted information is generally public, it doesmake things pretty >> easy for an adversary to collect metadata such as your contacts. >> >> This is expecially relevant if you refresh your keys all at once, as >> this will leak your complete contact list to the network. >> >> Is there any reason gnupg does not use https by default to connect to >> the keyservers? I think this is an unnecessary leak of privacy. > > as of 2.1.18, gnupg does use https by default to connect to the > keyserver network. :) > > In particular, if you do not supply a --keyserver argument, it will use > hkps://hkps.pool.sks-keyservers.net as the default keyserver, and should > verify the certificates only against the pool-specific CA. > >--dkg > I suppose this config did not change after upgrading from 2.1.17. Just tested it on 2.1.18 using arch and it still uses http on my setup. But this would be rather an issue with the distro, correct? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Unecrypted download of public keys
When using --revc-key or the gpa frontend, I noticed that the target public keys are still downloded using unencrypted http. While the trnasmitted information is generally public, it doesmake things pretty easy for an adversary to collect metadata such as your contacts. This is expecially relevant if you refresh your keys all at once, as this will leak your complete contact list to the network. Is there any reason gnupg does not use https by default to connect to the keyservers? I think this is an unnecessary leak of privacy. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg website
Am 30.01.2017 um 18:22 schrieb Werner Koch: > On Mon, 30 Jan 2017 11:56, w...@gnupg.org said: > >> I am working on that. But please given me a few days. I want to align > > Time warp: All servers updated. Sslabs rating is now A+ (respective A > for those without HSTS). The used pound version is can be found at > git.gnupg.org. > > Hope that helps the Sierras > > > Salam-Shalom, > >Werner > Wow that was fast, thanks. OSCP stapling is still missing though and I'm not sure NIST curves for ECDHE are the way to go (would prefer DHE) but that's not a primary concern I guess :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
sha1 pgp fingerprint
I have been wondering for a while about the use of sha1 in pgp fingerprints. Although sha1 may not be easily broken in practise, there are theoreticall collosion attacks that are feasible for well funded organisations. Cryptographers, like Bruce Schneier, have been recommending for years to migrate to a new hash algorithm for all sorts of reasons. New versions of gpg do not use sha1 in any encryption operation if I am not mistaken. But we still use sha1 fingerprints to compare of our keys. The question I have not yet found any clear answer for, is why is nobody talking about this and should pgp keys be identified by a stronger hash alogrithm in the future? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg website
Am 25.01.2017 um 23:00 schrieb Robert J. Hansen: >> The main problem would be its 64-bit block size. Apparently there's a >> "practical" attack against 64-bit ciphers as used in TLS [1]. > > Quoting from the abstract: "In our proof-of-concept demos, the attacker > needs to capture about 785GB of data." I question the wisdom of any system > which sends 785Gb of data without ever rekeying. > > This attack seems to fall into the realm of "stupid SSL mistakes lead to > exploitation. " > There are prove of concepts against TLS and openvpn https://sweet32.info/ It is not quite that simple I think. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg website
Am 25.01.2017 um 22:25 schrieb Damien Goutte-Gattat: > On 01/25/2017 02:41 PM, Robert J. Hansen wrote: >> For that matter, I'm still in the dark as to what the big problem with >> three-key 3DES is. The best attack against it requires more RAM than >> exists in the entire world and only reduces it to 112 bits. > > The main problem would be its 64-bit block size. Apparently there's a > "practical" attack against 64-bit ciphers as used in TLS [1]. > > That's probably reason enough to avoid 3DES whenever possible (when a > 128-bit cipher is available). > > [1] https://eprint.iacr.org/2016/798 > That would be the sweet32 attack https://sweet32.info/ Basically if you can collect a few hundred GB of data, it is trivial to calculate the key. There is a prove of concept for https connections, although I believe this is especially relevant for VPN connections (openvpn uses a 64 bit ciphers (blowfish) by default) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg website
Am 25.01.2017 um 12:14 schrieb Peter Lebbing: > On 25/01/17 09:52, Werner Koch wrote: >> OCSP is used as an alternative to CRLs and not directly related to >> privacy. > > The OP might have meant "OCSP Stapling" which includes the OCSP data in > the data sent by the webserver during TLS session setup. That way, the > OCSP data doesn't need to be fetched from an OCSP server, which would > leak the fact a certain website certificate is being verified to the > OCSP server. Yes that is what I meant, sorry for the confusion. I think this might be relevant for some people who would prefer not to trigger unnecessary queries for privacy reasons. Anyways ssllabs shows a warning that the website will be degraded from A to C in a month. Not sure that matters all that much, but if there is an oppertunity to change the available ciphers at some point... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gnupg website
Hi, not sure this is the perfect place, but I wanted to point out that the gnupg.org website still uses sha1 as a mac. If I am not mistaken, several common browsers have announced to display warnings fur this kind of tls connection, so it might be a good idea to update the server at the next opportunity. Also, activating OCSP to increase privacy might be a good idea too. Thanks for your work on open source encryption. - Regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcards and tokens
Am 18.12.2016 um 10:49 schrieb Peter Lebbing: > On 18/12/16 01:56, Robert J. Hansen wrote: >> Nope. OpenPGP requires each RSA encryption add at least eight random >> bytes to the data pre-encryption in order to make even identical >> messages encrypt to different ciphertexts. > > However, this randomness is added by the host, not by the smartcard. The > OpenPGP smartcard really only does a deterministic action, and its > correctness can be verified simply by doing the RSA public key operation > on the output and checking that the result is identical to what was fed > to the smartcard. > Thats good to know. Thanks > I can't think of a side channel to leak the private key to an attacker > through an uncompromised host, but I wouldn't be surprised if there is > such a side channel. Does anybody have a cool way to leak this? Single > bits at a time will do! :-) > Implement a GSM chip into the token? :) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent 2.1.16 needs about 10s for initialization saying need_entropy before it completes its first op
Am 19.12.2016 um 02:20 schrieb Jan Kundrát: > Hi, > we're using gpgme's C++ bindings in Trojita [1], an IMAP e-mail client. > After an update of gnupg from 2.1.15 to 2.1.16, gpg-agent appears to > need more than 10s to initialize itself during startup -- or at least > our very first decryptAndVerify() operation takes more than 10s. > I can confirm simular behavior. After upgrading to 2.1.16 it takes 10 seconds on the first operation performed. Any following operations are fast as usual. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcards and tokens
Am 18.12.2016 um 01:30 schrieb Andrew Gallagher: > >> On 18 Dec 2016, at 00:17, sivmu wrote: >> >> ... that this means RSA encrzption is reproducable, meaning encrypted >> files of the same plaintext result in the same ciphertext, as this woul >> make the process reproduceable and any malfunction can be easily noticed. > > No, because the plaintext is symmetric-encrypted with a random session key on > the host. The smartcard just asymmetric-encrypts the session key. This two > step process is used mainly because asymmetric encryption is comparatively > slow, but it also means that two identical plain texts won't get encrypted to > the same ciphertext, due to the random session key. > > A > You are right, I forgot that. Having some kind of way to check if the card is operating normally would be awesome though... signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcards and tokens
Am 16.12.2016 um 13:36 schrieb Andrew Gallagher: > On 16/12/16 02:30, sivmu wrote: >> If the token does the encryption (and signing) operations, > > Smartcards perform signing and DEcryption (which in the case of RSA are > mathematically identical). > >> it needs randomness. > > That's true of DSA and ElGamal, but smartcards normally implement RSA. > > Remember also that PGP uses a two-step encryption process. The random > symmetric session key is generated on the host rather than the > smartcard, and the secure hash used in signing is deterministic. > Thats what i wanted to hear. If the symmetric key is generated on the host, that stops any scenario where the smartcard can subvertly compromise the encryption process, assuming > The smartcard itself only RSA-decrypts the session key (or hash), and > this doesn't require an RNG. ... that this means RSA encrzption is reproducable, meaning encrypted files of the same plaintext result in the same ciphertext, as this woul make the process reproduceable and any malfunction can be easily noticed. Signing could still be manipulated by a compromised smartcard I guess signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcards and tokens
Am 15.12.2016 um 22:17 schrieb Damien Goutte-Gattat: > On 12/15/2016 08:35 PM, sivmu wrote: >> From what I understand, a malicious token can e.g. perform encryption >> operations with weak randomness to create some kind of backdoor that is >> hard to detect. > > The token is normally not used to perform any *encryption*. You encrypt > with the public key of your correspondant, which is stored on your > computer, not on your token (there's no need to protect it since it is a > *public* key). You use your token to *decrypt* messages that were sent > to you--and at that time, even if the token is malicious there's nothing > it can do to mess with the encryption. > I assumed the public key of the recipient is transferred to the token so that it can do the encrytion internally. This is one of the things I worry about. If the token does the encryption (and signing) operations, it needs randomness. Something that is often messed with and hard to produce reliably compared to a device with user interaction. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcards and tokens
Am 15.12.2016 um 02:35 schrieb NIIBE Yutaka: > sivmu wrote: >> One question remaining is what is the difference between the openpgp >> smartcard and the USB based tokens. > > I think that the OpenPGP card (the physical smartcard) is included in > Nitrokey Pro USB Token. So, it's exactly same from the view point of > smartcard. > > When you want to use a smartcard, you need a card reader to access the > card. And the card reader you use would bring another attack vectors. > In this point, Nitrokey Pro USB Token is the best approach, I suppose. > > IIUC, Yubikey products are JavaCard implementations and somehow emulate > OpenPGP card protocol by "app", and they work as CCID card reader + > OpenPGP card. > > In Nitrokey Start USB Token, there is no OpenPGP card physically, but it > is implemented by Gnuk, the software. > >> Also how much would you trust those vendors and can the use of such >> tokens actually decrease security? > > This is the point. > > The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by > man in the middle (or its vendor). The hardware MCU chip in Nitrokey > Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey > Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we > should consider possibility of backdoor of OpenPGP card. Well, I don't > know about Yubikey. > > When it is replaced to be malicious one to enable an access by others > (to your private keys), or it already has a backdoor in the first place, > it kills the purpose of USB security token. > > Here, the question is: how can we build up such a "trust"? > > It seems for me that there are two different approaches; (1) physical > difficulty (for example, plastic molding for "protection"), (2) > reproducibility and transparency/openness. Note that some method of > former makes latter difficult. > > > For myself, I take (2), and I did my best to make my product as > reproducible. (Since I don't manufacture semiconductor things, > reproducibility is not 100%, and this part of manufacturing and > technology is not open at all.) And I intentionally deliver my product > in a style of "transparent" or "open". > > Distribution channel is also difficult. I do in person, and I ask FSF > for my TRNG. Are there any good method? > > Obvious drawback of the apporoach (2) is that people with enough > concern/attention have tendency to do it under their control. > Reasonable. Since it's reproducible (somehow), it's possible, by > definition. And then, I can't sell many. > From what I understand, a malicious token can e.g. perform encryption operations with weak randomness to create some kind of backdoor that is hard to detect. Maybe there is also a way to secretly send the secret keys loaded onto the smartcard/token to the adversary using the PC and network it is used on. If there is no way to detect such malicious devices and given that certain organisations tend to mess with security tokens and crypto devices, it seems using those specific devices actually decreases security, assuming it is easy to manipulate specialised vendors of security hardware compared to manipulating electronic hardware in general. Or is this too much of a conspiracy theorie? (not that those do not have a tendency to be outrun by reality anyway) With nitrokey, both the hardware design and the software is open source and both have been audited. Bu I don't think that will keep some people from intercepting deliveries of such devices or mess with the production. I'm really not sure if specialised devices for crypto is a good idea, give that it presents such a promising target. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Smartcards and tokens
Hi, recently I came across the toptic of hardware tokens for pgp keys and I am thinking about getting one myself. From what I have found so far there are several candidates such as the Openpgp smartcard, Yubikey and Nitrokey USB tokens. One question remaining is what is the difference between the openpgp smartcard and the USB based tokens. Also how much would you trust those vendors and can the use of such tokens actually decrease security? Any advise would be welcome Regards, sivmu signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
