Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> I thought you could also tell how many keys it was encrypted to, from
> the output of gpg --list-packets.

Nope.  You can tell how many subkeys it was encrypted for, but not how
many distinct certificates those represent.  If one recipient has 10
subkeys and you encrypt to all 10, there will be 10 packets awaiting
you... but there's no way to determine these all correspond to one
certificate.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Tuesday 29 August 2017 at 2:24:18 PM, in
, Shawn K.
Quinn wrote:-


> No, that's the whole point of throw-keyids. All
> you're supposed to be
> able to tell when using that option, is that none of
> your keys will
> decrypt the message, so it's not for you.

I thought you could also tell how many keys it was encrypted to, from
the output of gpg --list-packets.




- --
Best regards

MFPA  

I'll tell you what's the matter!  This parrot is dead!
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWaqrDF8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+i9TAP9wHrrVApzeItibVUOzPGo6dF0Q1xWUdzhl2Gf+Fut6XgEA2DscZI9yyPwi
uzNpkEWlyk3Wp863KyXKvSUK3EZR5g2JApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWaqrDF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/wZSD/0UrzNDD8KQTwFU1P1YKtQlTM0i
1egLTxx3a4eukon0Cl3H3pniSQNXgtxP8A7BzkNKvWiKT661++WcqB5sQE/Fj9lX
O6zMGLfuKypdTXPC69h7i9rRS4D/yawgAtEIr5Fw2Cj4uUEbBBymQlLlTXUGdmyz
wDTNWWX1V/bTPl4yjZOnYrkD2sd1D2bOTqF9AnInrjARr1lJHZDztEtgKk9y2P5X
JjyI6IQORG6CEoKOraMP3FgK4p5+uFzcpMx7wj7QqgDb80oaRoGLn9eccZKl7OjP
ZHGronabhiVQCAvG1YoeAzusXszmhRxbUOXDsvmQ1/vTyU7/sz+exRaNmSCPN1r7
64M8uuxdYAbkSa1fQ+JbXjbb6hfpwrefASFRYy3wWcUfFecNg6suKCypSFJ6QrVj
q/tp3O6OB6mDoPFZZKXn+FUy0S7G7PNGp8quIUvc7vNRomPXdvz8zq18nO4HXKsX
Pkb5swwBfJkQeXhYGv+wgYCOPDR9+TeK2ZO4csmOUrdqkxsmqgskmjUvrJBiJFuv
BDX+uPkr60iwpzECadxMy9n+iD4jYvsrJxJu8PCJVp6g1m2iWfBmZGM0kLGEhuJF
uCZf4w6w18WWRgatfuwzRsRvCSVFLWx864fsLugVEu/krJ0upieKYZoP/1rGMh8i
H9qMsAgkv9cvWH0T6g==
=mygj
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Mario Castelán Castro]

