Mailing List Archive

On 17-10-2019 21:18, Robert J. Hansen wrote:

> 1. How should we handle the SKS keyserver attacks?
>
> One school of thought says "SKS is tremendously diminished as a
> resource, because using it can wedge older GnuPG installations and we
> can't make people upgrade. We should recommend people use other methods
> than SKS." If you think this is correct, please let me know what you
> think the alternate method should be.
>
> Another says, "with a recent GnuPG release SKS may be used productively
> and we should keep the current advice."

I'd say split it: if there are reasons to use gpg 1.4 for compatibility
or other reasons, don't use sks. If you're using gpg 2.2.17 or newer,
you can use it. The people who knowingly use 1.4 will know they're in
that category.

> "Your existing RSA-2048 keys are fine, you don't need to take any action"

Yet. Please look again in 5 years (estimate is till 2030 but some
unexpected attack might appear).

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Robert J. Hansen wrote in <99710af5-92ac-dbdd-afe9-d60d89614a76@sixdemon\
bag.org>:
...
|1. How should we handle the SKS keyserver attacks?
...
|Another says, "with a recent GnuPG release SKS may be used productively
|and we should keep the current advice."

I am using them, and have had the sks-keyservers.net in my own
cacert pool for a long time. I do only import rarely, very
specific keys, and only with supervision, however. It has always
been like that, and i also always clean keys, since i personally
never really had a glue onto the PGP approach of that web of trust.
I still whimper that the new German passports did not ship with
SSL and PGP keys/certificates. But that is something different.

...
|2. What should be done about the FAQ's guidance to use RSA-2048?
|
|First, I think everyone agrees it should be removed, as it's just not
|accurate any more; we've defaulted to RSA-3072 for some time.
|
|One option is, "remove it and update the text to refer to RSA-3072, our
|current default."
|
|Another is, "remove it and update the text to refer to ECC, which will
|be our next default." (If so: which curve and which lengths do you
|think should be the default?)
|
|(Again, third, fourth, and fifth ways are welcomed.)

This mail only because i want to point out that, if i remember
this correctly, the majority of FreeBSD committers who had a PGP
key used RSA 4096 already in 2002, or around that time. (4.7
times i think these were.)

|3. What should we advise people about their existing RSA-2048 keys?
|
|"There's no rush, but migrating them to [whatever our new guidance is]
|at a deliberate pace is advised, since RSA-2048 isn't expected to be
|generally safe past 2030"
|
|or
|
|"Your existing RSA-2048 keys are fine, you don't need to take any action"
|
|(Again, third, fourth, and fifth ways are welcomed.)

You know, i would say people should be advised to use the most
compatible, most secure keys available for their "very key".
Regardless of computing cost that is. And use specific "weaker",
"faster" or whatever keys for specific purposes, like tarball
signing, or whatever. I have never understood any other advise,
actually. I have vague memories of a very "conservative" sentence
on the use of PGP keys on the mentioned FreeBSD handbook page, it
must be more than 15 years, and i have only read it once.
I adhered to that, and i now that all the RSA 4096 things i have
produced ever since will be safe for quite some time, maybe even
until i die (which could happen anytime though), unless the
quantum thing explodes somehow (not a mathematician here).

I still have to log into SSH hosts which do not support anything
but RSA (i have only ever used RSA keys, not DSA i think it was,
and am using ED25519 for an increasing number of other hosts).

(P.S.: personally i am also still using GnuPG v1.4.23, in my
private path, even though i have 2.2.17 in /usr here, and the
rotating head of ArchLinux also ships the new one, etc. etc.)

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/17/19 3:38 PM, Steffen Nurpmeso wrote:
> You know, i would say people should be advised to use the most
> compatible, most secure keys available for their "very key".
> Regardless of computing cost that is. And use specific "weaker",
> "faster" or whatever keys for specific purposes, like tarball
> signing, or whatever. I have never understood any other advise,
> actually. I have vague memories of a very "conservative" sentence
> on the use of PGP keys on the mentioned FreeBSD handbook page, it
> must be more than 15 years, and i have only read it once.
> I adhered to that, and i now that all the RSA 4096 things i have
> produced ever since will be safe for quite some time, maybe even
> until i die (which could happen anytime though), unless the
> quantum thing explodes somehow (not a mathematician here).

