> The thing is, if I create an ECC (ECDSA) secp256k1 primary key with
> Sign, Certify capabilities I can also create a subkey with E
> capability which is also a secp256k1 key. So, they can be used for
> encryption after all, so why can't I just add E capability to the
> primary one.
You're co
On 2017-08-28 at 19:05 -0400, Rob J Hansen wrote:
> > 1. Is it possible, when transporting a message from Alice to Bob,
> > without holding any of their private keys, to do the following checks:
> > - verify the integrity of the message and make sure it is sanitized and
> > Bob can decrypt it with
Robert J. Hansen wrote:
>> It works with a RSA key, but not with ECC. Try with secp256k1 and you'll
>> only get Sign and Certify capabilities. At least this is what happens on
>> my side.
>
> I apologize for sounding like I'm condescending here: it's not my
> intent. However, there are very impor
> It works with a RSA key, but not with ECC. Try with secp256k1 and you'll
> only get Sign and Certify capabilities. At least this is what happens on
> my side.
I apologize for sounding like I'm condescending here: it's not my
intent. However, there are very important things you are apparently no
Robert J. Hansen wrote:
>> Tried both of them, not working. They only produce a single primary key
>> (8 RSA or 11 ECC) with S,C capabilities (without E).
>
> *shrugs* Do better. Seriously, if you literally choose option 8 and
> just go through the defaults you'll get a single primary key with an
> Tried both of them, not working. They only produce a single primary key
> (8 RSA or 11 ECC) with S,C capabilities (without E).
*shrugs* Do better. Seriously, if you literally choose option 8 and
just go through the defaults you'll get a single primary key with an
encrypt capability.
=
quo
Robert J. Hansen wrote:
2. Is it possible to have just one key (the primary one, no subkey) with
E flag also (S,C,E) -- I know this is not recommended but this is a
particular use case and the risks are acknowledged. I guess gnupg will
not allow you to do this by default, but i
Robert J. Hansen wrote:
>> Well, you can go one step further. Unless the sender is throwing the
>> key ids, you can look to see which keyids are given as hints in the
>> outermost layer, to see which people are expected to be able to decrypt
>> it.
>
> Sure, but this is a heuristic, not a formal
> If I have the public key of the recipient, I should be able to tell that
> a message was encrypted for that public key, except I am missing the
> private key to decrypt it. If I can check the message format I should be
> able to check this as well. How would I do this with gnupg?
--list-packets
> Well, you can go one step further. Unless the sender is throwing the
> key ids, you can look to see which keyids are given as hints in the
> outermost layer, to see which people are expected to be able to decrypt
> it.
Sure, but this is a heuristic, not a formal verification. A useful
heuristi
Thanks for the reply. See inline,
Robert J. Hansen wrote:
>> 1. Is it possible, when transporting a message from Alice to Bob,
>> without holding any of their private keys, to do the following checks:
>> - verify the integrity of the message and make sure it is sanitized and
>> Bob can decrypt it
> 1. Is it possible, when transporting a message from Alice to Bob,
> without holding any of their private keys, to do the following checks:
> - verify the integrity of the message and make sure it is sanitized and
> Bob can decrypt it with his private key;
No. You can check the format of the mes
Hi list,
Please help me with some information and hints.
1. Is it possible, when transporting a message from Alice to Bob,
without holding any of their private keys, to do the following checks:
- verify the integrity of the message and make sure it is sanitized and
Bob can decrypt it with his pri
On 2017-08-28 10:04:01, Werner Koch wrote:
> On Sat, 26 Aug 2017 00:35, l...@anarc.at said:
>
>> I'm in the process of reviewing performance of various security tokens
>> (the Yubikeys, the FST-01, Nitrokey), and I am getting somewhat
>
> Thanks for the numbers. However, the numbers Nitrokey are a
Hello Werner,
On 8/23/17 11:59 PM, Werner Koch wrote:
> On Sun, 13 Aug 2017 08:17, dani...@grinta.net said:
>
>> Digging a bit more, it seems that the functionality got dropped because
>> with GnuPG 2.x all key manipulations go through gpg-agent and it does
>> not (yet?) support password reset on
Hello!
Arguing that you don't care about the right to privacy
because you have nothing to hide is no different from
saying you don't care about free speech because you have
nothing to say. - Edward Snowden
The G
> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Mon, 28 Aug 2017 12:00, pe...@digitalbrains.com said:
>
> > The gpg process communicates its TTY to the agent so the pinentry
> knows
> > where to pop up. This is a feature, not a bug. But when you
> deliberately
> > want to pop it up elsewhere...
>
On 28/08/17 12:50, Werner Koch wrote:
> If you don't want that feature the --keep-tty and --keep-display options
> for gpg-agent may be useful:
Those options had slipped my mind... Thanks!
Werner, do you know why the bash shell that was running on the X
terminal where pinentry-curses popped up re
On Mon, 28 Aug 2017 12:00, pe...@digitalbrains.com said:
> The gpg process communicates its TTY to the agent so the pinentry knows
> where to pop up. This is a feature, not a bug. But when you deliberately
> want to pop it up elsewhere...
If you don't want that feature the --keep-tty and --keep-d
Hi,
Is it possible to instruct a smart card to not cache its PIN or have
GnuPG forcibly clear the PIN cache?
My understanding is that the PIN is cached internally [1] unless if you
enable "forcesig" (which only applies to signing operations). If this
caching by the smart card cannot be turned off
On 28/08/17 09:57, Fiedler Roman wrote:
> But it seems, that the gpg-decryption process attempts to trigger the
> pinentry, not the agent and so the access to the correct controlling TTY
> fails.
The gpg process communicates its TTY to the agent so the pinentry knows
where to pop up. This is a f
On Sat, 26 Aug 2017 00:35, l...@anarc.at said:
> I'm in the process of reviewing performance of various security tokens
> (the Yubikeys, the FST-01, Nitrokey), and I am getting somewhat
Thanks for the numbers. However, the numbers Nitrokey are are missing.
Shall I send you a "standard" Zeitcontr
> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
>
> On 25/08/17 18:40, Fiedler Roman wrote:
> > Idea:
> > 1) Extract all GPG preambles of files to be decrypted to a single file
> > (working)
> > 2) Batch decrypt all preambles from the input file on the trusted
> equipment
> > (not working in
23 matches
Mail list logo