On 31/08/17 17:49, s7r wrote:
>> You can use hash(private_key_1) to seed a cryptographically secure
>> pseudo-random number generator (E.g.: AES in CTR mode with the seed as
>> the key), and then use that random stream to generate (private_key_2,
>> pubic_key_2.
>>
>> This is a method applicable in general. The algorithms of private_key_1
>> and private_key_2 need not be the same, nor do they need to be defied
>> over the same curve.
>>
>> The only problem is that I do not know of a program to do they key
>> generation from a user-provided seed.
> 
> This will do for my use case.
> 
>> Please stop talking about "secp256k1 keys".  You do not have secp256k1
>> keys.  You have ExDSA or ECDH keys which are not interchangeable with
>> each other.
> 
> I think I asked in a wrong way. I do not necessarily need for both the
> primary key and the secondary key (key with Encryption capability) to be
> the same secp256k1 curve / ExDSA key / ECDH key, etc. -- all I need is
> for them to be reproductible at any time, any where, based on some seed,
> or sha256 hash of a user-generated password, etc. It's irrelevant if
> they are totally different keys that work in different ways, the only
> feature needed is to be able to reproduce them from scratch any time,
> and be able to decrypt the data.

You can use the same scheme that I described. The only difference is
that you use a hash (say, SHA-256) of the seed provided by the user as
the seed of the CSPRNG, instead of the hash of a private key (as I
originally described)

The only thing that is still missing is software that implements
deterministic generation of DSA and DH keys over secp256k1 given a seed.
You can either find one already written, write it yourself, or pay
somebody to write it for you (possibly as a modification of GNU PG).

Note that you will need to know the seed *and* the method of generation
so that you can re-generate the key in the future if it becomes
necessary. You can store the program used for the key generation in a
place where it will remain available in the future, for example, in the
same place where you store your backups, or print the source code. The
generation program needs not be kept secret. Only the seed needs to be
kept secret.

> Mario, check this out:
> 
> https://github.com/Jaxx-io/openpgpjs-secp256k1/blob/master/README_secp256k1.md
> 
> Generate keypair from bitcoin key:
> var openpgp = require('openpgp');
> var bs58check = require('bs58check');
> 
> [...]

I can not comment on this library. I have never used it nor do I plan to
use it.

-- 
Do not eat animals; respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

Hello Mario, Robert,

Replying to both inline.

Mario Castelán Castro wrote:
> On 29/08/17 02:09, s7r wrote:
>> I understand that the first one is ECDSA and the second is ECDH, but
>> can't I use the same secp256k1 key (if I import it) but in different two
>> representations (ECDSA representation for Sign and Certify and ECDH for
>> Encrypt)?
> 
>> The subkey might have a different fingerprint because it's a
>> different representation of course but this is not the concern, the
>> concern is for both to be computed from the same imported private key.
> 
> You can use hash(private_key_1) to seed a cryptographically secure
> pseudo-random number generator (E.g.: AES in CTR mode with the seed as
> the key), and then use that random stream to generate (private_key_2,
> pubic_key_2.
> 
> This is a method applicable in general. The algorithms of private_key_1
> and private_key_2 need not be the same, nor do they need to be defied
> over the same curve.
> 
> The only problem is that I do not know of a program to do they key
> generation from a user-provided seed.
> 

This will do for my use case.

> Please stop talking about "secp256k1 keys".  You do not have secp256k1
> keys.  You have ExDSA or ECDH keys which are not interchangeable with
> each other.

I think I asked in a wrong way. I do not necessarily need for both the
primary key and the secondary key (key with Encryption capability) to be
the same secp256k1 curve / ExDSA key / ECDH key, etc. -- all I need is
for them to be reproductible at any time, any where, based on some seed,
or sha256 hash of a user-generated password, etc. It's irrelevant if
they are totally different keys that work in different ways, the only
feature needed is to be able to reproduce them from scratch any time,
and be able to decrypt the data.

Mario, check this out:

https://github.com/Jaxx-io/openpgpjs-secp256k1/blob/master/README_secp256k1.md

Generate keypair from bitcoin key:
var openpgp = require('openpgp');
var bs58check = require('bs58check');

var wif = 'KyiAchQgMKuXQu89j6k6UVZQj7brK6cM79JfmDvkNXPVW24L1thi';
var buff = bs58check.decode(wif);
var privateKey = buff.slice(1, -1);
privateKey = openpgp.util.bin2str(privateKey);

var options = {
curve: 'secp256k1',
userId: 'Hamlet ',
passphrase: 'To be, or not to be: that is the question',
material: {
  key: privateKey,
  subkey: privateKey
}
};

openpgp.generateKeyPair(options).then(function(keypair) {
// success
var privkey = keypair.privateKeyArmored;
var pubkey = keypair.publicKeyArmored;
}).catch(function(error) {
// failure
});

Although I am not sure if how this code solves the primary / secondary
subkey problem, I doubt it can create a primary key with Encryption
capability because ECDSA doesn't work like this, as Robert clearly
explained (thanks again for this).



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

Hi everyone,

thanks for everyone's very helpful feedback. See inline.

Shawn K. Quinn wrote:
> On 08/29/2017 02:14 AM, s7r wrote:
>> Hi Phil,
>> Thanks - this is indeed _very_ useful for my use case. I don't think the
>> second part is a problem since I can particularly request to not set the
>> `throw-keyids` option, but let's say metadata becomes a problem at a
>> given point and we decide to use this option, can I tell which recipient
>> 'should' be able to decrypt a message based only on the encrypted
>> message format if the `throw-keyids` option was used?
> 
> No, that's the whole point of throw-keyids. All you're supposed to be
> able to tell when using that option, is that none of your keys will
> decrypt the message, so it's not for you.
> 
> 

Ok, understood, last thing: at least can I learn just by looking at the
cipher text that `throw-keyids` option was used and choose not to
further transmit that message and at least warn the sender that he
should double check and confirm one more time for safety reasons?

There is a single threat model: I am trying hard to prevent accidental
usage in an app where a message encrypted for a different recipient ends
up to the wrong person, no matter the recipient that actually gets the
ciphertext by mistake has absolutely no real use with it because he
won't be able to decrypt it -- the downside and loss is at sender side
for thinking the message was sent to someone else and further action is
expected.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Mario Castelán Castro]

On 29/08/17 02:09, s7r wrote:
> I understand that the first one is ECDSA and the second is ECDH, but
> can't I use the same secp256k1 key (if I import it) but in different two
> representations (ECDSA representation for Sign and Certify and ECDH for
> Encrypt)?

> The subkey might have a different fingerprint because it's a
> different representation of course but this is not the concern, the
> concern is for both to be computed from the same imported private key.

You can use hash(private_key_1) to seed a cryptographically secure
pseudo-random number generator (E.g.: AES in CTR mode with the seed as
the key), and then use that random stream to generate (private_key_2,
pubic_key_2.

This is a method applicable in general. The algorithms of private_key_1
and private_key_2 need not be the same, nor do they need to be defied
over the same curve.

The only problem is that I do not know of a program to do they key
generation from a user-provided seed.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Mario Castelán Castro]

On 28/08/17 22:27, Robert J. Hansen wrote:
> secp256k1 is a certain field of numbers in which elliptical curve
> operations may be defined.  It is not an algorithm.  You do not have a
> secp256k1 key.  You have an ECDSA key which operates in the curve
> defined by secp256k1.

Although elliptic curves are defined *over* a field, they are not
themselves a field (or at least, I am not aware of any way to define a
field over them).

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> Although elliptic curves are defined *over* a field, they are not
> themselves a field

Thank you, yes.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Peter Lebbing]

