Re: OpenPGP key verification + legal framework

On 05/11/18 17:56, Viktor wrote: > If my counterparty had signed some contract or document, he/she should > not be able to delete his/her public key certificate and data used for > its verification. IMVHO You're just (badly) reinventing X509. > This is exactly the part that is difficult to ensure

Re: Hard to find alternate source of checksums

Il 16/06/2018 19:48, Jeff Martin ha scritto: > I'm not on Linux. I'm on macOS, which does not come with any built-in > GPG. I must build GPG from source files. The only way to verify the > source files in this situation (I think) is by checksum. You can just fire up a VM booting with an "old enoug

Re: Hard to find alternate source of checksums

Il 09/06/2018 19:08, Jeff Martin ha scritto: > For a fresh install of GnuPG, I was following the integrity check > directions. I have no prior version for GnuPG. Why not fetch some (unrelated) live distributions, possibly some older ones and some newer ones? GPG is usually included and you can use

Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service

Il 07/06/2018 02:01, Leo Gaspard via Gnupg-users ha scritto: >> The only secure (even against decapping attacks) device I know of is a >> very old parallel-port "key" a friend described me ~25y ago. >> It was made of 3 silicon layers: the outer ones only contained interface >> circuits and 'random

Re: [NIIBE Yutaka] STM32F103 flash ROM read-out service

Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto: > BTW, BasicCard and JavaCard seemed even more obscure and I cannot find > any public service of cracking. Because those are (at least should be) based on secure chips. > But it does not solve any real problem in the perspective of cryptograp

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

Il 23/05/2018 04:35, Craig P Hicks ha scritto: > When decrypted by the user in its raw form the total message will be > human readable but a little ugly because it contains the obfuscation > string *o*, but it will be safe from EFAIL. While that could be OK for human-readable files, it silently al

Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)

Il 18/05/2018 07:31, Fiedler Roman ha scritto: > I thought about that also, but shouldn't 99%+ of systems perform no pinning > whatsoever of packages to repositories? In that case, the "wrong" repository > could publish just a slightly increased package version number of a package > from anothe

Re: OpenPGP card && exporting secret keys

Il 06/02/2018 06:47, Matthias Apitz ha scritto: > Is there any way to export the secret keys from the OpenPGP card to use > them directly (with a passphrase) and without the OpenPGP card? Not possible by design. What you can do is generate the key on the machine, then copy (not move) it to the ca

Re: auto-key-retrieve usefulness/annoyance

Il 05/10/2017 21:06, Daniel Kahn Gillmor ha scritto: > gpg isn't currently constructed to do this kind of asynchronous user > interaction, however. But the mail client could flag the message "key retrieval failed". Then, the delay is only on the first attempt. Unless the user un-flags that message

Re: 1024 key with large sub key

Il 03/10/2017 12:40, Werner Koch ha scritto: [...] > scrutinized the Intel ME, fixed all bugs in gpg, live in tempest At least they should have shared the bugfixes! :) BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.o

Re: [Feature Request] Multiple level subkey

