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, especially given > the new European legislation (GDPR). We needed to develop a > justification for this. We had registered by U.K. Information > Commissioner's Office (https://ico.org.uk) , hired certified Data > Protection Officer etc. Then, again IMVHO, you should have registered in a country that's supposed to *remain* in the EU... > For now we have connected notaries only in Tel Aviv and Kyiv. CACert does have quite a lot of notaries, but they're still not enough for an average user: I made a 600km trip just to meet one. It's simply not good at the economic level: I can buy a smartcard with an already legally recognized and binding signature for 3y at 50€ (IIRC). Moreover, if you just verify the mail address you're not identifying the user, just "someone that currently controls that address". The same can of worms faced by LetsEncrypt with DV certs. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 enough" distro that you can assume has not been tampered with. Maybe one from an old CD. Once you've bootstrapped the system, it all becomes easy :) BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 it to check the signatures. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 'randomness' while the keys and the logic were in the >> central layer. Trying to remove the outer layers destroyed the random >> patterns that were used as 'internal master key', rendering the rest >> completely useless. > Some people do reverse-engineering based on photons emitted by > transistors switching. These would get through this shielding. > Unfortunately, I can't find again the link to the conference talk where > I heard people explaining they did that… sorry. I think I've seen it. But IIRC it does not work with such a big slice (whole depth of the silicon slice, ~200micron IIRC). But now that you made me think about it, I remember I've seen another article where the attack was carried out from "behind" the chip. > Another kind of attack would be EM pulses / lasers for error-ing a > crypto computation, that would get through this shielding too. Fault-injection. But for cheap chips it's probably way easier to "just" use FIB (or a laser) to change the state of the protection fluses (usually just normal flash cells) then read the whole contents. > There are defenses against these attacks (well, for the > transistors-emitting-photons attack I'm not really sure), that are > deployed in secure elements. Attacks like this are tested by CC/EAL > evaluation laboratories. Hope so :) But I stay cautious when trusting certification. See the ROCA vulnerability in Infineon "secure" (smartcard) chips. > All that to say: hardware security, to me, is a way to increase the cost > of the attacker to perform an attack. All devices are eventually > vulnerable, given the right price, the point is to make attack more > costly than the benefit from breaking the card and/or than finding a way > around the card. (I'm not going to extend this point to software > security, but I'd think it most likely holds there too) Then, instead of "this chip is secure" they should just say "this chip can be cracked spending X in equipement (una tantum) and Y for every chip"... Marketing would never allow that :) > Oh, and also to say: choosing between a non-secure-element open-source > token and a secure-element NDA-ed-and-thus-non-open-source token is not > an obvious choice. As always it depends on the attack scenario. GnuK IIUC targets all those users who think a targeted attack is quite improbable or that rubber-hose cryptanalysis is end of game. If I know that extracting my key from the token costs $500, then I can choose what to do. But with a non-secure and open chip it's easier to estimate that cost (being easier and cheaper, it's more probable it gets used in universities by security students for their first attacks, usually the most fantasious ones). Quite surely it will be lower than the cost of attacking a secure chip, but probably by not that much. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 alters every other content. Say *m* is a binary file (say a tar.gz) that needs automatic processing and voilà -- you broke a perfectly good use case. Say *m* is not decrypted "immediately" but archived for later use together with other (pre-patch) files. That corruption could go unnoticed for a very long time, and when it gets noticed it could have damaged a lot of archived files... IMVHO that's really bad. And all that just because a bug isn't fixed where it belongs? A security-conscious user must upgrade the programs he uses anyway. So why apply dirty workarounds? Efail is not a GPG bug, so why should it be fixed in GPG? Sure, GPG can be more picky and throw an error instead of a warning, but please do not corrupt files that will be around much longer than any buggy mail client! BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 another repository. Unattended updates will apply it anyway and also for > users it would be hard noticing it: at least my "apt-get" version does not > show any information about the repository a package would be downloaded from > before confirming the installation. Thus the user would have to check each > single package manually by invoking "apt-cache policy [pkg-name]" or use > "apt-get download [packagelist]", check the logs and install packages with > "dpkg". Well, assume that who can publish to a repo you trust *is root* on your machine. Even if you could pin the package, what prevents him from adding a suid exe ? > Unless my system is misconfigured or other assumptions do not hold true, that > would imply, that the only security benefit from key pinning is only about > maintenance, making detection/pruning of stale keys easier. That's exactly what ther're for. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 card. But if you already generated it on-card you're toast. A possible workaround could be encrypting the password store to multiple "recipients" instead on only one (the GPGcard). Those multiple recipents can be everything you want: GPGcards, keys on disk, other people... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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.org/mailman/listinfo/gnupg-users
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 "pointing" to the master > identity, so any subkey can be reissued without having to re-register > in the system. Such a thing already exists, at least here in Italy: CIE/CNS. X509-based certs. It's got its own set of weaknesses, but since you're thinking about a trusted third party (the State), X509 is a better fit. Possibly extended by another applet that handles service-tokens (actually wrapped private keys + metadata). Anyway that's something that IMVHO does not fit well with GPG. Just my €.02 ... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 *seconds* to an attacker to brute force hashed PINs once he gets the hashed database. Salted hashes would multiply the needed time by the number of PINs (approx). So keeping such a database would be a really stupid thing to do -- unless it's kept in a HSM. Passwords have way larger key space (from 10^N for N digits of the PIN to 64^N or more for the passwords -- considering uppercase, lowercase, digits and symbols), hence salted hashes are quite secure. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 then makes two guesses, then I get > back my card and enter my correct pin, then I lose my card again, and > the same bad person finds it again and makes another two guesses, then I > get my card back again and so on? Say that's your wife/son that takes the card when you're at home... Low prob, but possible :) >> Usually there are other, non-technical ways. For example they just go to >> the bank with a death certificate. > I already have seen cases where it was not that easy in Germany. > Usually, presenting a death certificate to the bank is not enough. I > have seen that the bank had to make sure that the people presenting the > death certificate actually were the legal heirs. That meant that those > people had to acquire all sorts of documents from all sorts of > authorities which has been very expensive (several hundreds of EUR), but > more important, was very unpleasant and time consuming, especially in > the situation they were. Been there... Another reason to give the password before going with the documents might be "a bit" illegal: just transfer the money to avoid paying taxes. > But now, being a German citizen, try the same thing with eBay, Facebook, > LinkedIn, PayPal and so on ... no thanks. Why should heirs have access to social accounts? Paypal, otoh, is a bank that have to follow the same rules of other banks... > Nice ideas :-) My own security needs are not that high, though (hoping > that life won't punish me for that optimism). My concern with a singl "cleartext" pass would be a burglar that steals it together with other valuables... > To add to it, if you mistrust your relatives, you could put the password > on paper into some sort of lock box and carry the key to that lock box > with you. But then what would happen if you lost that key? Given that mechanical keys are often easier to open whithout the key than with it... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 might think, because it is > practically impossible to brute force a 4 digit pin with only 3 tries. 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. The probability to guess the correct code during the 5-years life of the card is definitely non-negligible. > And there is one more very important thing most people don't think of: > What happens if you have an accident or if you die? Your heirs will have > all sorts of troubles if something happens to you and they can't access > your electronic accounts because they don't have the passwords. Usually there are other, non-technical ways. For example they just go to the bank with a death certificate. > So I tend to write down at least my master password on a sheet of paper, > put that in a sealed envelope and give it to a relative who I highly > trust. In case I die, they open the envelope, have the master password > for my password safe and can use that to open the access to all my > accounts. Alternatively, you could have some relative you trust memorize > your master password. But since he won't use it regularly (hopefully), > he probably will forget it after short time ... Better use shamir's secret sharing, or just use LCD-segments characters printed on two acetate sheets that need to be combined to be read. Obviously the two sheets are to be given to two different people, in sealed envelopes... BTW the method you use is the same that was used for our mainframe's master password. :) BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. > Having done --learn-card once you can use the keys from the card for > X.509 or CMS (aks S/MIME) stuff. Then I don't understand the reason for gpgsm (the "niche" it fills)... opensc already supports many cards, and can even edit some. And (via PKCS#11) Firefox and Thunderbird (and many other programs, but only one at a time) can use the cards for auth (and signing). > But note, that PKCS#15 does not specifiy everything and card vendors > oftne implement proprietary extensions/modifications. As usual. But even openpgp RFCs are often implemented with proprietary extensions... > See gnupg/scd/app-p15.c for some hints. I'll have a look. Tks, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to use a PKCS#15 with GnuPG?
Hello all.
I'm trying to use an ePass2003 token (and possibly some Aventra MyID
cards) to have my keys around when I need 'em (especially for
authentication and signing). Both ePass2003 and MyID implement PKCS#15,
so IIUC they should be usable.
Too bad I can't find the needed 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
Last update: 20170615092227Z
Flags : EID compliant
PIN [User PIN]
Object Flags : [0x3], private, modifiable
ID : 01
Flags : [0x32], local, initialized, needs-padding
Length : min_len:4, max_len:16, stored_len:16
Pad char : 0x00
Reference : 1 (0x01)
Type : ascii-numeric
Path : 3f005015
Private RSA Key [SSH key]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign
Access Flags : [0xD], sensitive, alwaysSensitive, neverExtract
ModLength : 1024
Key ref: 0 (0x0)
Native : yes
Path : 3f0050152900
Auth ID: 01
ID : f3dcf75d07c02fd15ae7b7a335f84d46eda6049d
MD:guid: {323ba8f2-2b93-1900-fa3b-e1b4d2024011}
:cmap flags : 0x0
:sign: 0
:key-exchange: 0
Private RSA Key [Signature key]
Object Flags : [0x3], private, modifiable
Usage : [0xC], sign, signRecover
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref: 1 (0x1)
Native : yes
Path : 3f0050152901
Auth ID: 01
ID : 9e67a012e0e45f3ae9b1398b912bbf2ba1aef2d4
MD:guid: {6c1033ed-c1df-5baa-4e87-5be41c0a8b03}
:cmap flags : 0x0
:sign: 0
:key-exchange: 0
Private RSA Key [Decryption key]
Object Flags : [0x3], private, modifiable
Usage : [0x22], decrypt, unwrap
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref: 2 (0x2)
Native : yes
Path : 3f0050152902
Auth ID: 01
ID : 7db41d5b2c07355dd361e0bffd543c0cfc51953b
MD:guid: {08884d6f-15a7-1ade-7183-04d4a4e6bc6f}
:cmap flags : 0x0
:sign: 0
:key-exchange: 0
Public RSA Key [SSH key]
Object Flags : [0x2], modifiable
Usage : [0x40], verify
Access Flags : [0x0]
ModLength : 1024
Key ref: 0 (0x0)
Native : no
Path : 3f0050153000
ID : f3dcf75d07c02fd15ae7b7a335f84d46eda6049d
Public RSA Key [Signature key]
Object Flags : [0x2], modifiable
Usage : [0xC0], verify, verifyRecover
Access Flags : [0x0]
ModLength : 2048
Key ref: 0 (0x0)
Native : no
Path : 3f0050153001
ID : 9e67a012e0e45f3ae9b1398b912bbf2ba1aef2d4
Public RSA Key [Decryption key]
Object Flags : [0x2], modifiable
Usage : [0x11], encrypt, wrap
Access Flags : [0x0]
ModLength : 2048
Key ref: 0 (0x0)
Native : no
Path : 3f0050153002
ID : 7db41d5b2c07355dd361e0bffd543c0cfc51953b
$ gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
But:
$ gpg2 --card-edit
gpg: OpenPGP card not available: Not supported
gpg/card>
Well, actually it's not completely unexpected, but then I don't
understand why scdaemon is now locking my token, if it doesn't know how
to handle it:
$ pkcs15-tool -D
Using reader with a card: Feitian ePass2003 00 00
Failed to connect to card: Reader in use by another application
What am I missing?
Tks,
Diego
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 was looking for.
I'll probably put that in a script that immediately re-encrypts the
session key with the public key of the newly authorized user.
Then he'll decode the session key and use it to decrypt the archive.
BYtE,
Diego
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 encryption must be automatic, not done by an user. So, IIUC, the scheme you're suggesting given this limitation is what GPG already does when encrypting to a recipient's pk: generate a symmetric key, use it to encrypt the file, encrypt that key with recipient's pk. And it (hopefully) does every step in the safest possible way -- surely much safer than anything I could do from a script. What I'd need is some way to "extract" that temporary key (using the recipient's secret key, obv) and then immediately reencrypt it with another recipient's pk. Or (that's equivalent) add another recipient to the already encrypted file, w/o reencrypting the whole file. > Then you can reecrypt archive on one of the servers with new DEK > dedicated for that user. Or just let it be so. If user gained an access > to archive he could always decrypt same archive again. As I said, that's not a problem: once he's had access to a file, that's "forever" (I cannot avoid he saves the file in plaintext). But he must not be able to decrypt other files from the archive. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 appropriate > mode. Problem: the symmetric key (DEK) must remain in plaintext on the server. It's a relatively secure setup, but I prefer *not* to risk. Even if that means a slightly more involved process. If the server gets compromised, the attacker can only access new datasets, at most, not the historic archive. Moreover, with your proposal, once I give an user access to one file, he'll be able to decrypt *any* other file too. If I keep track of who can access every dataset and some day I find some datasets are being used "illegally", I can restrict the suspects. > Of course, such way doesn't allow you to revoke access to DEK since each > user could just decrypt his own copy. Since encrypting to a public key generates a random session key, the session key gives access only to that single file. Obviously that access can not be easily revoked (the user could have saved a plaintext copy anyway, so that's not a big issue). > A bit more complicated approach is to use two level system: > - generate data encryption key (DEK); > - generate key encryption key (KEK) for each authorized user; > - encrypt each user's KEK on each user's public key; > - create a table (tsv/csv or any other format) with some user id and DEK > encrypted with corresponding KEK and store it with data; > - encrypt data with DEK. That's the same of encrypting the DEK with multiple public keys. The problem is that I don't know in advance the users that will need access. IIRC there was some method to retrieve the session key and replace the public key part with another recipient... > Both methods are naive and gives end user DEK, so it's better to > reencrypt archive after that to rotate DEK. That would be a big problem: archives must remain static (to avoid troubles with offsite replication). > Also, a lot depends on your threat model. Since I don't know what risks > are you planning to avoid with original scheme I just assumed that > primary risk is 3rdparty archive storage compromise. Well, I handle the storage (currently 100TB, going to grow to 150TB soon). I want to avoid that an attacker could gain access to the whole archive if he succeeds in compromising the server. Clients are out of my perimeter (= not my problem). BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 script with a lot of checks is mostly ready). But my big doubt is how to handle archive reading in an efficient way. The naive way would be to let an authorized user decode the file and reencode it for the requester, but that would mean that this authorized user should have quite a lot of space available (twice the dataset size, at least). Is it possible to "extract" the used session key, so that the requester just ignores the asymmetric crypto and just uses the symmetric key to decode the file? Drawbacks? Other ideas? Tks, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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/mailman/listinfo/gnupg-users
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 been "anonymous": an attacker that compromises multiple servers shouldn't be able to determine if two users (on the two servers) are actually the same person (or even if two users of the same site share a single token). The only link would be the attestation certificate, but that should only be checked during enrollment and not stored anywhere (once the user is enrolled, the attestation cert is useless since only the site-specific pubkey is needed). With X509 (or GPG) certs the user's identity gets linked, for the joy of nosy orgs. @NIIBE : the sites don't send "proprietary JS" to the browser to access the token (needed code is public) but the browser must support U2F API. That's native in Chrome, but Firefox requires a plugin (and I don't know what's the status of other browsers). PS: it's not clear what happens when the attestation cert expires: does the token become useless for enrollment? PPS: the "attestation CA" could even be the GPG 'C' or 'S' key, that the server could check via WoT. That does not require 'C' or 'S' key to be on the token: the attestation certificate can be generated on an offline machine. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 on glass etched microfiche if you really want to cover that > timespan. Well, when considering such a timespan there could be other (bigger) issues... How long a today 'secure' key will remain secure? When will quantum computers be widely available? The only "guaranteed" crypto is information-theoretic one (neural networks mutual learning, distant noisy sources, etc), where adversary's probability of success is a function of the system parameters. But it's quite impractical and AFAIK covers only interactive key agreement. PS: in 100 years surely I won't (be here to) care if someone will be able to read my mails or not :) BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 expensive WoT checks. By loading your key, you're certifying it's yours. But it won't actually give any more assurance than "you is you" than your credentials (against GitHub): if someone steals your credentials, he can replace your pub key and sign new commits in your name. They're using GPG just as a frontend for signatures using self-signed certificates. BTW nothing prevents you from uploading your key to the keyservers and participate in the WoT -- that's the only thing that could assure who clones your repo that *you* signed those commits. Sometimes just "key persistence" is important (i.o.w. that the key that signed all the commits has always been the same, and in this case GitHub loaded key can be enough), other times it could be important to link the key used for signing a commit to (the reputation of) a real person, and in this case the WoT is needed. > Just some quick links in connection, for the less familiar. > For users (like me): > https://help.github.com/categories/gpg/ Some reccomendations could be quite questionable (always use RSA 4096, do not set an expiry on main key, no mention of generating a revocation certificate...). BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 sure which key is mine, you need to get my
>key fingerprint from me or follow a chain of signatures. If a phony
>key appears to be signed by someone you trust, you should see what's
>up with that person."
>
>
> and 4th sentence from the top at
> https://stallman.org
> >"If you want to send me GPG-encrypted mail, do not trust key servers!
>Some of them have phony keys under my name and email address, made by
>someone else as a trick. See gpg.html for my real key."
Why do you find it strange?
Keyservers are just public write-only repositories that do not attempt
to verify the keys.
You have to verify the keys via the WoT (web of trust: "follow a chain
of signatures"), or by other means ("see gpg.html for my real key"), and
that's what Stallman says. Better do both: check that the chain
identifies the key given in gpg.html (must be retrieved via https).
BYtE,
Diego
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 with one of the last MS > patchdays... I think it could even be realated to some HW issue. Are fans clean? Are capacitors OK? Electrolytic ones, the tall cylinders, often tend to "explode": they usually have an 'X' on the top and that should be flat and clean, else the capacitor is surely bad. Did you run a RAM test? And a CPU test? I know, it's just a remote possibility, but given the "randomness" it could be worth checking. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 a real time service only makes sense for ephemeral > comms. But it's just a form statement by the authority which the > sender appends to their signed data. My aim is something that's still secure even if some big leaps happen. Say QC becomes feasible: current pki methods (RSA and EC) are to be considered insecure. Hence I included a PQ signature (maybe NewHope?). > Trying to protect against future compromise of a signature algorithm is > really hard. And once you open that door, all data at rest signatures > are questionable. Well, actually symmetric crypto could be used with a system like the one used for one-time signatures: you sign both the (hash of the ) plaintext and the hash of the cyphertext obtained encrypting that plaintext with a (randomly generated, single use) secret key. This system allows a single arbitration: you give the judge the secret key used and he verifies that: a) the hash on the plaintext matches the signed one (everyone ca do this) b) the hash on the cyphertext matches the signed one (everyone ca do this, too) c) the hash of the plaintext encrypted under the given key matches b) A timestamping service could easily generate such a key from a "really secret key" (never disclosed) and the timestamp, maybe using a truncated hash (to prevent a possible hash inversion attack to determine the "really secret key") and remain able to disclose it to the judge without compromising other signatures' security. An attacker should be able to find another (meaningful!) messages that hashes to the same value and whose cyphertext under an unknown key would result in the other hash value. H(p')==H(p) H(Ek(p'))==H(Ek(p)) (for every k, since he does not know k) > Merkle trees protect against this though, as not only do you have to > forge the signature, but also recreate the entire subsequent merkle > tree, which should be infeasible. IIUC, merkle trees remain secure only if they continue to "evolve". If an attacker does have enough (more than 50%) computing power, he can control the tree's growth. And possibly rewrite the history (IIRC something similar happened not long ago, when a single group of miners had had for some hours the needed "quorum"). > If you embed the OCSP response in the tree with the signed data, then > it enjoys the same protection. I have to think about this a bit more... I'm not completely sure. To be at least partially in topic, it should be possible to do the signing (and the encryption) even with the current GnuPG version... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 sure that revocations get submitted to the authority in a timely > fashion and b) working out whether to trust the authority in the first place. > But that's a problem in OCSP too. The "stapling" part is the hardest, since with OCSP usually you need to verify that something is valid "now", while with a GPG signature you should be able to attest that something will be valid "forever". The only way to obtain that (I can think of, and assuming no online verification: online services come & go...) is having at least three different kind of keys (RSA, EC, PQ) sign at least three different hash function results *each*, so that even if an algorithm or two gets cracked the signature remains valid. > In general, anything you can do in the X509 trust model you can do in PGP - > but with a little more effort and a lot fewer default assumptions. That's good: this way most "implicit assumptions" must be explicited and their security impatc must be evaluated. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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, essentially OCSP? That's the idea, but in GPG trust model... Is it possible? BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 key could also create a revocation, and they could backdate it to deny access to previously created signatures; there’s a lot of interesting design questions about how to deal with this with random beacons and the like that are beyond the scope of this blog post -8<-- 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. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 version that only includes the TRNG, and it's completely open. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 shared between two administrators. Both are required at system boot to unlock the card. If the card gets removed, no single admin can unlock it. Sure, an admin could just use it while connected to the server to decrypt files (or simply read stored files) but as others said there's no way to prevent that if the attacker have physical access to the system. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 safe with important woodware documents or > your gpg key backup isn't tamper resistant either. I prefer the free > software solution given that the attack surface is smaller. Well, actually the situation is a bit better: the keys at rest are stored encrypted, even if kdf function uses less rounds not to slow down unlocking too much... So even if an adversary manages to get the token and retrieve the memory contents, he still have to find the passphrase to decode the keys. Quite like the situation where he somehow accesses your privring from a powered down computer. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 to be proven by *other* means!) then it's like having used a gun in a robbery? That would simpli make something wrong even worst, but allow for rightful use of crypto. Sure, it's way easier to outlaw any non-approved crypto, but then outlaws will use strong crypto nevertheless... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 redundant, since OpenPGP cards are supported[1] by native opensc driver?). If GnuPG/scd supported PKCS#11 you could tell it to use a key on any non-openpgp card as a GnuPG native key (some configuration could be required). [1] https://github.com/OpenSC/OpenSC/wiki/OpenPGP-card BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. Isn't it what PKCS#11 is for? If GnuPG supported PKCS#11 it would open a whole new world, like the ability to use generic cards. IMVHO "fixing" GnuPG to handle multiple cards and readers would actually create something really similar to PKCS#11... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 own smartcard/token. That would be great, but I think it's an orthogonal issue. When you get to use a smartcard, you are already giving up a lot of control on your key, trusting something you can't control and hoping certifiers did their work correctly and the units being sold are completely like the tested ones. The support for generic cards could be useful for other reasons. Say I have a smartcard that could host 15 keys. I'd like to use one for web auth, another for NFC auth, another for signing documents, another as my primary GPG identity (certification), one for GPG auth, one for GPG signing and the others for GPG decryption (just not to lose access to older mails). Currently it's not possible, unless I use quite a lot of different cards. IMO the "ideal" solution would be a FIDO-like system, where keys are kept, encrypted, on disk and uploaded as "blobs" to the card that decrypts 'em and only then become useable. That would remove the limit on the number of keys that could be kept on a card. But it's not feasible with Java cards, I think (at least I couldn't make it work w/o writing to the flash memory). That would be completely feasible with FST-01... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 to rotate, but still keep the old
> decryption key available.
In my case: every year will have its own PIN, different from the one
used for signing, and *really* different from the one for certification.
> Think: "There's a non-zero chance that someone
> got my private key material, but at least they can only decrypt stuff
> encrypted in 2011, all other years use a different key".
Extreme case: a judge orders to hand over the key to a set of messages
('cause they won't trust your decryption). Rotating keys minimizes
exposure of other material.
> Note in this scenario it is nice if I can still easily access my
> 2011 material as well.
Exactly.
> I'm not saying this is a solid line of reasoning. I'm just curious why
> limiting access to the decryption key is the only thing that makes sense.
Well, everybody can have his own perfectly valid reasons... Why limit
keys on smartcards more than technically necessary? Years ago cards had
space only for 3 keys, but a 144K Javacard can handle many more!
And if PKCS#11 was useable, one could use as many keys as needed by his
policy.
Note that I really don't like PKCS#11, but it's the de-facto standard to
access nearly every crypto-capable device.
BYtE,
Diego
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 rotate encryption key every year unless I'm prepared to have a different card per year). With nearly every card I could have a look at, I can keep at least a dozen keypairs, so that would reduce to one smartcard every 10 years. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 the passphrase so gpg could get to it > without human intervention, but not let anyone else see or know where it > was stored. What about using a smartcard? You supply the PIN only at boot, then it stays unlocked ad long as the system is working. This way an attacker couldn't steal the secret key even if successful at breaking in. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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" identity... And harder to fake by any opponent (governments would have no problem creating "fake" identity cards, passports or anything -- after all that's what they usually do for "real" ones!). On the other hand, if you saw mails from a single address signed by the same identity for years, chances are that it's the same person, even if the name on the identity card is different. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 scenario. If I have 10-years-old mails from someone I've never met, and all use the same key, I can assume that either 1) that identity belongs to the same person or 2) that an attacker MITMed *all* my connections (from every device I've had wherever I was and to every service I used). Occam's razor and my "exposure profile" make me think it's 1) :) In other words, *time* can be considered an 'out of band' channel. For others, very "high profile", it could be possible that such an attack might be performed, even if it's quite unlikely, unless there's *a lot* of money involved. What I learnt from OpenAlarm is that there's always to balance cost and security: over a certain limit, costs grow exponentially for marginal gains in security. So the different options have to be weighted carefully: you'll have to make different choices if you have to protect a bank instead of a garage. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 somewhere outside the smartcard. So, >> with some efforts and a good lab the OTP keys can be extracted. > The key is stored in the card. Then, replacing the card replaces the OTP key. No? BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 cheap. If such adversaries are in your > threat model, my guess (again) is that the OTP feature of this stick is > not aimed at you. The whole stick (and the current OpenPGP card spec) is not aimed at me, since it lacks the "decryption key history" that I'd need :) What I don't understand is why they did not use one of the private objects in the card to store the master key: this way, if the card gets swapped, the master key becomes inaccessible and the attacker can't use the OTP secret since it's encrypted with an unavailable key. Sure, it's not perfect (the master key gets loaded in RAM of the micro) but makes any attack harder. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 because the attacker is unable to > extract the key used for OTP generation? 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 somewhere outside the smartcard. So, with some efforts and a good lab the OTP keys can be extracted. > Anyway, thanks for all your work on the Nitrokey series! I think it's > great you put so much effort into creating these nifty devices. Nifty, indeed. Too bad PGP-card spec lacks decryption key archiving (so that you can change your DEC key every year but keep using the same card year after year). BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 different purposes. But this links all your identities together, that could be undesirable in some situations. The only alternative is to generate different keypairs to keep identities unlinked, like if they belong to different people (good luck having 'em signed by others!). BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 pirates' phone lines were being tapped, and since they connected to Fidonet BBSs, those got tapped too... then their lines were tapped and the other nodes they connected to became suspects and so on. As a result, a lot of people have had their bedrooms (where they kept the BBS PC) locked for the YEARS needed by justice to do its work. That's why my skin crawls when Robert J Hansen says Except that 99% of people who see that signature will think you have an association with white supremacists. Should they? No. Will they? Yes. Especially if one of those is a judge. When the average person have to pay for a lawyer, (s)he has already lost. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. If possible, I'd go for the HSM route (openpgp card or FST-01). This way, if a server gets compromised remotely, the attacker can not get a copy of the key (but he'll be able to use it as long as his activity on the server is not detected!). If the attacker obtains physical access to the server, you're toasted anyway. Just my .02 ... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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-formatted card to keep GnuPG keys? I searched a bit but saw no docs on what needs to be done... BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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^H^H^H^H ARM handle inputs... :) Or maybe a display + buttons via i2c (as the display capability is announced by b8 in sec 4.1.3.2 . Too bad it seems still limited to the standard set of keys. No way to store old dec keys (to keep using a single card to read all the old mails, even if generating a new key every year). A possible workaround would be a parallel application on the card that when called changes the active DEC key together with the card serial no, corresponding fingerprint in C5 DO and gentime in CD DO). BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Hardware Keyring
Il 09/06/2015 10:19, Antoine Michard ha scritto: - FST-01 http://www.seeedstudio.com/wiki/FST-01: Can be entropy device (NeuG http://www.gniibe.org/memo/development/gnuk/rng/neug), can be upgraded (need ST-LINK/V2), Only one enclosure with no attach. And Open Source Too That's the one I like most, given my security needs. Remember that it's not as hardened as a smartcard if the attacker gains unsupervised physical access to it for a long enough time. But it uses ommodity hardware you can source where you prefer, so a backdoor is really *much* less probable! And the creator reads this list, too! :) The only thing I really miss is that the trust db is not in the token, but integrating it would require changes/extensions to the protocol. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 /host/ authentication I mean that you verify that the host your are connecting to is in fact the host you wanted to connect to; and /that/ is through the public key of the host, of which you can verify the fingerprint. Let's call this keypair A. That gets verified during initial key setup. After you've verified the fingerprint, a copy of the hosts' public key, A, is stored in ~/.ssh/known_hosts on your client machine. Ok, just something to help the user avoid a verification step every time. But when the host is authenticating that you are in fact the user you are claiming to be, you sign a challenge that only you could sign because you have the private key, let's call it B. That is /user/ authentication. Ok. The host checks that your public key B is in ~/.ssh/authorized_keys on the server machine; if so, you're authenticated. Ok. But the signature contains the session identifier (called H in RFC4257 sec 8), that is derived from the initial key exchange (that should then be partially handled by the card as well). Luckily there's no need to recalculate it when keys are refreshed (RFC4257, sec 7.2), so it's one-time penalty. So the card should receive (and handle) the key exchange, prompting the user to accept the public key the server sent and then allow the auth key to just sign data where the session id is the one it calculated. Might be non-banal to handle concurrent ssh sessions with overlapping key exchanges (card generates a blob --might be symmetrically encrypted with a key only known to the card-- that's cached by ssh and passed back to the card when a new auth signature is requested for an existing session id?). BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 something to the signature value (if the receiving party sees that signature is about a txt file and the presented object is a doc, there's something wrong and suspect). Are you proposing that the internal hash state after the hashing of the document is handed over to the smartcard, after which the smartcard computes the hash over the signature subpackets that you want protected this way? It's unclear to me how you see such a thing be implemented without passing all data to the smartcard. Well, IIRC there are cards that require you to compute all but the last round of the hash, then pass the last block of data and the current state to let them compute the result (and maybe do the padding before signing). Something similar could be used for this: the last block will include the shown data just before the file len. I've had a quick look in RFC 4252, with public key user authentication for SSH2. I don't think there's anything that you can show on a display that would help the user decide if it were what they wanted to see. After a really quick glance in the RFC, I see just the username and the session identifier. The username is hardly unique (I usually use peter), and the session identifier is a unique number computed for the SSH session. It's the bit that prevents signature replay attacks but is not useful to show on a display, since the user can't tell whether it's good or not: it's just the output of a hash function. For auth it should be the hash of the host's pub key, the same SSH shows you the first time you connect to that host. All this is based on a really quick read of documentation I hadn't consulted before. It could be glaringly wrong. But when you said it is the fingerprint, I wondered if you misunderstood or that the fingerprint is actually part of the challenge. I don't think it is. Since the challenge have to be encrypted to the host's pub key, you can display its hash. I'll have another look at the RFC tomorrow morning... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 smartcard and generate on-card a new key that replaces the expired one. So an attacker could still abuse the key (it's not protected) but can not extract it to keep copies around. I really like SCs for signature and authentication[*] keys since often even if those keys are lost it's not a big deal as long as they can't be abused. [*] for auth, only if there's a centralized repository for the public key, else updating all instances of the pub key stored in devices could be a major hassle. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 purpose. Micro USB plug may be prefarable for compact board design. The problem with off-the-shelf keyboards is that they usually radiate a pattern that's recognizeable from some distance. The usual scan on a matrix keyboard activates one column at a time in fixed order, then checks the rows (possibly one at a time). A safer scan activates all columns at once, senses the rows, then changes columns to inputs and rows to outputs activating only the one where the pressed key is and finally determining the corresponding column. This doesn't generate a recognizeable pattern. I don't like wireless features by two reasons. Uh? Neither do I. I never understood the reasoning behind IR receiver for FST-01. It may introduce complexity for middleware of the card. I like KISS. Another is break visibility to check HSM composition validness. Yup. And it's easily snoopable. For FST-01 spesific request, I ask gniibe to consider about case design with physical hole to tightly bind a token with keyring. That's good. But I'd avoid plastic in favour of aluminium :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. Moreover, it's often free since you don't have to buy a new card just for that use, just recycle an unused one. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 don't see a reason why you wouldn't just have a whole bunch of generic key slots and only indicate its intended usage on creation/upload so people can do that as well.[1] Yup. But if those are too generic, then it could be way cheaper to just use a generic PKCS#15 card (I've had some experiences with Aventra ones: they've got space for many keys and 14 PINs... and are quite cheap!). If ECC were supported by the card, you'd need quite a lot less storage to keep all these keys. Yup. But on a device like GnuK space is really not the limiting factor. 2 - different PINs for different keys This would partly amount to resurrecting an old feature. IIRC, there were 2 user PINs in the v1.1 spec, but the v2 spec pretty much retired the second PIN. Don't take my word for it, though, check the spec. I remember seeing an unused PIN object. [...] However, I think the primary key/subkey feature is already covered pretty well by simply having two smartcards (it's what I do). Twice the cost, twice the risk of losing one, twice the management burden... 3 - separate key for NFC auth (with its own optional PIN) Sounds like an interesting concept. I don't know how much work it would be to have the ISO 7816 parts needed by the OpenPGP card really working for NFC. Do you just exchange the lower few communication layers (physical, data, ...) and is everything above the same for the subset of ISO 7816 you need? I haven't looked at NFC yet. I started implementing it on MyPGPid. From JavaCards it's quite easy to differentiate between wired and wireless, since the applet receives the protocol used to transmit the APDU. What I'm hinting at: NFC and cards with contacts are different enough that it might warrant handling NFC separately from the rest and hence doesn't need to be integrated into the process for determining the next cards-with-contacts standard and implementation. There are dual-interface cards, and I think they're not so disjoint, once you're using secure messaging. But NFC authentication through asymmetric crypto sounds interesting. Way more than EM4100 tags or MIFARE cards. 4 - HOTP PINs for signature/certification keys What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP? No need. Just an applet on the phone could do. At least if you aren't using the same phone to do the crypto. What I'm guessing you might mean, is that the HOTP device might be more trusted than the pinpad of the card reader: the card reader is connected to the PC. The HOTP device is simply a standalone device; is air-gapped. So even if the PC is compromised, it will not be able to learn your PIN, which you entered on the HOTP device. As I said, no need for a PIN on the HOTP device. The only important thing is that it's a *different* device, better if air-gapped. Is this what you're getting at? I don't really see the use. Smartcards protect extraction of the private key; they're not equipped to prevent usage of the key material through a compromised PC. So what they can't learn your PIN; they'll just get you to enter it for them. I don' see this adding something beyond your point 6, which I'll treat there. You're authorizing a *single* operation. As you noticed, malaware could be smart enough to fool the user for decryption (where using HOTP would be foolish: you'd have to continuously generate new codes just to scan the mail), but signature is another beast. HOTP could be seen as a stronger 'alwaysauthenticate' flag. 5 - possibility to export private keys to user-certified devices I'm not terribly interested in that. Firstly, you would still need a backup of the key the data is encrypted to; the chain has to start somewhere. Secondly, provided you can have a trusted system for the generation of the keys, you could simply generate them on that trusted system, encrypt them to the key you wish to encrypt it to, and then store the encrypted data as you see fit. Unless you're doing something like SmartcardHSM, where each card gets initialized with a device attestation key (generated on-card) and its certificate, so you can choose to trust other cards as long as they're certified. A more user-centric approach would require a temporary CA (no need for long-term storage of its secret key) that the user uses to certify keys generated on his own cards. Once the cards have been certified, the CA key can be deleted. In the worst case, the user won't be able to transfer his keys to other (newer) devices. On-card generation is putting a lot of trust in the on-card RNG as well; I put more trust in Linux's PRNG on a trusted system. As long as you're generating the keys on a
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 right in the abstract: the bandwidth of the canary button (one bit of LED output secret key action requested, one bit of input ok to use secret key) is too limited to protect against the sophisticated attack you describe, and increasing the bandwidth of the channel (e.g. on-device display screen, keypad) makes the UI/UX even more infeasibile. At some point, you just have a second computer attached to your computer, and now there is room for that second computer to be compromised :/ Well, at least that one would be a dedicated computer, with very limited connection to the outside world. And if the idea of a display gets implemented, at least the kind of operation can be confirmed. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 - possibility to export private keys to user-certified devices 6 - support for out-of-band authorization (HW) 7 - support for more informative signing (requires a small display: HW) 3 to 6 should be under a policy object connected to the main key to make it public and let relying parties evaluate how much trust to give. Since smartcards have evolved (slowly...) and nowadays we have other much-less-constrained alternatives (GnuK), I feel that many limitations are just an heavy heritage that's becoming nonsensical. The reasons behind my list, point by point: 1 - I'd like to roll the key used for reading mail every year, but currently that would mean I'd have to use a new card every year or have old keys on-disk, defeating the purpose of using a smartcard/token (from my tests on actual smartcards, it's not hard to have room for 14 to 20 keys on an 80k smartcard, more than 30 on a 144k one, WAY more are possible on GnuK) 2 - If I have to use my card to login on a possibly untrusted computer, I don't want it to steal my PIN and sign/certify without me knowing it 3 - Since NFC readers often have no pinpad (or could have easily been tampered with) I don't want to expose my main PIN nor the same key I use for wired auth 4 - since HOTP changes at every use, it makes keyloggers nearly useless and gives a third factor to the auth process (might be combined by simple means -like digit-by-digit addition modulo 10- to the PIN) 5 - I know, it's debatable and many see it as dangerous... but is it more dangerous than keeping an on-disk (or on-paper) copy of the key? Key export should be protected by a certificate (policy object defines an allowed KeyID for export and the private key is exported only encrypted to that KeyID); might even set a fuse to mark the fact that the key have been exported 6 - like in Yubikey NEO, a physical button to authorize some operations can be useful (certification, signature, NFC PIN-less auth) 7 - malaware currently can replace the hash of the object being signed and the user can't know it till it's late... a small display could be used to report some metadata (file name type and size for signature, keyID and owner data for certification, peer ID for auth...) to give the user more feedback What do you think? Complete BS or could something be considered for inclusion? PS: 1 is the main reason I'm not yet using GPG much, even if I started using it since DOS FIDO-BBSs era... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 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 such a feature is implemented in HSMs to avoid unsafe key generation (outside the HSM itself) *and* the risk of key loss. The idea is that *before* creating/importing the master key, you set the policy, including the key ID (or IDs) that can ask for key export. Once the master key gets created, you no longer can alter the policy. The policy should be exported together with the key and override the existing one while importing a key (so that you can't alter -actually it's just really hard, but doing that should invalidate signatures on your master key!- the policy by exporting from a device and importing on another). 6 - like in Yubikey NEO, a physical button to authorize some operations can be useful (certification, signature, NFC PIN-less auth) That would be a pretty useful thing, but require you to trust the card reader. This, however, would really make sense on the Gnuk and I guess you could even do that without changing the spec. Nope. it's possible to have (at least I've seen one: my father does have it!) smartcards with small displays, keyboards (1-2 keys could be enough, but a full 4x3 keypad would be awesome!) and even batteries/solar panels! The form factor is not the real problem. The problem is that it's quite a close and secretive market, heavily relying on security by obscurity (when I asked Yubikey how to access the user presence key from a Java appled, they answered I'd have had to contact NXP and sign an NDA! So no need to trust the card reader :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 that you can't alter -actually it's just really hard, but doing that should invalidate signatures on your master key!- the policy by exporting from a device and importing on another). There in lies the problem. It's really hard - it's doable. Yes, by someone who controls the trusted export key. On the other hand, current method to generate on a secure system and move to card makes it easy to lose control of the key. What is the use case that absolutely needs exportable master keys? Safe key recovery in case sc gets damaged. With the current system you have to always generate new keys on the secure system and store the backup in a safe place that is *not* a smartcard. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 would probably have to add a compile-time option or maintain a fork. Then maybe, a simple (disabled) SIM card from an old phone contract (I usually have about a dozen around) could be better suited for the job, since there's no on-card crypto involved. Just store the secret in an SMS, with the sender set to the ID of the protected storage :) Ok, end of OT. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 the prompting is a false sense of security). Who told, not so long ago, that if the attacker have control of the machine you're using you've already lost? The machine from where one is originating the ssh connection have to be quite trusted. Else you need a smartcard with out-of-band authorization for every operation. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 the EEPROM and reads encrypted key material, a low s2k count means he can recover plain key material quite faster than with more iterations. Luckily it's configurable. :) Power of open source! BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 am having a look at implementing it. But I received the programmer too late and now I have a more demanding (and really high priority!) project: my son! :) But I'll try to implement it, even if really slowly. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 what that should add to the security... IOW, if the private key have been generated by a third party to have a certain fingerprint, what's the purpose of adding that fingerprint to the signature? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. I read this quite differently. I read it as that 'r' is not included in the signature, that is, what is signed is still just the hash. It seems profoundly silly to not include it in the signed data, for the reasons you mention. Can you give a quote that actually says 'r' is not included in the signed data? When it says that 'r' have to be sent separately. It's 'included' only indirectly in the hash calculation. At a first glance, it would be safer to have r *inside* the signature. Oh, I agree, I already thought that might close any 'r'-swapping security issues, if there would be any; just like you can include the hash algorithm in the signature to prevent swapping it out for a weaker one. But when swapping 'r''s does not actually create any security issues, it just makes things needlessly complicated. I don't understand you. I said that if you have a short message (less than hash len) it's trivial for an attacker to fix a new M' and calculate a new r' value that satisfies r xor M == r' xor M' . It gets harder with longer messages. To use your smartcard example: the smartcard only accepts a specifically formatted message. If you change that message to now include a new value, you would need a new smartcard. Furthermore, the size of 'r' might pose a problem; it's a significant addition to the data structure that is signed. Depends on how strict the checking is. E.g., if the smartcard only uses the raw buffer you pass it (just adding the needed padding before signing) and is able to accept SHA-512, then you could just use SHA-256 and append 256bits of 'r' w/o having to change the smartcard: it sees 512bits and pads 'em like in SHA-512. That's one of the reasons I like the cards that do the last hash round more. Maybe it's just a performance issue? I suppose also simplicity, verifiability, implementation cost... Probably. The rest seems unrelated to randomized hashing except for what I already mentioned: that including 'r' in the signature would mean you can't use an existing OpenPGP card. But I'll answer anyway. I didn't study OpenPGP card protocol enough. while the op is anyway 'RSA encrypt', the padding should be different if you're signing an hash or exchanging a session key. Failing to let the card do the padding could lead to exposure of the private key, IIRC. I think you mean RSA decrypt, for signing you use the RSA decrypt primitive, just as you use to decrypt a session key. Yup. Terminology slip. The RSA op involving the private key, so sign/decrypt. But this is all already done in the OpenPGP card. It checks the data to be signed conforms to PKCS#1; it is optional to check the DigestInfo, but the rest of the data structure already differentiates it from an encrypted session key. It will only let you sign with the Signing and Authentication keys. Likewise, it checks that the output of decrypting with the Decryption key conforms to the PKCS#1 format, so you can't fool it into a signing operation either. Ok. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 research has been done. That doesn't mean it's a fact that there are no significant attack vectors, but it does give the scheme credibility. Well, I'm no expert, but it gives me the feeling of being potentially dangerous, since once the attacker have your signature for a document s=E(Prk, H(RMX(M,r))) , r (note that r is not signed, as the rhash scheme suggests and the paper confirms!) he *might* be able to calculate r' so that RMX(M',r') == RMX(M,r) then 'recycle' your signature for M'. Remember that RMX is proposed to be a simple block-xor! For very short (less than a single hash block) messages it's trivial, if I'm not badly mislead by the graphic description in the site: RMX(0, 1) == RMX(1, 0) Citing from the paper: RMX can be used with any hash-then-sign scheme by replacing the digest H(m) in the original signature scheme with H(RM X(r, m)). In this case, the salt r is generated for each signature by the signer and transmitted to the verifier together with the message and signature[1] and the footnote [1] is In contrast to a previous proposal by the same authors, the salt r does not need to be included under the signature. . I haven't yet found out why he changed his mind. At a first glance, it would be safer to have r *inside* the signature. This way the attacker couldn't change it. But maybe that exposes other problems. To me it appears that *any* encryption of the message before hashing would lead to analogue security properties. Say you generate 'r' and use it as 'session key' to block-encrypt M then sign the hash of encrypted M (IMVHO it's better if the signature includes r too). Maybe it's just a performance issue? BTW, some smartcards want you to feed 'em the hash state and the last block of data so they can calculate the last hashing step by themselves. And IMVHO it's better if the padding is generated by the card, depending on the operation being performed: while the op is anyway 'RSA encrypt', the padding should be different if you're signing an hash or exchanging a session key. Failing to let the card do the padding could lead to exposure of the private key, IIRC. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 mitigate at least the spam? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 each signature by the /signing/ party. So the attacker loses control over the input to the hashing algorithm, and they no longer can use collision attacks because they don't know the exact input to the hashing algorithm. Sorry, I've been too concise. I see two problems with randomizing crypto: 1) who guarantees that the 'r' seen by the receiving party is the same generated by the signer? Since it's usually trivially combined with source text, I feel it's a huge attack vector 2) it could be a side-channel for leakage (say a smartcard under some control by some TLA that encrypts the used secret key and some really random bytes and uses the result as 'r') BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 should disclose the whole list of subscribed addresses (that's really valuable metadata -- not to say a dream for spammers!) 2) you make mail headers and message size explode Not good, IMVHO... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 - the authors have never ever tried to do what they suggest others to do. If they had done so then they would have known just how crappy their supposed expertise was. I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a useless pile of crap also. Surely you're doing it wrong, overlooking some passage. So don't blame others for something *you* are doing wrong. I am faced with two options: (1) Create yet another set of keys (2) Give up using gnupg after some 20 years (3) Do it the right way as everyone else and admit you were doing something wrong. I think I will unsubscribe from this list and give up on gnupg as a pile of crap. And that will be better for the whole community. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 a new set of keys. I have done this 4 times. If all four times you did the same wrong thing, then it's obvious that you got the same wrong result. Just to prove it's your error, I copied my .gnupg from one system (str957-142) to another (str957-004), with the most basic method I ould think of. I'm not an expert (probably I transferred more than what was needed!), but as you can see I succeeded at the first try! diego@str957-142:~$ gpg --list-secret-keys /home/diego/.gnupg/secring.gpg sec 2048R/F9B9D307 2014-11-14 uid Diego t...@example.com ssb 2048R/3A4AD1C0 2014-11-14 diego@str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed .gnupg diego@str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz È necessaria una passphrase per sbloccare la chiave segreta dell'utente: Diego t...@example.com 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 diego@str957-142:~$ ls GnuPG-backup.tar.gz* GnuPG-backup.tar.gz GnuPG-backup.tar.gz.asc diego@str957-142:~$ scp GnuPG-backup.tar.gz diego@str957-004:/home/diego Then on the other PC: diego@str957-004:~$ tar xvfz GnuPG-backup.tar.gz .gnupg/ .gnupg/gpg-agent-info .gnupg/pubring.kbx .gnupg/gpg.conf .gnupg/private-keys-v1.d/ .gnupg/reader_0.status .gnupg/pubring.gpg~ .gnupg/secring.gpg .gnupg/scdaemon.conf .gnupg/gpa.conf .gnupg/trustdb.gpg .gnupg/pubring.gpg diego@str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz È necessaria una passphrase per sbloccare la chiave segreta dell'utente: Diego t...@example.com 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 diego@str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID chiave F9B9D307 gpg: Firma valida da Diego t...@example.com I notice that no one on this list - for all the talk of oh I've done it can offer no practical information has to HOW. No one. No one. No one knows how to do this simple task. In all my 20 years I have never found out how. Perhaps things are different under a Windows O/S but on Linux there is NO SOLUTION. Done just now in Ubuntu. So there's an error on your side. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 referred too. No amount of copying no amount of backups no amount of anything will change that fact. Then do what we've already done to try to help you: open a terminal on the source machine, type the commands and cutpaste to the list. Unless you do that, showing *exactly* what you've done, I doubt anybody can help you: all our crystal balls are broken... And I'm *not* going to try to help you again unless I see that cutpaste. Wasted time. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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've had no time to develop it further :( Hope I'll be able to return on it soon... Unless another (paid) project steps in... Suppose after some time I decide an old key has seen it's useful lifetime. I'd like to create a new encryption-capable key. However, I definitely need to keep the old key, or I won't be able to see anything encrypted to me in the past. Currently you have to generate your encryption key on the PC and copy it to the card. So you have a copy to reuse. Or just use multiple cards BEG The current OpenPGP smart card restricts me to a single key for encryption, a single key for signatures, and a single key for authentication. If it were possible to tell the card, on uploading the key, what that key's usage will be, I would be able to have a separate smartcard that decrypted the 3 OpenPGP subkeys I used for encryption previously. This instead of being forced to use 3 separate smartcards. I get the impression this is a relatively small change to the firmware of the smartcard, but a larger change to the software running on the PC. On a 144K javacard, IIRC, I've been able to store 13 RSA-2048 encryption keys. Plus master, signature and two auth keys (one reserved for contactless auth). BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 can host the applet and many keys. The trick is that it accepts the standard OpenPGPCard commands, plus some extended commands to handle extra keys (like selecting current enc/dec key, or safely export keys only towards user-certified devices). This way you only need the standard GnuPG plus an helper program (can be a simple script using opensc) if/when you need the extra functions. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 are risks associated with NFC, and I haven't done any real looking at the security model of NFC -- it's very likely there are big things I'm overlooking. But the ability to store 400 bytes, to access it quickly and easily, and all in a tag that costs less than a dollar and can be read with almost any modern smartphone, is kind of cool. Or, as suggested, use the whole phone as a smart tag, placing it in device mode with a suitable applet that sends your whole key w/o the limit of 400 bytes. Too bad it's quite easy to reprogram the tags, IIUC, so the applet method should be preferred. IMOP, such an applet should be able to use bluetooth, too, to allow sending the key to non-nfc enabled phones (but maybe a simple file manager could be enough for this? Maybe some file managers already allow to send via NFC too)... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 *never* apply RSA directly. Padding is important and *must* be checked during process. Decryption and signature are the same RSA op, but use a different padding so you can tell which op got applied. 2) If a signature key has expired then you may delete the private part. You should usually never throw away a decryption key, though, as it can happen that you have to decrypt data long after the public part has expired. And that poses a big problem for everyone that would like to use a smartcard for decryption... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 / Debian You could use gnuk (includes 'quite' secure openpgp card), or only its TRNG NeUg: http://www.fsij.org/gnuk/neug_version1_0 Readily available on seeedstudio (pre-programmed with gnuk, if you only want NeUg you need to flash it yourself). Hope it helps. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 signatures (and few people do) then a signature on a key does not encourage a 3rd party to trust signatures made by that key. Ah, OK. Now it makes more sense. Tks for the clarification. Even if a key is recognised as authenticated/validated/certified for association with a particular email address, the signatures made by that key will not be trusted by anyone who has not made an active decision to make a particular key a trusted introducer. IIUC, *unless* I tsig it. But if I use tsig I'm doing both an identity signature and a trust signature. I see no way I can publicly say I don't really know real-world identity of this subject, but I trust him as an introducer (yep, might sound strange [*], but often a pseudonym is more meaningful than RL name, but pseudonyms aren't good in WoT): if I tsig his key, I'm cerifying his pseudonym -- that I shouldn't do since it's not on any document. [*] well, not too strange in many cases, when it's healtier that a pseudonym is *not* easily correlated to a RL identity. In fact, this is a reason (though one of many) why the web of trust has never quite lived up to its promise. No UI that I am aware of sets even marginal trust by default on newly imported keys. Most users (I suspect) will only ever end up trusting keys that they themselves have signed. That is the default position. Understandable/safer, but harder to bootstrap :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 practice is the same as asking you to sign blank sheets of paper so they can later write on them what they like. IMVHO it's an *illegal* practice, and actually I vaguely remember news about a case where a female worker had to sign a blank sheet, that was later used for her resignation when she asked for maternity leave. IIRC she won the cause. Signing cards, at least here in Italy, are bound to a person. If multiple persons can sign the same kind of document (or if a vice is needed), then there are more cards, each controlled by a different person. That's why it's called qualified signature and it's (legally) stronger than a plain one. As already pointed out it could be different for encryption-only keys, that could be escrowed under some circumstances. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 machines, figure digital signatures! Deception? In politics? Surely you jest. That could /never/ happen... ROFLASTC :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 work? Making WoT calculator avoid looking for keys signed by that user if reached throught my certification. It sounds like you'd want to ask an OpenPGP to introduce an additional concept on top of the notions of validity and ownertrust (which are already confusing): They work: I'm *really* confused. :) some sort of meta-ownertrust: instead of ownertrust's question of: how much am i willing to rely on NdK's identity assertions, 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. meta-onwertrust would ask how much am i willing to believe NdK's assessments of certification practice quality? Who is going to understand this question? What kind of UI would you suggest for it? No, it's not what I meant. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 is *really* the one given in this UID, but I absolutely don't trust his identity validations... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 transactions to various online stores :) ). I'd have been interested in developing for Yubikey, too, but that required an NDA with NXP for their SDK, or I couldn't access the button (and access to the button was the only reason I was interested in Yubikey in the first place!). BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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't change anything in the equation. Then where would you stop analyzing? If you look at the OS code, there could be a backdoor in the CPU microcode. Or in the chip firmware uploader (is there an HV programming mode available? was it disabled or physically removed from the die?). And these are just the most obvious. The best we can do is trust the manufacturer and read the fine print on the datasheets. It will be more secure than a sw only implementation that runs on a connected PC. ByTE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: MUA automatically signs keys?
Il 31/01/2014 10:24, Steve Jones ha scritto: Well the conventions of use, for example the key signing party protocol, requires photographic id. If I publicly sign a key it has to be in line with how I expect others to interpret it. Policies and notations on signatures go 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 use ndk@mydomain=X notation and that X=0 means just checked the person can access the given mailbox, X=1 means at least 2 other persons have confirmed that the same user used that email address for the last year and so on. Is my understanding right? When I sign a key and use a notation, am I actually signing *all* the identities associated with that key? Or just one? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 hardware. A token is a bundle of a smartcard and a reader, and usually looks like an USB stick. If you have a dedicated (non virtual) server, usually you can ask to have a token plugged in. If you're using a virtual server, then it's harder and there are other possible attacks against your key material, as previously discussed on-list. I might be able to use a software only solution; I've heard something about agents, but don't really understand any details. Can such an agent be used, one that I can start and load the key with passphrase at system startup? I don't know if such an agent exists. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 useful to be able to use the same smartcard for both Android APK signing and OpenPGP signing. IIRC there is an OpenSC driver for OpenPGP cards, that makes 'em accessible throught PKCS#11. https://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg06206.html Seems it's quite old... Maybe if you want to take over developement... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 down or a reset operation. Thus an attacking malware only needs to trick you info decrypt an arbitrary message and is then free to use the smartcard without having the reader ask you again for a PIN. Is it just convenience or enforcing it (e.g. adding a forcedecauth flag) would lead to usability issues (maybe because sometimes decryption is called many times in sequence)? That would be the case for auth key, I think: using it to auth against a web page would ask auth for every sub-request of objects on the page. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 message and I want to stress that sometimes it's best to send a first encrypted then signed (or signed-encrypted- signed) message. I can't come up with a situation where sign, encrypt, sign again w/ *same* key used in the first signature gives more security than first encrypt then sign. So two layers are enough. I (partially) get your point: receiving an encrypted message could mislead an uneducated user... But I doubt someone w/ access to top secret material falls in that category :) BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 keygrip.key. Maybe I'm missing something... What happens if keys are kept on smartcard? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 to carry: just keep the card near the rear of the phone while doing crypto ops. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 expensive of the cited actions (except breaking encrypted keys on file). It requires great skills and devices that aren't exactly cheap (see Anderson's page at http://www.cl.cam.ac.uk/~rja14/ and read some of his papers about reliability of security systems). Hire someone that plants a keylogger in your PC is probably cheaper than 2K$ (maybe it's even free, if he can rob something while at it). You could even find someone who does rubberhose analysis for fun... How much effort is it, compared to breaking into a smartcard, that requires a specialized lab? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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, havina actually a limitless-memory card: you'd simply have to send the encrypted key blob, the password and the PIN. Too bad in all cards I know key objects can only be stored in EEPROM/Flash, that have a quite limited number of writes :( But, as Peter pointed, that wouldn't bring you more security. Checking the applet is difficult. Only few people are skilled to do. Try reading code of an applet. You can learn the basis of SC devel in an afternoon, and that would be enough to understand how a well-written app works. Then throw away what you learnt and ask if some expert already looked at that code :) I am a user of gnupg. I can't be auditor-like type of person for all projects I am using. If you want to be paranoid enough, you need to. That, or pay a lot of money -- and who guarantees you that the staff is not paid by a TLA agency? ]:) And let's say the applet is fine as is. It will be much more difficult to find out if the smartcard really wipes the key as soon someone is trying to dismantle the card to directly read its memory. It is my understanding, that understanding such hardware design is even harder than understanding the applet. And knowing/searching for vulnerabilities in the hardware design is an art in itself. Sure. Look at works by Ross Anderson, just for naming one expert in that field. Maybe you want to hire him. You can do many checks yourself: there are various OpenPGP Java implementations around. Also the hardware design? How much do you want to pay for that level of security? Maybe, you should start reading the applicable certification procedures (what does CC-EAL5 mean exactly?), to see what's already considered and which level of examination each card mask have undergone. Then, if that's not enough, you should contact a manufacturer and take steps to have a custom-made mask examined by your enginering staff, then buy enough cards. Or, simpler, ask the supplier to sign a contract where the considered attacks are detailed. One could do it manually already. First encrypt a message using the smartcard and the encrypt the encrypted message again using a password-protected/encrypted key. And you could tell contacts, my signature is only valid if it is signed by both signing keys. Naive and error-prone. Manually doing so just seems to inconvenient to get it right. Technical challenges should only be implementing that feature but not conceptual limitations? Then you should use the (really heavy) shared RSA signature: to have a valid signature, all N chunks from N parties are needed. Key generation is a collaborative effort, too, so no single party can know the whole secret key. That could be a good idea for a Ph. D thesis (probably a hard one). I fear that current crypto support in JavaCards wouldn't be entirely useable :( BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 here.] - Not capable of breaking gpg's key encryption/password protection. - Not capable of rubber-hose cryptanalysis. - Not capable of installing a miniature camera and/or hardware keylogger. You're saying that he can lockpick your security door but can't break the glass of the window nearby... Just IMVHO... BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 a limited USB stick! Since the smartcard is a really controlled execution environment, we can say it's a trusted environment. I've learned the hard way (by buying the equipment even with external PIN pad), that when keytocard has been used, that only the PIN has to be entered. No password. Unfortunately. Luckily. Smartcards are used to avoid exposing key material to an untrusted environment, like a PC. The smartcard has been bought by me to improve security. Not to substitute one security mechanism with another. I believe gpg's software encryption is more trustworthy than a card I got by snail mail. I haven't heard that any cards have been compromised yet, but how do I know if I really received an original (untampered) card in the first place. You have to trust the supplier. If you ordered 'em in significant quantities, you could ask to have 'em with special keys so that every step can be checked. Or. more easily, you can buy blank java cards from diffetent manufacturers, then compile an upload your carefully checked applet. In my opinion both attempts, password protection and smartcards, on security are worthwhile. When using smartcards I am trusting hardware, a small group of card designers, producers, post office... And when using gpg's software key encryption, I am trusting the software producers and the programmers actually looking at the code. You can do many checks yourself: there are various OpenPGP Java implementations around. The idea was to take my chances. If smartcards work, that's great. The key can be abused when a malware infection happened, but at least the key can not be extracted. On the other hand, if I loose my smartcard and smartcards don't do what they promise (i.e. someone ever comes up with some exploit to extract the key), I fall back to gpg's software key encryption. And how do you think the card could perform crypto ops on encrypted keys? If you lose your card, it could be way easier to revoke the keys on card. And that's why many people keep their master key offline, using cards/tokens just to safely transport their keys. I am ignorant about the technical details. Maybe there is a technical reason why it's not worthwhile to combine these things? Or are smartcards just too limited at this stage of development to support that? No. It's simply impossible to do what you're asking. Unless you replace the secret key with a *masked* version, leaving the unmasking key on the PC, encrypted by PGP. But that would prevent checking on-card various possible attacks, actually weakening the whole system. BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
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 and send it to key servers when they suspect compromise. But should the sub key revocation certificate get into the wrong hands due to compromise, the damage would be limited. Since you still have your secure offline main key, you can revoke subkeys yourself... Or am I missing something? BYtE, Diego. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