On 29/08/17 15:24, Shawn K. Quinn wrote:
> All you're supposed to be
> able to tell when using that option, is that none of your keys will
> decrypt the message

... which you can only do by trying each private key on the encrypted
session key packet and seeing whether the resulting plaintext (which
contains the session key) makes sense.

There isn't any information that can be learned without actually trying
out a particular private key. At least for RSA, it's the only algorithm
I know enough by heart about to make this claim with confidence.

You don't need to decrypt the data though, just the encrypted session
key, to see if it's the correct private key.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Shawn K. Quinn]

On 08/29/2017 02:14 AM, s7r wrote:
> Hi Phil,
> Thanks - this is indeed _very_ useful for my use case. I don't think the
> second part is a problem since I can particularly request to not set the
> `throw-keyids` option, but let's say metadata becomes a problem at a
> given point and we decide to use this option, can I tell which recipient
> 'should' be able to decrypt a message based only on the encrypted
> message format if the `throw-keyids` option was used?

No, that's the whole point of throw-keyids. All you're supposed to be
able to tell when using that option, is that none of your keys will
decrypt the message, so it's not for you.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> I understand that the first one is ECDSA and the second is ECDH, but
> can't I use the same secp256k1 key (if I import it) but in
> different two representations (ECDSA representation for Sign and
> Certify and ECDH for Encrypt)?

Please re-read my message:

>> secp256k1 is a certain field of numbers in which elliptical curve 
>> operations may be defined.  It is not an algorithm.  You do not 
>> have a secp256k1 key.  You have an ECDSA key which operates in the 
>> curve defined by secp256k1.