If you absolutely, positively, _need_ the most bits of security then
RSA4096 shouldn't be your go-to anymore. RSA4096 doesn't actually
provide 4096 bits of security. The _key_ sizes may be 4096 bits, but
you must understand the security comes from the the cardinality of
prime numbers, so the actual amount of security is only 131 bits of
security. Compare this to RSA's 3072 bit keys providing 125 bits of
security. Unlike RSA, ECC keys don't scale logarithmically. For ECC,
the fields need to be a prime modulus, but that's about it. As a
result, the key sizes scale linearly with the bits of security by
a factor of 2. So, if you want the most security possible with GPG
_today_ you won't beat curve P-521, which provides ~261 bits of
security, and to get an equivalent in RSA your key size would need
to be at least 15360.

But you have to understand, even 128 bits of security is so
incredibly large that even the combined computing power of every
processor we have now won't be enough to crack it. See:
https://crypto.stackexchange.com/a/48669 for just how effort
it'd take.
By the way, 256 bits of security isn't twice the amount of 128 bits.
129 bits is twice the amount of security of 128 bits. Get it?
If you are curious just how much effort it'd take to break a 256 bit
key, I'd argue that it's physically impossible because there simply
isn't enough energy in the universe to break it... see:
https://youtu.be/S9JGmA5_unY

But I digress. It's not the bits of security that matter anymore.
You have a far bigger chance of being insecure with side-channel
attacks etc, than you are with not enough bits of security. That is
a far bigger security hole... Being on a device that is exposed
to the internet. That's where you'd get cracked. Not the key size
being too small.

-----BEGIN PGP SIGNATURE-----

iLkEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXajragAKCRDo8fj9gx4T
01GGAgkB8tgtFHtx91tvWxKzKdlFoceY68lzw968aWRqnv/ObRVUKDp/GVD/ykdj
Zagk6D+t6V0ua7eUONo9j37/zmwOIfcCCQF4xvT4Mlaqfr2RUqt9Wyp+TEhLtrhJ
GjmOOzrUcfjPT/ckvAk9Rl12gzuorIcbuwrCisN0r3htCwECJLz8s6r69A==
=Rek+
-----END PGP SIGNATURE-----

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

Robert J. Hansen [2019-10-17T15:18:07-04] wrote:

> 1. How should we handle the SKS keyserver attacks?
>
> One school of thought says "SKS is tremendously diminished as a
> resource, because using it can wedge older GnuPG installations and we
> can't make people upgrade. We should recommend people use other methods
> than SKS." If you think this is correct, please let me know what you
> think the alternate method should be.
>
> Another says, "with a recent GnuPG release SKS may be used productively
> and we should keep the current advice."
>
> Is there another solution I'm overlooking? Please don't think I'm
> limiting the discussion to just those two. If you've got a third way
> (or a fourth, or a fifth) I'd love to hear them.

I think the FAQ should briefly discuss the attack and weaknesses of SKS
keyservers. The FAQ could then say that with GnuPG version <something>
user is quite safe. Then mention that there is also alternative,
keys.openpgp.org, with different features.

--
/// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
// https://keys.openpgp.org/search?q=tlikonen@iki.fi
/ https://keybase.io/tlikonen https://github.com/tlikonen

On Thu, 2019-10-17 at 15:18 -0400, Robert J. Hansen wrote:
> 1. How should we handle the SKS keyserver attacks?
>
> One school of thought says "SKS is tremendously diminished as a
> resource, because using it can wedge older GnuPG installations and we
> can't make people upgrade. We should recommend people use other methods
> than SKS." If you think this is correct, please let me know what you
> think the alternate method should be.
>
> Another says, "with a recent GnuPG release SKS may be used productively
> and we should keep the current advice."
>
> Is there another solution I'm overlooking? Please don't think I'm
> limiting the discussion to just those two. If you've got a third way
> (or a fourth, or a fifth) I'd love to hear them.