Il 12/09/2017 19:39, lesto fante ha scritto: > i think my user-case if one of the most common, especially if we want > to create something like a state-provided identity (on you > smartacard-document), that want want to make easily usable on everyday > services (remeber, all services is really "po

Re: A Quick Supplement

Il 18/07/2017 14:23, Daniel Villarreal ha scritto: > Have you ever asked Werner about what he thinks about "ease" of > backing up?" Security = confidentiality + integrity + availability If you're not considering availability, you only can have partial security. BYtE, Diego

Re: Changing PINs of German bank card

Il 12/07/2017 12:01, Binarus ha scritto: > Not sure about that. Similar to serious websites which don't store your > password in clear text, but do store the password's hash instead, I > would expect that banks don't store your PIN in clear text as well. Even with 6-digits PIN it would take *secon

Re: Changing PINs of German bank card

Il 11/07/2017 12:32, Binarus ha scritto: >> If you routinely use your card twice a day, they can make two or four >> guesses each day: every correct PIN you insert resets the counter. > I am not completely sure if I got you right. Wouldn't that mean that I > have to lose my card, the bad person th

Re: Changing PINs of German bank card

Il 11/07/2017 09:44, Binarus ha scritto: > - If somebody tries to brute force the pin (or online banking password), > the access will be permanently denied if there are more than 3 failures > (the exact number may vary). That means that the length of the pin / > password is not as important as one

Re: How to use a PKCS#15 with GnuPG?

Il 17/06/2017 10:35, Werner Koch ha scritto: > gpg expects an OpenPGP card. For pkcs#15 you need to use gpgsm. As a > starter do > gpgsm --learn-card > which imports the certificates from such cards. There is no --card-edit > etc, because in general PKCS#15 cards are distributed personalized.

How to use a PKCS#15 with GnuPG?

ded infos... I generated some test keys on the token (ssh one is imported, for another test): $ pkcs15-tool -D Using reader with a card: Feitian ePass2003 00 00 PKCS#15 Card [NdK-test]: Version: 0 Serial number : 0843420916091101 Manufacturer ID: EnterSafe

Re: Key management for archives

Il 09/06/2017 08:24, Werner Koch ha scritto: > ( gpg --status-fd 1 --show-session-key --max-output 1 \ > -o /dev/null 2>/dev/null FILE || true ) \ >| awk '$1=="[GNUPG:]" && $2=="SESSION_KEY" {print $3}' > The output can then be used with --override-session-key Tks! That's exactly what I

Re: Key management for archives

Il 06/06/2017 22:40, Konstantin Gribov ha scritto: > In first scheme DEK is never stored in plain text. It used while > encrypting archive and encrypted with gpg (or any other cryptographic > means) and plain text version is removed right after that. There's a big misunderstanding here: the encryp

Re: Key management for archives

Il 06/06/2017 20:13, Konstantin Gribov ha scritto: > I can think of more simpler approach: > - generate secure random for symmetrical data encryption key (DEK); > - encrypt that key for authorized users on their public keys; > - encrypt data itself with something like ChaCha20 or AES in appropriat

Key management for archives

Hello all. I'd need to handle an archive with many big files (~200GB each). The system receives "plain" files in a "dropbox" folder, then encrypts 'em to a (set of) public key(s) (no corresponding private keys on this system) and deletes source files. Up to this point it should be OK (a cronnable

Re: Documentation about --list-secret-keys output

Il 07/04/2017 11:51, mogliii ha scritto: > +offline (for example, a primary key can be taken offline by exported Shouldn't it be "exporting" instead of "exported"? BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/m

Re: How U2F works

Il 06/03/2017 16:10, Werner Koch ha scritto: > An old argument against user certificates was the need to purchase a > device or a certificates. Now U2F requires that you purchase a device > anyway, thus this would void that argument. IIRC one of the selling points of U2F is that it should have be

Re: Announcing paperbackup.py to backup keys as QR codes on paper

Il 23/02/2017 11:00, Gerd v. Egidy ha scritto: > If we are talking centuries, I'd worry about the availability of gnupg as > much > as qrcodes. Both are publicly available standards, but I don't know if they > are still available and understandable by then. I'd recommend going to > plaintext o

Re: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys?

Il 28/12/2016 13:28, Miroslav Rovis ha scritto: >> The fact that Github, since this outgoing year, accept gpg signing only >> if you post your public key to their servers. I can't say for sure, but maybe that's so so they can have an "attestation key" to use for verifying signatures, without expen

Re: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys?

Il 27/12/2016 22:09, Don Warner Saklad ha scritto: > What do you kind folks out there make of comments at > https://stallman.org/gpg.html > >"I'm told that key servers carry many phony keys claiming to be >mine. Here is info about which keys are really mine." > > >"Of course, to be really su

Re: Strange behaviour

Il 11/12/2016 11:56, Matthias Mansfeld ha scritto: > Currently I have not the time to go much more in depth and can live > with the fact that in that moment much other stuff on this computer > tends to hang and the "easiest" way for now is to reboot... It is > possible that this behaviour came

Re: Proof for a creation date

Il 07/12/2016 09:53, Andrew Gallagher ha scritto: > No signature can possibly attest that something is valid *forever*. Well, "till the heat death of the Universe" can be enough for any practical purpose :) > You're right that stapling is absolutely required in a data at rest > use case, because

Re: Proof for a creation date

Il 07/12/2016 00:27, Andrew Gallagher ha scritto: > I don't see any reason why it couldn't be done in principle - anyone who > wants could set up an "authority" that produces a regular, signed list of all > the certificates it currently trusts at each point in time. The trick is a) > making sur

Re: Proof for a creation date

Il 06/12/2016 23:14, Andrew Gallagher ha scritto: >> That could actually reduce trust in any PGP signature, unless there's a >> way to timestamp 'something' that says "as of 'now' this key have not >> been revoked". Ideally that attestation should be included with the >> signature itself > So, es

Re: Proof for a creation date

Il 06/12/2016 12:30, Roman Zeyde ha scritto: > You can also use OpenTimestamps service as described here: > https://petertodd.org/2016/opentimestamps-announcement Interesting! To remain on-topic, I'd like to take the "footnote 3": -8<-- An interesting nuance to this is someone who has stolen a PGP

Re: Specifying entropy source

Il 16/11/2016 15:55, Juergen Christoffel ha scritto: > Then there are http://www.bitbabbler.org and > http://ubld.it/products/truerng-hardware-random-number-generator/ as > hardware random number generators. Both are worth their money IMO. Why not GnuK, that incorporates a TRNG too? There's even a

Re: PCI DSS compliance

Il 10/11/2016 16:24, helices ha scritto: > Our company must decrypt ~100 files 7x24 in near real time. How can > work - or any reasonable alternative - in such a production environment? Wouldn't a smartcard solve (at least partially) the issue? Insert it in a pinpad reader and have the PIN sh

Re: smartcard reader

Il 19/10/2016 13:06, Werner Koch ha scritto: > There is no integrated card. gnuk uses an SM32 MCU which implements the > OpenPGP card and CCID interface specs. This has the huge advantage that > all software (firmware) is free software. The drawback is that it is > not tamper resistant - your s

Re: Attacks on encrypted communicxatiopn rising in Europe

Il 24/08/2016 14:11, Francesco Ariis ha scritto: > @Johan Wevers: you might or might not be aware, but what you describe > is the "Four Horseman of the Infocalypse" [1]. Instead of stupid backdoors, couldn't legislators simply say that if encryption is used to try to hide a crime (that still have

Re: several GPG smartcards connected at the same time

Il 09/08/2016 10:27, Justus Winter ha scritto: >> If GnuPG supported PKCS#11 it would open a whole new world, like the >> ability to use generic cards. > We have such a module: http://scute.org/ That's exactly the opposite: Scute allows a PKCS#11 app to access an OpenPGP card (but isn't it redunda

Re: several GPG smartcards connected at the same time

Il 09/08/2016 02:39, NIIBE Yutaka ha scritto: > Currently, this configuration is not supported by scdaemon. I don't > know any portable technical solution (supporting GNU/Linux, Windows, > and MacOS X, etc.) to handle multiple card readers (and/or cards) > simultaneously by a single application.

Re: How to sign a PDF using a DNIe

Il 28/06/2016 04:16, NIIBE Yutaka ha scritto: > I think that it is opposite way what we should make it possible. Let > a government accept signature which is generated by our own > smartcard/token with free software. Or let a governor certify our own > public key, where the private key is in our

Re: gnupg-pkcs11 status & future

Il 26/02/2016 16:02, Peter Lebbing ha scritto: >> Rotating does only make sense if you take the old key soon offline. > Why is this the case? I must admit I'm fairly comfortable not rotating > my keys (which are on OpenPGP smartcards). But I can think of lines of > reasoning where it makes sense t

gnupg-pkcs11 status & future

Hello all. Is gnupg-pkcs11 still maintained? Files on sourceforge are from 2011... The idea of using a "standard" key container for GPG keys is appealing, and it could solve my (very personal, I admit, but maybe others feel the same) "problem" with having only 3 keypairs (for example I can't rota

Re: Use of --passphrase-file

Il 19/02/2016 15:17, Harman, Michael ha scritto: > Thanks Brian. I think I tried this but I couldn’t figure out how to > completely hide the passphrase so no one could get to it. Maybe I was > using it incorrectly. Since this is an unattended operation that runs > day and night, I wanted to secure

Re: Key selection order

Il 14/01/2016 21:06, Andrew Gallagher ha scritto: > Tofu does not guarantee identity persistence. Just because your > correspondence hasn't been obviously tampered with (yet) does not mean that > someone hasn't been MITMing you all along and biding their time. As usual, it depends on your attack

Re: Key selection order

Il 14/01/2016 18:04, Andrew Gallagher ha scritto: > ... which is why you should never use ToFU. There is no known method of > secure communication that does not involve out of band verification. I disagree. TOFU is what many users do anyway: identity persistence is often more important than "real"

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

Il 23/11/2015 08:56, Jan Suhr ha scritto: >> I didn't look at the code (so this could be completely wrong and I'd be >> happy!), but if the OTP key is decrypted using a key in the chip after >> verifying that the card accepts the PIN, then it's even worse, since >> that master key is in cleartext

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

Il 22/11/2015 12:55, Peter Lebbing ha scritto: > My guess is the OTP shared secret is stored in the non-volatile memory > of the microcontroller (in plaintext). That memory is reasonably well > protected against reading out (when properly configured). Sure, it's > possible with a lab, but it's not

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

Il 21/11/2015 12:07, Peter Lebbing ha scritto: > Personally, I don't really see yet why the latter is so important; > however, gaining the ability to issue OTP's by simply inserting my own > OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or is > it not part of the threat model

Re: absolutely nothing to panic over

Il 25/10/2015 08:40, listo factor ha scritto: [...] > enough, we now see the cracks in the basement: advances in > computing technology are corroding the fundamental algorithms, > one by one... Unless you move to another family of algorithms based on information-theoretic limits on what an eavesdr

Re: gpg agent forwarding (via ssh) totally broken with 2.1 and NFS-mounted $HOME

Il 21/09/2015 15:06, Werner Koch ha scritto: > You create a plain file ~/.gnupg/S.gpg-agent with this content: Why isn't the hostname included in file name? This way shared filesystems would have no problems.. BYtE, Diego ___ Gnupg-users mailing list

Re: Multiple GPG public keys with one private keys

Il 27/08/2015 08:02, Divya Vyas ha scritto: > I am looking at generating multiple public keys with one private keys. > As I have multiple identities. I dont want to generate separate keypair. You can have multiple identities associated with one keypair, eventually using different subkeys for diffe

Re: protecting pub-keys from unwanted signatures

Il 16/08/2015 18:04, Einar Ryeng ha scritto: > Is there any other problem arising from someone signing your key without > "permission"? The only problem I see is that you can easily get associated with the wrong people. Like what happened here in Italy with Fidobust (about 25 years ago): some pira

Re: Optimal setup for corporate keys

Il 20/07/2015 02:44, F Rafi ha scritto: > We will have decryption processes on multiple servers. So if one server > happens to get compromised, I want to avoid the disruption of reaching > out to 40 partners to exchange keys again. We would only reach out to > the affected partners with new keys.

Re: gpg-2.1.6 scdaemon: cannot disable OpenPGP application

Il 09/07/2015 06:56, NIIBE Yutaka ha scritto: > Currently, in the source code of GnuPG, we have support of following: > DINSIG (DIN V 66291-1) > German Geldkarte > OpenPGP card > pkcs#15 card > SmartCard-HSM > Telesec NKS card So I could use any pkcs#15-formatte

Re: [Announce] GnuPG 2.1.5 released

Il 12/06/2015 02:34, NIIBE Yutaka ha scritto: > http://www.g10code.com/docs/openpgp-card-3.0.pdf Really interesting! Especially section 4.1.3: IIUC, that allows for out of band authorization of the crypto ops. I'll have to study better the code for GnuK and how to make that little beast^H^

Re: Hardware Keyring

Il 09/06/2015 10:19, Antoine Michard ha scritto: > - FST-01 : Can be entropy device > (NeuG ), can be > upgraded (need ST-LINK/V2), Only one enclosure with no attach. And Open > Source Too That's the one

Re: s2k-cipher-mode default

Il 02/06/2015 20:37, Daniel Kahn Gillmor ha scritto: > But if we move to AES-256, we remove this attack, which means > that none of our users get thrown under this particular bus. What if by changing to AES-256 you end up saving one from the bus by throwing all users under the train? IIRC, I read

Re: Whishlist for next-gen card

Il 01/03/2015 21:54, Peter Lebbing ha scritto: > No, I'm talking about that as well. And I don't think the fingerprint of > the host is part of the signed data or the signature. Why do you think the > fingerprint of the host is part of that? Because I didn't remember well the SSH protocol... > By

Re: Whishlist for next-gen card

Il 27/02/2015 19:43, Peter Lebbing ha scritto: > I don't understand the practical difference between HOTP and the button > to confirm an action. That the HOTP doesn't need HW support so it can be implemented in standard smartcards. >> If that info is embedded in the signature packet, it could add

Re: Unattended signing

Il 25/02/2015 00:01, Peter Lebbing ha scritto: > On 24/02/15 23:16, Daniel Kahn Gillmor wrote: > If you asked me to /destroy/ the key, I would look through my drawers for all > backups I have and do a "shred" on them, and think really hard where any > further > copies might have ended up. Use a s

Re: Whishlist for next-gen card

Il 22/02/2015 01:46, Yuji -UG- Imai ha scritto: > For token type card, how about appending one more usb port to connect > keyboard? It's just for inputing PIN/passphrase or out-of-bound auth > by hitting the Enter key. USB ten keys like V7 KP0N1-7N0P Numeric keypad > looks suitable for this purpos

Re: Whishlist for next-gen card

Il 21/02/2015 17:54, Daniel Kahn Gillmor ha scritto: > If the malware is keeping the session keys around, it can just keep the > session keys for everything you ever decrypt, and use them anyway to > access your encrypted documents, independent of your button-presses. Or just sniff the PIN. > You

Re: Whishlist for next-gen card

Il 21/02/2015 12:51, Peter Lebbing ha scritto: >> 1 - support for more keys (expired ENC keys, multiple signature keys) > Yes! This would be a great feature to keep expired encryption keys on a card. > I > personally would have no use for more than 1 signature and 1 authentication > key, > but I

Re: Help need to use truecryt + openpgp applet.

Il 21/02/2015 12:26, Peter Lebbing ha scritto: >> Or use a plain USB stick. > Hehe :). I think what Diego means, is that a SIM card can still be protected > by > a PIN. You would need to enter the PIN before you had access to the SMS, > similarly as the private DO's on the OpenPGP card. Exactly.