What you want to do is like saying, "RSA and DSA each use prime numbers,
so can't I use the same prime numbers for each?"  And the answer is no,
not really, because RSA and DSA are different algorithms that work in
different ways.  Even if you were to use the same prime numbers for
both, your RSA keypair would be distinctly different from your DSA
keypair.  They are not interchangeable.

Please stop talking about "secp256k1 keys".  You do not have secp256k1
keys.  You have ExDSA or ECDH keys which are not interchangeable with
each other.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> given point and we decide to use this option, can I tell which recipient
> 'should' be able to decrypt a message based only on the encrypted
> message format if the `throw-keyids` option was used?

No.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

Robert J. Hansen wrote:
>> 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 confusing the field of numbers in which an algorithm operates
> with the algorithm itself.  It's like confusing a sports car with a tour
> bus, thinking that since they run on the same roads they're interchangeable.
> 
> secp256k1 is a certain field of numbers in which elliptical curve
> operations may be defined.  It is not an algorithm.  You do not have a
> secp256k1 key.  You have an ECDSA key which operates in the curve
> defined by secp256k1.
> 
> When you "create a subkey with E capability", you're creating an ECDH
> subkey operating in secp256k1.  It's a completely different algorithm
> that happens to operate in the same numerical space.  Different cars,
> different capabilities, same roads; different keys, different
> capabilities, same curve.
> 
> ECDSA/EdDSA cannot encrypt.  ECDH cannot sign or certify.
> 
> Your primary key must be able to make certifications.  So that means if
> you want to use ECC, your primary key must be ECDSA/EdDSA, and you will
> never be able to make it into an encryption-capable primary key.

Thanks for this. Ok, now it's clear why the primary key cannot Encrypt.
Here is a key I have just generated:

sec  secp256k1/BF131CA5E1642BE9
 created: 2017-08-29  expires: never   usage: SC
 trust: ultimate  validity: ultimate
ssb  secp256k1/26882EB702DD7D4B
 created: 2017-08-29  expires: never   usage: E
[ultimate] (1). Delete Me 


I understand that the first one is ECDSA and the second is ECDH, but
can't I use the same secp256k1 key (if I import it) but in different two
representations (ECDSA representation for Sign and Certify and ECDH for
Encrypt)? The subkey might have a different fingerprint because it's a
different representation of course but this is not the concern, the
concern is for both to be computed from the same imported private key.

Thanks.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

Phil Pennock wrote:
> 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 his private key;
>>
>> No.  You can check the format of the message and ensure it's not
>> mangled, but that's about it.  A loose proof of this follows:
> 
> 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.
> 
> In `gpg --list-packets` output, that will be the `:pubkey enc packet:`
> items.
> 
> GNUPGHOME=/nonexistent gpg --batch --list-packets < "${INPUT_FN:?}"
> 
> It won't confirm that Bob _can_ decrypt it, since that goes into a lot
> of assumptions about competence, not lost keys, possession of devices,
> whatever.  But in normal use, it'll tell you if Bob should be able to
> decrypt it.
> 
> Privacy-sensitive environments concerned about metadata analysis will
> set the `throw-keyids` option in their config and that would prevent
> this.
> 
> -Phil
> 

Hi Phil,
Thanks - this is indeed _very_ useful for my use case. I don't think the
second part is a problem since I can particularly request to not set the
`throw-keyids` option, but let's say metadata becomes a problem at a
given point and we decide to use this option, can I tell which recipient
'should' be able to decrypt a message based only on the encrypted
message format if the `throw-keyids` option was used?



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> 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 confusing the field of numbers in which an algorithm operates
with the algorithm itself.  It's like confusing a sports car with a tour
bus, thinking that since they run on the same roads they're interchangeable.

secp256k1 is a certain field of numbers in which elliptical curve
operations may be defined.  It is not an algorithm.  You do not have a
secp256k1 key.  You have an ECDSA key which operates in the curve
defined by secp256k1.

