Re: E-mail with deniable authentication

[vedaal]

On 8/29/2017 at 2:26 PM, "Mario Castelán Castro"  wrote:Is there any
existing, convenient way to do deniable authentication for
e-mail?
=

There are workarounds to accomplish this:

[1] Sender 1 sends a signed and encrypted pgp e-mail to Receiver 1, 
giving Receiver 1 a 'passphrase'  which they will agree to use for the
next encrypted messages.

[2] Sender 1 and Receiver 1 now send conventionally encrypted messages
with this passphrase, but without signatures.

[3] They both know that only the person who knows the passphrase could
have sent it.

[4] If they want deniability, they can say that the passphrase 'leaked
out' and anybody who it leaked to could have sent it.
Alternatively,

One can generate a keypair with a random name, and send it to the
other one, and they can both sign with it, but encrypt to their own
non-shared keys.

Again, this signing key can be 'leaked' to the public for deniability,
if necessary.
There are probably other similar variations of this approach.
vedaal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

E-mail with deniable authentication

[Mario Castelán Castro]

Hello.

We have OpenPGP/MIME to sign and encrypt e-mail, thus securing the
communication. It is my understanding that the other party can publish
the signature and the unencrypted message and thus prove that somebody
in the possession of the private key wrote (or at least signed) the message.

One way to do deniable authentication is to take a shared secret.and use
that as the key to a MAC function. However, this does not seem to be
implemented in OpenPGP, although it could be done as an additional layer.

Is there any existing, convenient way to do deniable authentication for
e-mail?

Thanks.

-- 
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 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: E-mail with deniable authentication

[Robert J. Hansen]

> We have OpenPGP/MIME to sign and encrypt e-mail, thus securing the 
> communication. It is my understanding that the other party can 
> publish the signature and the unencrypted message and thus prove
> that somebody in the possession of the private key wrote (or at
> least signed) the message.

This is not true except in a theoretical mathematical sense.

For instance, several people in the community (I know I have, and I
recall Werner saying he as well) have seen PGP-signed spam mails that
are the result of a home user using Symantec's PGP mail proxy, then
getting infested by malware which sends out spam.  Since all mail goes
through the proxy and the credentials are cached, the spam mails were
signed.

You can prove origination *only if* you can prove the originating PC was
not compromised.  Given how common compromise is today -- a few years
ago Vint Cerf estimated one in four desktop PCs was compromised -- this
is a very high threshold to clear.

In a theoretical sense, OpenPGP is a nonrepudiable protocol.  But in a
practical sense, it is not.

___
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