I think right now the FAQ has a bit of redundancy with mentioning SKS
all the time. My suggestion would be to start by deduplicating that.
Try to make most of it keyserver-agnostic.

Then, possibly in 'Is there any particular keyserver I should use?'
discuss both SKS and keys.openpgp.org. I suppose comparing them would
be good, and mentioning which GnuPG versions are vulnerable
to poisoning.

That said, given that this is a more generic design problem than
specific SKS vulnerability, it would probably use its own answer
in the FAQ.

> =====
>
> 2. What should be done about the FAQ's guidance to use RSA-2048?
>
> First, I think everyone agrees it should be removed, as it's just not
> accurate any more; we've defaulted to RSA-3072 for some time.
>
> One option is, "remove it and update the text to refer to RSA-3072, our
> current default."
>
> Another is, "remove it and update the text to refer to ECC, which will
> be our next default." (If so: which curve and which lengths do you
> think should be the default?)
>
> (Again, third, fourth, and fifth ways are welcomed.)

Well, if it's still meant to say 'Why does GnuPG default...', then
obviously it needs to be updated. Probably it is worthwhile to
explicitly indicate when the default has changed, and why.

Probably the question below it 'Do other high-security...' would also
need to be updated, maybe make it more generic, like what sizes do other
applications use.

> =====
>
> 3. What should we advise people about their existing RSA-2048 keys?
>
> "There's no rush, but migrating them to [whatever our new guidance is]
> at a deliberate pace is advised, since RSA-2048 isn't expected to be
> generally safe past 2030"
>
> or
>
> "Your existing RSA-2048 keys are fine, you don't need to take any action"
>
> (Again, third, fourth, and fifth ways are welcomed.)
>

The latter. Let's wait a bit how things emerge. It would be silly to
have people redo their keys just to have them redo them for ECC again
soonish.

--
Best regards,
Micha? Górny

Robert J. Hansen wrote:

> 1. How should we handle the SKS keyserver attacks?

I would list in the FAQ the kind of attacks possible,
to educate users, before they choose one for uploading
their key.

> One school of thought says "SKS is tremendously diminished as a
> resource, because using it can wedge older GnuPG installations and we
> can't make people upgrade. We should recommend people use other methods
> than SKS." If you think this is correct, please let me know what you
> think the alternate method should be.
>
> Another says, "with a recent GnuPG release SKS may be used productively
> and we should keep the current advice."
>
> Is there another solution I'm overlooking? Please don't think I'm
> limiting the discussion to just those two. If you've got a third way
> (or a fourth, or a fifth) I'd love to hear them.

It would be nice if you can add to the keyserver list also the
mailvelope.com keyserver, because it requires users to authenticate
their keys against the keyserver with an received encrypted email
and it also allows keeping third party signatures, compared to
Hagrid.

https://keys.mailvelope.com

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


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

> It would be nice if you can add to the keyserver list also the
> mailvelope.com keyserver,

I concur keys.mailvelope.com is a fine keyserver today. However, you might want
to consider:

> because it requires users to authenticate their keys against the keyserver
> with an received encrypted email

An "encrypted" verification email in no way, shape or form "authenticates"
a key any more than an unencrypted email. It may seem like it should at first
glance, but it really doesn't if you think through the attack scenarios.

> and it also allows keeping third party signatures, compared to Hagrid.

This property also makes it susceptible to flooding attacks, and Mailvelope
doesn't make use of third party sigs itself.

I talked to Thomas (from Mailvelope) the other day, and he said he would either
want to make their implementation more abuse resistant (which I assume means
dropping third party sigs as well), or decommissioning it altogether in favor of
Hagrid.

Cheers

- V

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