When you "create a subkey with E capability", you're creating an ECDH
subkey operating in secp256k1.  It's a completely different algorithm
that happens to operate in the same numerical space.  Different cars,
different capabilities, same roads; different keys, different
capabilities, same curve.

ECDSA/EdDSA cannot encrypt.  ECDH cannot sign or certify.

Your primary key must be able to make certifications.  So that means if
you want to use ECC, your primary key must be ECDSA/EdDSA, and you will
never be able to make it into an encryption-capable primary key.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Phil Pennock]

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 his private key;
> 
> No.  You can check the format of the message and ensure it's not
> mangled, but that's about it.  A loose proof of this follows:

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.

In `gpg --list-packets` output, that will be the `:pubkey enc packet:`
items.

GNUPGHOME=/nonexistent gpg --batch --list-packets < "${INPUT_FN:?}"

It won't confirm that Bob _can_ decrypt it, since that goes into a lot
of assumptions about competence, not lost keys, possession of devices,
whatever.  But in normal use, it'll tell you if Bob should be able to
decrypt it.

Privacy-sensitive environments concerned about metadata analysis will
set the `throw-keyids` option in their config and that would prevent
this.

-Phil

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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 important things you are apparently not
> quite understanding, so I'm going to be excruciatingly clear.
> 
> A primary key must have the Certify capability -- it's used to certify
> the subkeys, after all.
> 
> This means algorithms which can only encrypt cannot serve as a primary key.
> 
> ECC algorithms come in two varieties: ones that can sign (EdDSA, ECDSA)
> and ones that can encrypt (the rest).
> 
> So if you insist on using ECC, you must use EdDSA or ECDSA as the
> primary key.
> 
> Which means your primary key cannot encrypt.
> 
> RSA does not have this limitation.  RSA can be used for signing and
> encrypting.
> 
> This is why my example used RSA.
> 
> Use RSA.

It is not a problem at all. Thanks for the feedback and your time,
really appreciate it.

Unfortunately, I do need secp256k1 as the encryption key, this is the
reason I am asking if it can be done or not, if I could use RSA I would
not even ask, I am using RSA for so many years.

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



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> 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 not
quite understanding, so I'm going to be excruciatingly clear.

A primary key must have the Certify capability -- it's used to certify
the subkeys, after all.

This means algorithms which can only encrypt cannot serve as a primary key.

ECC algorithms come in two varieties: ones that can sign (EdDSA, ECDSA)
and ones that can encrypt (the rest).

So if you insist on using ECC, you must use EdDSA or ECDSA as the
primary key.

Which means your primary key cannot encrypt.

RSA does not have this limitation.  RSA can be used for signing and
encrypting.

This is why my example used RSA.

Use RSA.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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
> encrypt capability.
> 

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.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

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

=

quorra:~ rjh$ gpg --expert --full-generate-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
 0 = key does not expire
= key expires in n days
  w = key expires in n weeks
  m = key expires in n months
  y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Delete Me
Email address: delete...@example.com
Comment:
You selected this USER-ID:
"Delete Me "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key FD87EA81A2F00BA1 marked as ultimately trusted
gpg: revocation certificate stored as
'/Users/rjh/.gnupg/openpgp-revocs.d/6DBE635236A542524E7D950FFD87EA81A2F00BA1.rev'
public and secret key created and signed.

pub   rsa2048/FD87EA81A2F00BA1 2017-08-29 [SCE]
  6DBE635236A542524E7D950FFD87EA81A2F00BA1
uidDelete Me 





signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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 is there any magic that can be
 done?
>>>
>>> Yes.
>>>
>>
>> How? I tried in expert mode but didn't manage.
> 
> --expert --full-generate-key
> 
> Options 8 or 11 should work for you.  Haven't verified it.

Tried both of them, not working. They only produce a single primary key
(8 RSA or 11 ECC) with S,C capabilities (without E).

