On Tue, 29 Aug 2017 13:21:58 -0500, Mario Castelán Castro wrote:
> Is there any existing, convenient way to do deniable authentication
> for e-mail?
If your communication partners would use the same software, like opmsg.
https://github.com/stealth/opmsg
Or if you would use Bitmessage instead of
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
On 29/08/17 13:33, Robert J. Hansen wrote:
> 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
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
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
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 curv
> 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.
> 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
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 (whic
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 u
> 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 num
> 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.or
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 th
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
>>> Bo
14 matches
Mail list logo