Re: Help need to use truecryt + openpgp applet.

Il 21/02/2015 03:01, Matthias-Christian Ott ha scritto: [...] > it finds PKCS #11 objects on the card). That said, I doubt using the > private DOs for PKCS #11 objects and associated metadata will be > generally accepted (other people could be storing other data in these > data objects), so you wo

Re: Whishlist for next-gen card

Il 20/02/2015 16:07, Ville Määttä ha scritto: 5 - possibility to export private keys to user-certified devices That pretty much defeats the point of using a smart card in the first place. >> That's not "uncontrolled export", and in fact… >> …(snip)… >> while importing a key (so tha

Re: Whishlist for next-gen card

Il 20/02/2015 11:36, Jonathan Schleifer ha scritto: >> 1 - support for more keys (expired ENC keys, multiple signature keys) > And maybe for storing a certification key with a different PIN. Wasn't it covered by 2 - different PINs for different keys ? :) >> 5 - possibility to export private keys

Whishlist for next-gen card

Hello all. What I'd like to see addressed in future card specifications: 1 - support for more keys (expired ENC keys, multiple signature keys) 2 - different PINs for different keys 3 - separate key for NFC auth (with its own optional PIN) 4 - HOTP PINs for signature/certification keys 5 - possibil

Re: SSH generic socket forwarding for gpg-agent