I have even generated it normally (primary key with capabilities S,C +
subkey with E capability) and tried to edit the key after that, by
deleting the subkey and trying to toggle the capabilities of the primary
key but E is not a valid option to select as capability for the primary key.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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 verification.  A useful
> heuristic, absolutely, but this is still at the level of "let's look at
> the packets to glean publicly available data" -- whereas message
> sanitization and verification would require access to the content of the
> message.
> 
> Part of this is, I think, the OP is being a little handwavy with the
> idea of verification/sanitization.  If what you're checking is dependent
> in any way on the cleartext, then you're screwed.  And if what you're
> checking is dependent on the ciphertext, you're not really dealing with
> the message at all, but the container it's packaged into.
> 

Yes, what needs to be checked is dependent on the cipher text. Only if
the message has all the packets and theoretically can be decrypted (if
the recipient has the private key). It does not matter if the cleartext
makes sense to the recipient or not.

"look to see which keyids are given as hints in the outermost layer" --
not sure I understand here. I am trying to do a check that is natively
supported by gnupg.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> 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

>>> 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 is there any magic that can be
>>> done?
>>
>> Yes.
>>
> 
> How? I tried in expert mode but didn't manage.

--expert --full-generate-key

Options 8 or 11 should work for you.  Haven't verified it.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> 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
heuristic, absolutely, but this is still at the level of "let's look at
the packets to glean publicly available data" -- whereas message
sanitization and verification would require access to the content of the
message.

Part of this is, I think, the OP is being a little handwavy with the
idea of verification/sanitization.  If what you're checking is dependent
in any way on the cleartext, then you're screwed.  And if what you're
checking is dependent on the ciphertext, you're not really dealing with
the message at all, but the container it's packaged into.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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 with his private key;
[SNIP]
> So no.  Can't do this, sorry.  You can check the message format to make
> sure all the packets are well-formed and make sense, but you can't do
> more than that.  Only the message recipient can.
> 
>> - verify that the message was encrypted for Bob and not for anyone else
>> (Alice didn't mix recipients by mistake);
> 
> Kind of, by checking the message format.
> 

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?

>> 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 is there any magic that can be
>> done?
> 
> Yes.
> 

How? I tried in expert mode but didn't manage.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[Robert J. Hansen]

> 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 message and ensure it's not
mangled, but that's about it.  A loose proof of this follows:

GnuPG only uses asymmetric crypto to encrypt the session key(s) for a
message.  The message itself is encrypted with a symmetric cipher using
a randomly-generated key.  A key principle of symmetric ciphers is the
output of that cipher should be indistinguishable from random noise.

So you have a message you're couriering.  To you, it appears to be
random noise.  How do you do message integrity on random noise?  If you
can distinguish correct from incorrect encrypted data, then clearly
you're able to discern information about the underlying message, which
contradicts the given that the data you're looking at is
indistinguishable from random noise.

You might be able to attach a SHA256 of the encrypted data packet, but
that only tells you if you're carrying the encrypted data packet the
sender intended -- it doesn't tell you a thing about whether the
*decrypted* message will be sensible to Bob.

So no.  Can't do this, sorry.  You can check the message format to make
sure all the packets are well-formed and make sense, but you can't do
more than that.  Only the message recipient can.

> - verify that the message was encrypted for Bob and not for anyone else
> (Alice didn't mix recipients by mistake);

Kind of, by checking the message format.

> 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 is there any magic that can be
> done?

Yes.

> 3. Is it possible to import a secp256k1 private key and use it? For
> example a secp256k1 key in the following format:

Dunno.

> 4. Is there a way to skip the passphrase entirely and not encrypt the
> private key at all?

Yes, but this is usually spectacularly unwise.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key)

[s7r]

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 private key;
- verify that the message was encrypted for Bob and not for anyone else
(Alice didn't mix recipients by mistake);


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 is there any magic that can be
done?


3. Is it possible to import a secp256k1 private key and use it? For
example a secp256k1 key in the following format:

0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

How could this be imported in gnupg?


4. Is there a way to skip the passphrase entirely and not encrypt the
private key at all?


Thanks.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users