On Fri, 2019-10-18 at 09:19 +0200, Stefan Claas via Gnupg-users wrote:
> Robert J. Hansen wrote:
>
> > 1. How should we handle the SKS keyserver attacks?
>
> I would list in the FAQ the kind of attacks possible,
> to educate users, before they choose one for uploading
> their key.
>
> > One school of thought says "SKS is tremendously diminished as a
> > resource, because using it can wedge older GnuPG installations and we
> > can't make people upgrade. We should recommend people use other methods
> > than SKS." If you think this is correct, please let me know what you
> > think the alternate method should be.
> >
> > Another says, "with a recent GnuPG release SKS may be used productively
> > and we should keep the current advice."
> >
> > Is there another solution I'm overlooking? Please don't think I'm
> > limiting the discussion to just those two. If you've got a third way
> > (or a fourth, or a fifth) I'd love to hear them.
>
> It would be nice if you can add to the keyserver list also the
> mailvelope.com keyserver, because it requires users to authenticate
> their keys against the keyserver with an received encrypted email
> and it also allows keeping third party signatures, compared to
> Hagrid.
>
> https://keys.mailvelope.com
>

This domain seems not to resolve with DNSSEC-capable resolvers.

--
Best regards,
Micha? Górny

Vincent Breitmoser wrote:

> > It would be nice if you can add to the keyserver list also the
> > mailvelope.com keyserver,
>
> I concur keys.mailvelope.com is a fine keyserver today. However, you might
> want to consider:
>
> > because it requires users to authenticate their keys against the keyserver
> > with an received encrypted email
>
> An "encrypted" verification email in no way, shape or form "authenticates"
> a key any more than an unencrypted email. It may seem like it should at first
> glance, but it really doesn't if you think through the attack scenarios.

Well, at least than it is an additional protection layer, which is nice to have.

> > and it also allows keeping third party signatures, compared to Hagrid.
>
> This property also makes it susceptible to flooding attacks, and Mailvelope
> doesn't make use of third party sigs itself.

I think they changed it a while ago. Before one could submit keys, once
they were already on the keyserver. Now it requires again a comformation
email.

And it is true while you can't sign keys with Mailvelope the Key Manager
however shows them.

> I talked to Thomas (from Mailvelope) the other day, and he said he would
> either want to make their implementation more abuse resistant (which I assume
> means dropping third party sigs as well), or decommissioning it altogether in
> favor of Hagrid.

I think that the Mailvelope keyserver is a nice for people who are in need of
CA or classic WoT signatures. So they should IMHO keep it.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


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

Tony Lane via Gnupg-users wrote in <dd866d17-9f49-cf3f-e1a7-b626a7c4676a\
@gmail.com>:
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA512

That seems to be a good choice.

|On 10/17/19 3:38 PM, Steffen Nurpmeso wrote:
|> You know, i would say people should be advised to use the most
|> compatible, most secure keys available for their "very key".
|> Regardless of computing cost that is. And use specific "weaker",
|> "faster" or whatever keys for specific purposes, like tarball
|> signing, or whatever. I have never understood any other advise,
|> actually. I have vague memories of a very "conservative" sentence
|> on the use of PGP keys on the mentioned FreeBSD handbook page, it
|> must be more than 15 years, and i have only read it once.
|> I adhered to that, and i now that all the RSA 4096 things i have
|> produced ever since will be safe for quite some time, maybe even
|> until i die (which could happen anytime though), unless the
|> quantum thing explodes somehow (not a mathematician here).
|
|If you absolutely, positively, _need_ the most bits of security then
|RSA4096 shouldn't be your go-to anymore. RSA4096 doesn't actually
|provide 4096 bits of security. The _key_ sizes may be 4096 bits, but
|you must understand the security comes from the the cardinality of
|prime numbers, so the actual amount of security is only 131 bits of
|security. Compare this to RSA's 3072 bit keys providing 125 bits of
|security. Unlike RSA, ECC keys don't scale logarithmically. For ECC,
|the fields need to be a prime modulus, but that's about it. As a
|result, the key sizes scale linearly with the bits of security by
|a factor of 2. So, if you want the most security possible with GPG
|_today_ you won't beat curve P-521, which provides ~261 bits of
|security, and to get an equivalent in RSA your key size would need
|to be at least 15360.
|
|But you have to understand, even 128 bits of security is so

I might a bit if i follow this road long enough.

