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: 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

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: 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: 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: 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: 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 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: 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 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: 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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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

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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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 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 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: 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: ? 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: ? 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: 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: 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: Why trust gpg4win?

Il 10/09/2013 00:29, Pete Stephenson ha scritto: >> USB is a peer protocol. There's an astonishing amount of computational >> power on both sides of that USB cable. Protocol negotiation is complex. >> Put it all together and you get a peer-to-peer protocol which you >> *cannot* secure because (

Re: Why trust gpg4win?

Il 10/09/2013 14:19, Werner Koch ha scritto: >> First error: USB is *not* a peer protocol. It's master-slave. FireWire >> is a peer protocol. > However, that is implemented by computers at boths ends and the software > there may have backdoors or explotable code which coult be used for all > kind

Re: Why trust gpg4win?

Il 11/09/2013 11:48, Pete Stephenson ha scritto: > Actually, I was thinking of something that was the exact opposite: > some device (which I don't think exists) that would allow one to > connect a USB flash drive to the device, and have the device convert > that into RS232 serial data for the comp

Re: Attacking an offline system

Il 12/09/2013 19:07, Peter Lebbing ha scritto: > The filesystem is also still there with this USB-via-serial-port thingy. And > on > the CD. Nope. W/ Vinculum module you send it commands like "open mickey.txt" and then "read 1024". The filesystem driver is in the module and your interface only re

Re: Why trust gpg4win?

Il 12/09/2013 23:10, Marko Randjelovic ha scritto: > All the time I read suggestions on using USB sticks and I must say > people are crazy about USB sticks. It is more convenient to use optical > media then USB stick because they are read only. Boot from Live CD, not > from USB stick and use USB s

Re: Why trust gpg4win?

Il 13/09/2013 11:33, Jan ha scritto: > My "security perimeter" should be "equal" to the maximum of the > "security perimeters" of my usual communication partners. That is so > because with their private key they protect my mail and with my private > key I protect their mail. What is "usual" is not

Re: Why trust gpg4win?

Il 13/09/2013 21:12, Jan ha scritto: >> How can you check there isn't a weakness in RNG, for exampel [...] > There are statistical test with which you can test whether a random > number generator produces for instance uniformly distributed numbers. > This in connection with the above procedure mig

Re: How to find and verify a trust path?

Il 17/09/2013 22:01, Philip Jägenstedt ha scritto: > That's fine, I'm just trying to figure out what others do to convince > themselves that (e.g.) the GnuPG dist sig key is trustworthy-ish and > if there are any tools to help with the boring bits. I think "stability" is what most newbies (and pro

Re: Question about a perfect private Key store for today's environment

Il 21/09/2013 23:06, Aleksandar Lazic ha scritto: > What solution is available for public Web mail providers like gmail, > gmx, hotmail, .? Firefox+GreaseMonkey+script to interface to card? BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnu

Re: Question about a perfect private Key store for today's environment

Il 22/09/2013 20:43, Aleksandar Lazic ha scritto: >> Firefox+GreaseMonkey+script to interface to card? > Your solution implies that you need to install all this components on > all devices. Sure. Unless you want to trust someone else to handle your keys. But then don't be surprised if who have som

Re: standardized security levels

Il 11/10/2013 07:24, Hauke Laging ha scritto: > My OpenPGP specific aim is that such a standardized list would be implemented > in OpenPGP applications, probably as a signature notation. The typical user > would have several keys (for the same address) at different security levels. > Thus the s

Re: New GPLv3 OpenPGP card implementation (on a java card).

Il 15/10/2013 11:41, Pete Stephenson ha scritto: > On Tue, Oct 15, 2013 at 7:42 AM, Ann O'nymous wrote: >> If anyone is interested I wrote a java card implementation of the OpenPGP >> card and released it under the GPLv3 I'm 'more or less' (no time ATM :( ) working on extending standard GPG card p

Re: Does anyone use an NXP JCOP J3A smart card?

Il 14/11/2013 17:42, Ruslan Sagitov ha scritto: > I’m looking for a combo of a SCM SCR3500 card reader and a NXP JCOP J3A > smart card. I want to know whether this combo works with GnuPG or not. You have to load an OpenPGP-compatible applet to the card. It's not too hard, since that card supports

Re: Smart card reader security

Il 27/11/2013 08:36, Werner Koch ha scritto: >>> smart cards readers are fun to play with. IIRC, there have been >>> demonstrations turning the doctors health card terminals and PIN+chip >>> terminals into space invaders consoles. >> Do you have a source for that? I'd love to see some video or so

Re: Any future for the Crypto Stick?

Il 01/12/2013 20:09, Tristan Santore ha scritto: > You might want to check out the Yubikey guys. They make a yubikey with > an openpgp applet. > https://www.yubico.com/2012/12/yubikey-neo-openpgp/ Yubikeys would be interesting, if only it would be possible to develop personal applets to load on 'e

Re: Any future for the Crypto Stick?

Il 03/12/2013 15:30, Mark H. Wood ha scritto: > I wonder how feasible that really is. The system surrounding the card > is not under control of the card's manufacturer or anyone who might > have corrupted him. All it takes is one knowledgable person watching > the data stream for interesting ano

Re: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?)

Il 08/12/2013 14:15, Mark Schneider ha scritto: > A little security is not real security. There always can be backdoors in > the firmware (BIOS, closed source drivers etc). Why is everyone thinking 'BIOS' as backdoorable piece of sw? Why not the hard disk? http://spritesmods.com/?art=hddhack Just

Android and E2E security

Hi all. Seems someone is actively working on securing phones in an user-effortless way... http://www.techthefuture.com/technology/cyanogenmod-brings-system-wide-secure-messaging-to-android-phones I've only had a quick look at it and something yet doesn't "sound right", but might be just an impre

Re: Revocation certificate for sub key?

Il 13/12/2013 23:56, adrelanos ha scritto: > Is it possible to create a revocation certificate just for sub keys and > not the master key? I can't see how it can be useful... > This would be useful for offline master keys. Trusted persons could be > given the revocation certificate for sub keys a

Re: Possible to combine smartcard PIN with key password?

Il 22/12/2013 04:13, adrelanos ha scritto: > Or in other words, is it possible to store an already encrypted > (password protected) gpg private keys on a smartcard? So the smartcard > never gets to see the plain key? That would be really useless: smartcardneeds the key to *do* crypto ops! It's not

Re: Possible to combine smartcard PIN with key password?

Il 23/12/2013 19:29, adrelanos ha scritto: > This would be lucky, if one could enter the PIN using an external keypad > (possible) AND a password using the keyboard (not possible). I'd like it was possible, but for other reasons: that would mean you could instantiate an object in card's RAM, havin

Re: Possible to combine smartcard PIN with key password?

Il 24/12/2013 02:41, adrelanos ha scritto: > Adversary capabilities: > - Can physically steal the smartcard. > - Capable of dismantling a smartcard to extract the key its holing. > [Maybe not now, but maybe in a few years the tool required to so so will > be available. Only making up the scenario

Re: Printing PGP Businesscard

Il 24/12/2013 10:18, Ralph J.Mayer ha scritto: > is there an easy way to print your PGP-key on a piece of paper in a > nice way? Maybe using QR code? At least for the fingerprint, or a reference URL. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-us

Re: Possible to combine smartcard PIN with key password?

Il 27/12/2013 01:42, adrelanos ha scritto: [...] >> You're saying that he can lockpick your security door but can't break >> the glass of the window nearby... > I don't understand how you get to that conclusion. You're assuming that breaking into a smartcard is something easy, while it's the most

Re: deleting secret key not implemented

Il 31/12/2013 14:49, Kristian Fiskerstrand ha scritto: >> But how do I go about deleting it if I can't do it through gpg2? >> Can I do it manually somehow? > Get the keygrip as gpg2.1 --with-keygrip -K uid and delete the > corresponding file(s) in $GPGHOME/private-keys-v1.d. The form should > be .

Re: ePGP extension for mobile

Il 31/12/2013 17:11, ved...@nym.hush.com ha scritto: > As phones are increasing in memory and processing power, > maybe an app could be developed to use a smart card usb reader on a phone. Since many phones already have NFC, why not use an RFID-capable Javacard w/ openpgp applet? No extra reader t

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

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: 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: 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: 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 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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."

  1   2   >