Il 13/02/2015 23:23, Daniel Kahn Gillmor ha scritto: > The traditional argument against this sort of feature is that someone > with control over your local socket would most likely have control over > your graphical environment, and therefore could dismiss or hide any > prompt that comes up (so th

Re: Talking about Cryptodevices... which one?

Il 28/01/2015 02:46, NIIBE Yutaka ha scritto: [...] > specification (and with SHA256). It's default s2kcount is 192 as the > MCU is slow enough, but you can configure it at compile time (like > 65535 for host PC, or more). Uh, I think this exposes a weakness: if the attacker "somehow" accesses th

Re: Crypto device where I need to confirm every operation?

Il 22/01/2015 21:08, Daniel Kahn Gillmor ha scritto: > If anyone is considering adding this kind of feature to the FST-01, i'd > be happy to test and debug it with them. I proposed to add a button to FST-01 ages ago (IIRC it still was just a project on Seeedstudio...), as "user presence test", and

Re: Vanity Keys

Il 13/01/2015 16:34, David Shaw ha scritto: > I like the idea of adding a proper fingerprint to signature packets. I seem > to recall this was suggested once in the past, but I don't recall why it > wasn't pursued. What I don't understand (surely because of my ignorance of GPG inner working) is

Re: Randomized hashing

Il 27/11/2014 14:45, Peter Lebbing ha scritto: On 27/11/14 13:04, NdK wrote: (note that r is not signed, as the rhash scheme suggests and the paper confirms!) "In contrast to a previous proposal by the same authors, the salt r does not need to be included under the signature."

Re: Randomized hashing

Il 27/11/2014 11:28, Peter Lebbing ha scritto: [Resending to list] > Perhaps I should add that it takes real research and formal proof to show that > this randomized hashing doesn't add attack vectors, and I have been glossing > over that. But that is because at a glance it looks like such resear

Re: digest-algo SHA256, SHA-1 attacks

Il 26/11/2014 20:39, Peter Lebbing ha scritto: > On 26/11/14 20:31, NdK wrote: >> Well, IIUC with rhash you're giving the attacker another mean to tamper >> with your message. Unless 'r' is chosen deterministically. > 'r' is randomly generated for ea

Re: digest-algo SHA256, SHA-1 attacks

Il 26/11/2014 20:15, Peter Lebbing ha scritto: > Has something like randomized hashing[2] been considered by the OpenPGP > standardization people? Well, IIUC with rhash you're giving the attacker another mean to tamper with your message. Unless 'r' is chosen deterministically. But then it can be p

Re: Pros and cons of PGP/MIME for outgoing e-mail?

Il 26/11/2014 15:30, Bjarni Runar Einarsson ha scritto: > And if we further factor in viruses and phishing and > exploits and spam, then widely deployed PGP/MIME might make the real > world less secure, not more. :-P Maybe including a mandatory proof-of-work that includes addressee identity might

Re: Backup of encrypted private key on uncontrolled disks

Il 20/11/2014 18:33, Dave English ha scritto: > Hint: do you always wear a hood over your head and the keyboard when entering > your passphrase? Could simply use different passphrases for regular use and backups... BYtE, Diego. ___ Gnupg-users mailin

Re: Encryption on Mailing lists sensless?

Il 18/11/2014 19:15, Mirimir ha scritto: > What distinguishes a mail list from email with bcc? Software? Size? That you're sending to a *single* address that hides the others. > As long as messages were separately encrypted to each recipient, no > third parties would be involved. But: 1) you shou

Re: Why the software is crap

Il 14/11/2014 18:24, da...@gbenet.com ha scritto: > I have a clean install of 64 bit LXD - all programmes are working 100 per > cent. My keys get > imported perfectly - every programme including Enigmail knows they are there. > But when I try > to sign or sign and encrypt I get the error referre

Re: Why the software is crap

Il 14/11/2014 13:24, da...@gbenet.com ha scritto: I have cooled. You can export your private key - you can export your public key. You can import your private key you can import your public key. In 20 years I have always had the same problem - the same error message and have each time created

Re: Why the software is crap

Il 14/11/2014 12:41, da...@gbenet.com ha scritto: I usually just lurk, but that's too much... I even tried exporting my private and public key from the command line and then tried importing. The same error message as before. I have checked on the internet - most of the suggestions are crap -

Re: auto refresh for expired certificates

Il 25/10/2014 20:09, Hauke Laging ha scritto: > I would like to suggest a new option for GnuPG (mainly intended for the > config file) which would automatically try to import an update for the > certificate if it has expired (both from the standard key server and > from the preferred one if set

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

Il 15/08/2014 12:31, Peter Lebbing ha scritto: > So if you had a smartcard with a lot of storage, you could copy the key > material of your old keys, taken from your secure backup, to the card > and keep on using a card to work with the keys. That's what I was doing with MyPGPid: a 144k Javacard c

Re: OpenPGP card feature request: as many encryption-capable keys as technically possible

Il 15/08/2014 02:18, Peter Lebbing ha scritto: > The problem is expiring a encryption-capable subkey on an OpenPGP > smartcard, replacing it with a new one. > Currently, the OpenPGP smartcard only allows a single > en-/decryption-capable key. That's exactly why I started MyPGPid project. Too bad I

Re: using different encryption key in evolution

Il 10/07/2014 21:44, Richard Ulrich ha scritto: > Is there a way in evolution to explicitly state which encryption keys to > use? > Judging from the gpg manpage, it could be done on the commandline, but > that would be difficult to then send as a regular email, I guess. Try putting the individual

Re: Key distribution via NFC

Il 04/07/2014 05:54, Robert J. Hansen ha scritto: > If someone asks you for your certificate, you don't have to > trade a SHA-1 fingerprint -- just put down your keychain and let the > person wave a cell phone over it. Just place in the tag the URL where to retrieve your key. > Obviously there ar

Re: Why create offline main key without encryption capabilities

Il 01/06/2014 16:17, Hauke Laging ha scritto: > There are certain risks using the same RSA key for encryption and > signing. If you make a blind signature over data someone supplied then > you unintentionally decrypt the data (and send it back). Then you're using RSA the wrong way. You should *n

Re: what hardware entropy usb key equivalent Simtec entropy key take ?

Il 25/05/2014 20:57, tux.tsn...@free.fr ha scritto: > As you know it is not more possible to buy a Simtec entropy usb key since > many years, so my question what hardware entropy usb key do you recommend now > to replace it (not too expensive) ? > PS: need to be compatible with GNU Linux / Debi

Re: Managing Subkeys for Professional and Personal UIDs

Il 04/05/2014 14:43, Robert J. Hansen ha scritto: > Because the law says the document must bear the President's signature, > not that of a functionary acting on the President's direction. Just 'cause the law lays *way* behind technology: when it was created, they couldn't think of "autosign" machi

Re: Managing Subkeys for Professional and Personal UIDs

Il 03/05/2014 05:01, Robert J. Hansen ha scritto: > And regardless of whether it's a good practice or a bad one, I've worked > in businesses that have done exactly this -- so it's a real-world > example that demonstrates the occasional need for a third party to > possess signing keys. That practic

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

Il 03/05/2014 10:50, Nicholas Cole ha scritto: >> Well, if ownertrust answers that, it's what I need: a way to say "I am >> sure this key belongs to X, but I don't want it to be used to introduce >> more keys in the WoT". > But it doesn't work like that anyway. Unless you are using Trust > signat

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

Il 03/05/2014 01:10, Daniel Kahn Gillmor ha scritto: > Having such an assertion cryptographically bound to the OpenPGP > certificate in parseable form implies in some sense that you think a > mechanical process (e.g. WoT calculated validity) should be able to make > use of it. But how would that

Re: Signature without policy meaningless? (was Re: UI terminology for calculated validities)

Il 02/05/2014 17:12, Peter Lebbing ha scritto: > I don't quite understand. If I know someone, I can talk with them about how > they > verify ownership before they sign. Then I can judge whether I agree and assign > ownertrust accordingly. Too bad (IIUC) you can't say "I certify that this person i

Re: Subject: openpgp card and basiccard RNG

Il 13/02/2014 23:20, Werner Koch ha scritto: [JavaCards] > I am not interested in those small applications on the smartcard as long > as I can't scrutinize the real code, i.e. the OS. Whether those > applications are written for a p-code system (JavaCard, BasicCard) or > for the native CPU doesn'

Re: Subject: openpgp card and basiccard RNG

Il 13/02/2014 21:29, Peter Lebbing ha scritto: > Although I think there's a trend towards more openness, and I learned a while > ago that you can get crypto-capable JavaCards these days without requiring an > NDA. I've been able to work on JavaCards w/o having to sign anything (except the transac

Re: Setting up shared access to gpg on a UNIX server

Il 31/01/2014 01:29, DUELL, BOB ha scritto: > A couple folks (Diego and Johannes) mentioned using a smartcard or a > token. I think a smartcard refers to a piece of hardware, but I > don't know what a "token" means. Our server is in a datacenter and > I'm sure I cannot attach any sort of hardwar

Re: MUA "automatically signs keys"?

some way to alleviate that but only if the > tools support it. I tried looking around for some tutorials about notations, but could only find minimal information ("it's a string in 'tag@domain=value' format"). IIUC in *my* policy I could specify that when signing a key I us

Re: Setting up shared access to gpg on a UNIX server

Il 30/01/2014 02:14, DUELL, BOB ha scritto: > I will appreciate any and all comments. If there is a "better way" to do > this, I'd love to learn. Every user in the group could "leak" the secret key. At least put it into a smartcard/token connected to the server: they'll just be able to *use* it.

Re: using an OpenPGP card with Java (keytool and jarsigner)

Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto: > Does anyone know if there is any chance of using an OpenPGP smart card for > Java? I know that GnuPG doesn't support PKCS#11, but I was wondering if > things work the otherway around: java using the OpenPGP card. It would be > super usefu

Re: USB key form-factor smart-card readers with pinpads?

Il 06/01/2014 10:34, Werner Koch ha scritto: > To make use of the decryption key the smartcard first requires that a > VERIFY command is send to the card. This is what asks for the PIN. > After a successful verification of the PIN the card allows the use of > the PSO Decrypt command until a power

Re: sign encrypted emails

Il 03/01/2014 11:28, Hauke Laging ha scritto: > But I do not suggest to make my configuration the default. I just want > to be able to use it. Sometimes it's best to send a signed cleartext > message, sometimes to send an unsingned encrypted message, sometimes a > first signed then encrypted me

  1   2   >