|incredibly large that even the combined computing power of every
|processor we have now won't be enough to crack it. See:
|https://crypto.stackexchange.com/a/48669 for just how effort
|it'd take.
|By the way, 256 bits of security isn't twice the amount of 128 bits.
|129 bits is twice the amount of security of 128 bits. Get it?
|If you are curious just how much effort it'd take to break a 256 bit
|key, I'd argue that it's physically impossible because there simply
|isn't enough energy in the universe to break it... see:
|https://youtu.be/S9JGmA5_unY

My download is excessed until the 22nd. But will throw an eye.

|But I digress. It's not the bits of security that matter anymore.

For me the fascinating thing in this area are all those ideas
which human minds had to not have a need to do brute force
searching. Regarding my GPG passwords i think nothing much can be
done about that though, except restricting the search to the bytes
that pass "tr -cd 'a-zA-Z0-9_.,=@%^+-'", but which is already
a significant reduction.

|You have a far bigger chance of being insecure with side-channel
|attacks etc, than you are with not enough bits of security. That is
|a far bigger security hole... Being on a device that is exposed

Yeah, the passwords which were stolen by talking in my sleep are
a real problem.

|to the internet. That's where you'd get cracked. Not the key size
|being too small.

Actually i do not think that is really true, or only by accident.
I think the problems are theft, trojan horses, threat of force,
and that unfortunately includes coercive detention also (maybe
also only and even) in our western first world. So even with what
for example FreeBSD has, where you can have some space on your
harddisk which looks like random data but actually contains an
encrypted partition, (i am pretty sure in the Linux world this is
also doable somehow), there are drugs and other specialists which
can make you talk and reveal that presence. At some later time
i would expect a court order to access log etc. data in and of the
brain implant will increase personal rights and freedom.

And not the key size being too small may likely be true, but
shortly after Y2K i am pretty sure to remember right that the
"usual defaults" where 1024 bits for RSA or so, and whoever
followed that advise and had some records protected by such a key,
and there are records which are of real value, might have or look
forward to problems if they got lost. Which thus brings me back
to the FreeBSD developer handbook entry which talked about 4096
bit keys around that time.

So yes, an excursion like yours is pretty cool and of value, and
experts do know, but for "normal people" i would always favour the
best thinkable default. For that audience that EC stuff may also
just work, then. I mean, the thing is that "normal people"
usually never get to use GnuPG directly anyway, and having the
best defaults if gpg gets used indirectly by application programs
is possibly better than having lots of configurations in this app
and that app. (Like the central OpenSSL configuration file that
is now possible, with sections for individual programs. Though
programs need adjustments to use that.)

Btw., you use autocrypt headers, in this mail of yours there are
thus two certificate keys included. Unfortunately my MUA not yet
can either of them, and will not before next spring.
At that time we will support PGP/MIME and inline signed/encrypted
messages (even though it will not be nice until some later
time). And will have a look into OpenPGP: headers. But not
autocrypt, no.

|-----BEGIN PGP SIGNATURE-----
|
|iLkEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXajragAKCRDo8fj9gx4T
|01GGAgkB8tgtFHtx91tvWxKzKdlFoceY68lzw968aWRqnv/ObRVUKDp/GVD/ykdj
|Zagk6D+t6V0ua7eUONo9j37/zmwOIfcCCQF4xvT4Mlaqfr2RUqt9Wyp+TEhLtrhJ
|GjmOOzrUcfjPT/ckvAk9Rl12gzuorIcbuwrCisN0r3htCwECJLz8s6r69A==
|=Rek+
|-----END PGP SIGNATURE-----
--End of <dd866d17-9f49-cf3f-e1a7-b626a7c4676a@gmail.com>

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/18/19 2:12 PM, Steffen Nurpmeso wrote:
> (redacted)... there are drugs and other specialists which
> can make you talk and reveal that presence. At some later time
> i would expect a court order to access log etc. data in and of the
> brain implant will increase personal rights and freedom.

Not exactly. Actually, this is precisely why I find public key
cryptography so cool. If you do not explicitly add your own address
to the list of recipients, you will not be able to decrypt the message!
This may sound silly, but you may want to write something to someone
that you cannot ever possibly be compelled to decrypt. It will be
impossible for you to decrypt, even though you wrote it and encrypted
it and even if you have the file in your possession and even if you
have all your secret keys and you know all of your own passwords
and have them written down. You can smile serenely while they're
beating you with a rubber hose, knowing that you can't endanger the
lives of your sources, nor give up your rights, even if you felt like
that might be entertaining for a change. This is also exactly why
governments find it such threat - the idea we have a way to truly,
securely communicate in a way they cannot prove who sent what
terrifies them. It's also what lead to the US trying to classify
such crypto as a military munition, which was later repealed in court
in Bernstein vs US Department of State. They're trying to bring it
back though (hah, fat chance)!


> Btw., you use autocrypt headers, in this mail of yours there are
> thus two certificate keys included. Unfortunately my MUA not yet
> can either of them, and will not before next spring.
> At that time we will support PGP/MIME and inline signed/encrypted
> messages (even though it will not be nice until some later
> time). And will have a look into OpenPGP: headers. But not
> autocrypt, no.

I didn't realize there were people in this mailing list who didn't
use it. Well, I turned it off here... that better?
-----BEGIN PGP SIGNATURE-----

iLcEARMKAB0WIQQWZv6JZKxO310TWtXo8fj9gx4T0wUCXapNbAAKCRDo8fj9gx4T
02M3AgifbiLAywfj+K8T0LujTLhyVAFy6UAkP7q+4SQjUuhN510K3RH7Z4WC0/h/
KugrLdV0W+SMPv0jRTuzXyIkAWCAHwIIkYC5/+n85ualrY9WF3Kpk6o2Yws5CWxW
yTmM1wcnNN7uzXOXafLPTxGyca9uqil158OEbfX6GktAc2mrQkFLUNc=
=8nMs
-----END PGP SIGNATURE-----

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

Hello Tony.

Tony Lane via Gnupg-users wrote in <b6c13393-e28a-34d3-1907-a3bcd4608f19\
@gmail.com>:
|On 10/18/19 2:12 PM, Steffen Nurpmeso wrote:
|> (redacted)... there are drugs and other specialists which
|> can make you talk and reveal that presence. At some later time
|> i would expect a court order to access log etc. data in and of the
|> brain implant will increase personal rights and freedom.
|
|Not exactly. Actually, this is precisely why I find public key
|cryptography so cool. If you do not explicitly add your own address
|to the list of recipients, you will not be able to decrypt the message!

But wait, that is a frantic scenario.

|This may sound silly, but you may want to write something to someone
|that you cannot ever possibly be compelled to decrypt. It will be
|impossible for you to decrypt, even though you wrote it and encrypted
|it and even if you have the file in your possession and even if you
|have all your secret keys and you know all of your own passwords
|and have them written down. You can smile serenely while they're
|beating you with a rubber hose, knowing that you can't endanger the
|lives of your sources, nor give up your rights, even if you felt like
|that might be entertaining for a change. This is also exactly why
|governments find it such threat - the idea we have a way to truly,

I find that overly optimistic. It brought two visual film
impressions, one is the poor guy from within the crate in Pulp
Fiction, that is how you end if you run out of hopes at some time,
it seems. The other was a French film of a Basque revel (or
freedom fighter if you want to), who was finally caught and
interrogated under drugs. The drugs made him see (he was a host
before), unfortunately the film ends thereafter with him in
a straitjacket hammering the back of his head against the pad in
some cave cell, trying to get rid of a lot of side channel attacks
(my impression, entirely others may have seen a man gone grazy).

|securely communicate in a way they cannot prove who sent what
|terrifies them. It's also what lead to the US trying to classify
|such crypto as a military munition, which was later repealed in court
|in Bernstein vs US Department of State. They're trying to bring it
|back though (hah, fat chance)!

Oh yes, i also have the impression that hysteria gains currency.
A lot of which surely is tactics to gain momentum against chinese
made and designed communication hardware, nevermind the extra
costs of kindling. (I for one think it is just undemocratic and
antisocial if only one party can spy. And they all do, more or
less, right.)

And we see ambitions to forbid crypto, or to allow only crypto
with backdoors. I personally think this will come some day, just
like the implant will, the benefits are too large, just think
about the possibility to get the entire medical history and
current state of a person in an emergency situation. Criminals
which go to prison by themselves, what do i know :)

|> Btw., you use autocrypt headers, in this mail of yours there are
|> thus two certificate keys included. Unfortunately my MUA not yet
|> can either of them, and will not before next spring.
|> At that time we will support PGP/MIME and inline signed/encrypted
|> messages (even though it will not be nice until some later
|> time). And will have a look into OpenPGP: headers. But not
|> autocrypt, no.
|
|I didn't realize there were people in this mailing list who didn't
|use it. Well, I turned it off here... that better?

"Thank you" ^_^. I think yes! No, i would not, i think it is
a strange thing, of course public keys must come from somewhere,
but passing several hundred or so bytes in each and every mail
message seems like a weird thing to do. Especially if the key is
shipped alongside the message already, and then headers can be
spoofed, so autocrypt makes sense alongside dkim and such third
party signing environments, which i also dislike, in the form they
come. (I would prefer a CMS message envelope i think, but sure,
this requires MIME messages.) I mean, if i want to have signed
communication with someone, i could very well just send her or him
a signed message saying so, and then the key is also where it
belongs, no? Strange thing...

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

> Especially if the key is shipped alongside the message already

Are you sure that it is though? Seems to me you're giving out ill-informed
advice here.

- V

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

Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>:
|
|> Especially if the key is shipped alongside the message already
|
|Are you sure that it is though? Seems to me you're giving out ill-informed
|advice here.

Bad advice of mine yes, PGP does not do it the way S/MIME does it.
Sorry, this was not truly intended, i am more used to CMS and
S/MIME, it just came "naturally" out of me. Side-channel free, so
to say ;}

But you could send a signed message with the public key attached
(as application/pgp-keys even?) to the person you want to
henceforth communicate encrypted and/or signed. You need some
kind of web of trust to make this fly, however. But it would
make it clear that you have the private counterpart.

I do stand to my opinion on the Autocrypt header beside that.
I think the OpenPGP: header with a reference to safe transport for
fetching possibilities is more kind and social, and safer, too.

| - V
--End of <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

Steffen Nurpmeso wrote in <20191021160908.4_HGk%steffen@sdaoden.eu>:

'Just want to add that the DKIM i refer to in my first message is
in my eyes not a solution but a desastrous demolition ball
of the mail standard, and as such hatred by me, and the reply-to:
that was pointing to Tony Lane's real address is gone if one does
not answer him as a primary and at first glance.

To: Vincent Breitmoser <look@my.amazin.horse>
Cc: Tony Lane via Gnupg-users <gnupg-users@gnupg.org>

Brain damaged that too. And i wonder how many archives will be
mutilated and soiled. What will the next generation think,
definetely not the same that "we" do when we look at messages from
the 80s, for example. That is the worst business cr.p in a long
time.

(And i apologise shall some g's be missing, my six month old
Lenovo IdeaPad 530S has a keyboard defect; for now i use
a Mode_switch overfay for f, but it's kinda sick.)


--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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

Steffen Nurpmeso wrote in <20191021160908.4_HGk%steffen@sdaoden.eu>:
|Vincent Breitmoser wrote in <2UJQOP6NMJE80.2FS52GC36TCEU@my.amazin.horse>:
||> Especially if the key is shipped alongside the message already
||
||Are you sure that it is though? Seems to me you're giving out ill-informed
||advice here.
|
|Bad advice of mine yes, PGP does not do it the way S/MIME does it.
...
|But you could send a signed message with the public key attached
|(as application/pgp-keys even?) to the person you want to
|henceforth communicate encrypted and/or signed. You need some
|kind of web of trust to make this fly, however. But it would
|make it clear that you have the private counterpart.

Ok, that "clear" is only true if you then just send an encrypted
messae right afterwards. But that should be it, or am i confused?
I would say that is not an effort too much to gain safe
communication when it is desired. And then there are other ways
of fetching keys, as long as there are keyservers which one can
use.

Thanks for the sks pool is due at that time.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

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