Re: Preventing public key upload to key-servers

[Johan Wevers via Gnupg-users]

On 29-01-2022 4:43, jonkomer via Gnupg-users wrote:

>> When the keyserer operator operates outside
>> of the EU I don't think that is a legal problem.

> If an individual that requests his personal information is
> removed (i.e., the "right to be forgotten") is EU resident,
> GDPR applies regardless of the jurisdiction in which the
> information server is located.

That's what the EU claims. Other countries can value that opinion just
as much as some other countries that want people convicted outside their
borders for insulting Dear Leader.

If the EU isn't ready to use the ultimate law (might makes right) then
it's just a dead letter.

-- 
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
https://lists.gnupg.org/mailman/listinfo/gnupg-users

First Amendment and Marines?

[jonkomer via Gnupg-users]

My personal preferences have nothing to do with the topic
discussed here. I was simply trying to help an organization
that is, for *their own good business reasons* very much
motivated to adhere to GDPR, use existing IT infrastructure
to move to a more secure method of communication.

I was the one to suggest to them to use e-mail and OpenPG
encryption. The reasons were two-fold: first to avoid one of
those centralized, web-browser based, single-point-of-failure,
essentially insecure communication setups so common today;
the second was to make their member's communication
interoperable with general Internet population in order
to increase organization's visibility and promote wider
adoption of encrypted e-mail. I posted my original question
only in order to find out some technical details on how to
do that.

Posting the question was worthwhile, as I have learned
that:

(a) Unfortunately, OpenPG email encryption is incompatible
with GDPR and should not be used by those that either want
or need to be GDPR compliant.

(b) GDPR appears to be a topic that, for some strange reason,
elicits emotional reactions by the OpenPG creators and
maintainers.

(c) GPG and OpenPG appear to be very much US-centric
endevours. That fact ought to be taken into account by the
new users.

If the ultimate goal of OpenPG is the wider adaption of
encrypted e-mail, finding technical means to make it usable
by those that *wish to be GDPR compliant* - without forcing
such MO on everyone - appears to be a worthwhile effort.

I thank again to all that have contributed their answers,
comments and opinions.

Jon K.


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

Re: Thunderbird's hints and history for OpenPGP/MIME (new wiki page)

[Binarus]

On 03.12.2021 12:04, Bernhard Reiter wrote:

First I wanted to gather some feedback, especially about the following
section, where I've added a recommendation what to use instead
of incompatible header encryption:


| Transport information in a decentral network - just like the writing on the
| outside of a postal mail envelope - cannot be protected in principle.
| When reflecting on this, chose  a subject that is plausible in context,
| but without sensitive contents, to best veil potential unwanted observers.
| (Your thinking is right: The more sensitive this is, the more you have
| to build up a plausible context for your unavoidable traces first.)


I didn't read the wiki page yet, but I'd like to comment on that paragraph. I 
agree in part, but not completely. The idea is nice, but can't be realized in 
practice.

From my personal experience, it is very hard and consumes time to find appropriate 
subject lines. After all, when using OpenPGP in business, recipients invest 5 seconds per 
message at maximum when scanning the list of received messages to decide what message to 
read first. "Wrong" subject lines are not helpful in this context. That means 
that your suggestion may be valid for private communication, but not for business.

Rather, it is often good style and really simplifies things if some important (sensitive) data is 
in the subject line. As an example, imagine that you are communicating with your health insurance 
company. The staff there usually is very grateful if they see your insurance number in the subject 
line, plus a few keywords (in German, for example, "Kündigung", 
"Leistungsantrag" etc.). Not following this convention costs them time and effort and is 
bad style.

Apart from that, you'll have some trouble yourself with that strategy. Imagine you have to find a message you have sent 
two years ago. That could be hard if you have "faked" the subject lines. Furthermore, the recipient will 
hopefully answer your message one day, and will typically do this by just hitting the "Reply" button. That 
means the answer comes back with the same "fake" subject line you originally had chosen, and that game will 
continue until the communication on this subject has ceased. In the end, you have 50 sent messages and 50 received 
messages with a "wrong" subject line.

Your comparison with snail mail is the right way to understand the issue: Did you ever 
receive a letter from your health insurance which carried the actual subject on the 
*outside* of the *envelope* (example subject of a letter from your health insurance: 
"Payment for your HIV treatment")? I didn't, and I'll have a very serious talk 
with the sender if I ever do.

*Every* piece of data should be protected, especially in electronic 
communication, except the transportation data which technically is absolutely 
necessary to get the transport done. In the same way the postal service does 
not need to know the content of a letter (including the subject) to transport 
it from the sender to the recipient, SMTP servers do not need to know the 
subject to transport messages.

SMTP basically needs only the sender address (strictly looking at it, not even 
that, but it is important for bounces and replies) and the recipient address. 
Sad to say that SMTP servers usually dynamically add headers during transport 
which already can put somebody at risk, but I guess we'll have to live with 
that for the moment.

A subject line really does not fall into the category of transportation data. 
SMTP servers don't need to know it to transport the message, and it can (and in 
most cases, will) contain sensitive data. We shouldn't call something 
transportation data solely because it is in a header.

I am very grateful that we can finally encrypt the subject line with most OpenPGP 
implementations since several years. Actually, not being able to do this kept me from 
using PGP (in E-Mail) for a while. Now I always encrypt the subject line, and so do my 
communication partners. If there are MUAs out there which can't cope with that, 
refraining from encrypting the subject would be the wrong reaction. Instead, people using 
such a MUA should be educated to use another MUA. PGP implementations have undergone 
changes which were much more "breaking" than encrypted subject lines.

Best regards,

Binarus


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

Re: First Amendment and Marines?

[Robert J. Hansen via Gnupg-users]

I was simply trying to help an organization
that is, for *their own good business reasons* very much
motivated to adhere to GDPR, use existing IT infrastructure
to move to a more secure method of communication.


And, for those people and businesses who have to do business with the 
EU, the GDPR is worth complying with even when it's not strictly 
enforceable.  For instance, United States airline companies that fly 
into the EU voluntarily comply with the GDPR for EU citizens flying 
within the United States, because if they don't they might find their 
access to European airports restricted.


But if you're an American without EU ties, the GDPR is yet another piece 
of foreign legislation we don't need to pay attention to.  And when 
Europeans baldly say "the GDPR applies worldwide, you must follow it," 
what we hear is "the EU overrides your silly Constitution."


At which point we tell you to have that argument with the Marines, 
please.  That position you're pushing is a thoroughly silly one, and it 
deserves to be called out as such.


I don't hate you.  I don't dislike you.  I don't hold you in contempt. 
In fact, I don't even *know* you.  You said something many Americans 
find very silly, and we laughed.  That's all that happened.  :)



(a) Unfortunately, OpenPG email encryption is incompatible
with GDPR and should not be used by those that either want
or need to be GDPR compliant.


No, it's quite possible to be GDPR compliant, as evidenced by the fact 
the German government has adopted it.  I'm pretty sure the German 
government has a number of lawyers specializing in EU regulation, and 
they're fine with it.


Perhaps you might want to ask, "how is the German government complying 
with GDPR?"



(c) GPG and OpenPG appear to be very much US-centric
endevours.


It's not.


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

Re: First Amendment and Marines?

[Jonas Tobias Hopusch via Gnupg-users]

Small correction: The standard is called OpenPGP, not OpenPG.

IIRC, OpenPGP is an open protocol specification by the IETF that succeeded the
original proprietary Pretty Good Privacy.

GNU Privacy Guard (often abbreviated to GnuPG or GPG), the software this 
mailing-
list is for, is merely one implementation of the standard (albeit an extremely
widespread one).

Sorry if I come across condescending, my intention is only to avoid
misunderstandings.

-- 
Jonas Tobias Hopusch

OpenPGP Keys for encrypted communication are available via Web Key Directory 
(WKD)
or from https://downloads.jotoho.de/openpgp/

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

YubiKey 5C NFC not detected

[Felix E. Klee]

I would like to set up a YubiKey 5C NFC for SSH, but it doesn’t get
detected by GnuPG:

$ ykman config usb -l
OTP
FIDO U2F
FIDO2
OATH
PIV
OpenPGP
YubiHSM Auth
$ cat .gnupg/scdaemon.conf
reader-port Yubico Yubi
$ gpgconf --kill gpg-agent
$ ps x | grep scdaemon
  33408 ?SLl0:00 scdaemon --multi-server
  49465 pts/2S+ 0:00 grep scdaemon
$ /usr/lib/gnupg/scdaemon --version
scdaemon (GnuPG) 2.2.32
libgcrypt 1.9.4-unknown
libksba 1.6.0
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ gpg --verbose --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

What can I do?


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

Re: First Amendment and Marines?

[Ingo Klöcker]

On Samstag, 29. Januar 2022 17:38:24 CET jonkomer via Gnupg-users wrote:
> Posting the question was worthwhile, as I have learned
> that:
> 
> (a) Unfortunately, OpenPG email encryption is incompatible
> with GDPR and should not be used by those that either want
> or need to be GDPR compliant.

I disagree with this conclusion. For example, you could use OpenPGP keys with 
pseudonymous user ids or even with identical user ids. Obviously, this would 
make using OpenPGP more difficult because the email clients couldn't easily 
map OpenPGP keys to email addresses. OTOH, some email clients actually support 
mapping of OpenPGP keys to contacts. Maybe even the company's internal address 
book could be used for this. This way uploading those OpenPGP keys to 
keyservers wouldn't leak email addresses. Arguably, the OpenPGP keys 
themselves could still be considered as person identifiable information. In 
this case, you might want to use symmetric encryption (which OpenPGP also 
supports). But that makes using encryption even more difficult because now you 
have to share the passwords used for symmetric encryption and, at the same 
time, make sure that those passwords are kept secret.

> (b) GDPR appears to be a topic that, for some strange reason,
> elicits emotional reactions by the OpenPG creators and
> maintainers.

I don't know who you mean by "the OpenPGP creators and maintainers". Neither 
Phil Zimmermann, the original author of PGP, nor Werner Koch, the original 
author and maintainer of GnuPG, have participated in this thread. OTOH, some 
people who have replied to you are also on the mailing list where the future 
of the OpenPGP standard is discussed.

> (c) GPG and OpenPG appear to be very much US-centric
> endevours. That fact ought to be taken into account by the
> new users.

I find it ironic that you are accusing GnuPG of being a US-centric endeavor. 
You really need to do some more research before jumping to such absurd 
conclusions.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: YubiKey 5C NFC not detected

[Ingo Klöcker]

On Samstag, 29. Januar 2022 22:24:03 CET Felix E. Klee wrote:
> I would like to set up a YubiKey 5C NFC for SSH, but it doesn’t get
> detected by GnuPG:
> 
> $ ykman config usb -l
> OTP
> FIDO U2F
> FIDO2
> OATH
> PIV
> OpenPGP
> YubiHSM Auth
> $ cat .gnupg/scdaemon.conf
> reader-port Yubico Yubi

Are you sure "Yubico Yubi" is the correct value for the reader-port option? 
Did you try without specifying this option?

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: First Amendment and Marines?

[Mauricio Tavares via Gnupg-users]

On Sat, Jan 29, 2022 at 12:59 PM Robert J. Hansen via Gnupg-users
 wrote:
>
> > I was simply trying to help an organization
> > that is, for *their own good business reasons* very much
> > motivated to adhere to GDPR, use existing IT infrastructure
> > to move to a more secure method of communication.
>
> And, for those people and businesses who have to do business with the
> EU, the GDPR is worth complying with even when it's not strictly
> enforceable.  For instance, United States airline companies that fly
> into the EU voluntarily comply with the GDPR for EU citizens flying
> within the United States, because if they don't they might find their
> access to European airports restricted.
>
> But if you're an American without EU ties, the GDPR is yet another piece
> of foreign legislation we don't need to pay attention to.  And when

  Not quite. It cares about personal data from people residing in
Europe at the time said data was collected. And even then, you need to
be targeting EU/EEA residents. So, if a German citizen goes to FL and
needs to stop at the emergency care to have a shark bite taken care
of, that data now is owned by the hospital forever, which will figure
out how to make money with it without asking permission.

> Europeans baldly say "the GDPR applies worldwide, you must follow it,"
> what we hear is "the EU overrides your silly Constitution."

  One can argue that the US has done the same. Some of it -- if
you want to do business in the US, you better follow American rules --
makes sense though, but we are difressing here.

> At which point we tell you to have that argument with the Marines,
> please.  That position you're pushing is a thoroughly silly one, and it
> deserves to be called out as such.
>
> I don't hate you.  I don't dislike you.  I don't hold you in contempt.
> In fact, I don't even *know* you.  You said something many Americans
> find very silly, and we laughed.  That's all that happened.  :)
>
> > (a) Unfortunately, OpenPG email encryption is incompatible
> > with GDPR and should not be used by those that either want
> > or need to be GDPR compliant.
>
> No, it's quite possible to be GDPR compliant, as evidenced by the fact
> the German government has adopted it.  I'm pretty sure the German
> government has a number of lawyers specializing in EU regulation, and
> they're fine with it.
>
  I not only agree but also would add that The Bundesamt für
Sicherheit in der Informationstechnik (German Federal Office for
Information Security) itself, which handles computer and communication
security -- critical infrastructure protection, internet security,
certification of security products -- for the German government, uses
it. Badly at times[1], but that is another bag of cats.

> Perhaps you might want to ask, "how is the German government complying
> with GDPR?"
>
  Better than the Irish government, but once again I digress.

> > (c) GPG and OpenPG appear to be very much US-centric
> > endevours.
>
> It's not.

  I agree. Given that it is open source, you can run your own
setup completely independently, including web of trust. Therefore, you
can control data lifetime.

[1] 
https://www.somethingofdoom.com/2021/11/german-federal-office-for-information.html

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

Re: Preventing public key upload to key-servers

[Ángel]

On 2022-01-28 at 20:43 -0700, jonkomer wrote:
> > When the keyserer operator operates outside
> > of the EU I don't think that is a legal problem.
> 
> If an individual that requests his personal information is
> removed (i.e., the "right to be forgotten") is EU resident,
> GDPR applies regardless of the jurisdiction in which the
> information server is located.
> 
> Jon K.

Not really. If an EU resident is travelling on nonEUland, the GDPR
wouldn't apply. And it protect as well an noneulander which was only
temporarily on EU.


In order for the GDPR to apply to a company (controller/processor) not
established in the EU, the people whose data is being processed must be
in the EU (irrespective of whether they are a resident or staying for a
couple of days) and the company would need to be:
a) offering of goods or services (even if it's for free) to such people
in the Union; or
b) monitoring their behavior (which takes place in the Union)


See article 3 for the details:
https://gdpr.eu/article-3-requirements-of-handling-personal-data-of-subjects-in-the-union/


Best regards



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

Re: Preventing public key upload to key-servers

[Ángel]

(changing back the thread subject)

On 2022-01-29 at 09:38 -0700, jonkomer wrote:
> I was the one to suggest to them to use e-mail and OpenPG
> encryption. The reasons were two-fold: first to avoid one of
> those centralized, web-browser based, single-point-of-failure,
> essentially insecure communication setups so common today;
> the second was to make their member's communication
> interoperable with general Internet population in order
> to increase organization's visibility and promote wider
> adoption of encrypted e-mail. I posted my original question
> only in order to find out some technical details on how to
> do that.
> 
> Posting the question was worthwhile, as I have learned
> that:
> 
> (a) Unfortunately, OpenPG email encryption is incompatible
> with GDPR and should not be used by those that either want
> or need to be GDPR compliant.

That's a non-sequitur from the thread. Your GDPR issue is with
people uploading keys to the PGP keyservers without consent, not
with OpenPGP (which doesn't need keyserver nor even specify the
use of keyservers, although they are related technology).

Think about it: If you sent me a physical letter full of personal
information, and I then publish it on the newspaper, with no legitimacy
to do so, in violation of GDPR. Would that make snail-mail incompatible
with GDPR?


Regarding your problem, I would suggest not to include the first/last
name in the key. Only the email address. (Yes, the name part is
optional).

So instead of 
 John Smith 

if would simply be
 


The name part is inherently unreliable, since it cannot know if the
owner is *the* John Smith you want to write to (assuming the user is
actually named John Smith!). On the other hand, the key can be easily
matched with the provided email address.

Of course, a member wanting to correspond with John Smith needs to find
out that their email is john@example.org but that was likely
already the case before, and something which is probably solved through
that "internal verification mechanism" (which I'm a bit wary about, I
would recommend that the keys were provided signed by the domain owner,
so members would only need to trust(sign) that key to know that they
have a valid example.org pgp key. They could be published through WKD.
This doesn't preclude that access to the keys could require
authentication).

A second issue on having the users rely (and the owner needing to
assert) on the name displayed on the key would have been what to do
when a second John Smith wanted to become a member.



Best regards



PS: I guess by the "emotional reactions" you mean Robert J. Hansen
mails, since replies by other people seem much more technical in
nature. You shouldn't generalize from one person to "all creators and
maintainers". In fact, I think -but have not checked- that most of
GnuPG code will have been written inside the EU. There are lots of
OpenPGP users inside the EU, under GDPR, including Government entities
(as Robert J Hansen noted).



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

Re: Preventing public key upload to key-servers

[Robert J. Hansen via Gnupg-users]

PS: I guess by the "emotional reactions" you mean Robert J. Hansen
mails, since replies by other people seem much more technical in
nature.


If by 'emotional' people mean 'amused', then yes.  I thought it was 
cuter than a pailful of kittens.  :)


If by 'emotional' people mean angry, annoyed, or perturbed, then no.


You shouldn't generalize from one person to "all creators and
maintainers".


Especially given that I'm neither of the two!


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

Re: pgp263iamulti06

[Ángel]

On 2022-01-23 at 15:23 -0500, Robert J. Hansen wrote:
> > When generating the key-pair with Re: pgp263iamulti06, the
> > "randomness" is obtained by user's keyboard input. Is it
> > then that the above applies only when the session key is
> > generated?
> 
> No, the whole CSPRNG is (probably) compromised.  PGP 2.6.3 used keyboard 
> interrupts harvested directly from the hardware to get a collection of 
> random bits which it then fed into the CSPRNG to be expanded out into a 
> large quantity of randomish bits.  It's just that when generating a new 
> certificate it always replenished the CSPRNG's entropy -- when 
> generating traffic it didn't, but the CSPRNG was still dependent on the 
> randomness collected earlier.
> 
> On Windows, you no longer have this direct access to hardware and 
> there's almost certainly some determinism introduced by the HAL.

Ok, you made me actually look at pgp263iamulti06. :-)

It seems to be using ANSI X9.17 but built on CAST5. ANSI X9.17 has been
removed by NIST, and CAST5 has a block size of only 64 bits.
Nevertheless, it probably is a decent enough CSPRNG nowadays. Way out
of my reach, anyway.

However, the entropy gathering seems overly optimistic:

It doesn't seem to take timing into account,* just the keystrokes
themselves.** It discards more than two consecutive presses of the same
key, but other than that, it will be assuming about 7 bits of entropy
per key-press. Whereas the user will be typing with a keyboard which
doesn't even have 2^7 keys. Perhaps up to 5 bits of randomness, more
likely on the order of 2^4 different keys, and the keys pounded by the
user won't be independent events, so not even 4 bits of entropy.

There are lots of further mixing (including additional randomness saved
on randseed.bin file), but if you actually had less random bits than
you thought...



Regards


* Time is used to ensure not fetch more than one keypress per second.
** Note: on Macintosh the implementation seem to work slightly
different than the others.



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

Re: First Amendment and Marines?

[vedaal via Gnupg-users]

On 1/29/2022 at 5:39 PM, "Mauricio Tavares via Gnupg-users"  wrote
  Not quite. It cares about personal data from people residing in
Europe at the time said data was collected. And even then, you need to
be targeting EU/EEA residents. So, if a German citizen goes to FL and
needs to stop at the emergency care to have a shark bite taken care
of, that data now is owned by the hospital forever, which will figure
out how to make money with it without asking permission.

=

This is NOT true, 
(but may make sense to someone who has never been a hospital patient
in the US.)

Every hospitalized patient is given a consent form prior to treatment,
which they may edit or refuse to sign.
-It allows release of medical information to the Insurance Carrier, 
-to the Patient's private Physician, 
-to a third party designated by the patient as a 'next-of-kin-with
medical proxy', should the patient not be in a condition to make
decisions, 
-or to a third party statistical group following the frequency and
outcome of a particular condition requiring hospitalization.

The patient can choose any, all, any combination, or none of them. 
And still get treatment.
Vedaal___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Backup of GPG private keys?

[Ángel]

On 2022-01-28 at 08:18 +0100, Werner Koch wrote:
> The problem here is that the public parts of the encrypted private
> parts are not authenticated and by modifying the public parts and
> tricking the user to import such a modified backup, information about
> the secret key can be revealed.

I'm a bit confused by this claim, Werner. 

Say you fetch your key backup from Mallory's safe, and take it to your
basement. The import wouldn't be an online process with timing leaks.
The feedback that Mallory might get is his friend at the door blaming
him for providing a tampered backup.

The private part wouldn't be modifiable without the passphrase. And if
the public part was changed, it would no longer match the secret part
(or it could match the secret key, but have a different creation
timestamp and be effectively a different key than the one you were
expecting to restore), so it should get rejected. And pubkey with a
prime of 1 shall be invalid.
Some preferences could be added/stripped from the public key
(undesirable), but that's far from revealing information from the
secret key.

Could you elaborate? I am surely missing something.

Best regards



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

Re: Preventing public key upload to key-servers

[Vincent Pelletier via Gnupg-users]

On Fri, 28 Jan 2022 13:02:03 -0700, jonkomer via Gnupg-users 
 wrote:
> After the user removal the domain owner is ipso facto
> GDPR compliant. However, he would prefer that a naive user
> (rightly or not) does not consider him unresponsive, and both
> sides have some interest in preventing any Internet server
> from keeping an active and publicly exposed user's name
> and (now defunct) e-mail-address, thus indiscriminately
> advertising forever the fact that John Doe was at some point
> in time a member of Example.org.

How many signatures are expected to be on such key ?
If there are none (or maybe very few, especially if none links to
example.org administration), then would it be reasonable to argue that
this key can have been forged and the association with that domain is
an unverifiable claim ? I have no idea how it would legally fly, and
there is certainly a question of scale (enough individually
unverifiable but globally concordant claims become a globally convincing
picture).


Unrelated note: I find the rhetoric of a few posts in this thread
absolutely astounding. From a crypto question to red scare and "my army
is going to kick your country's ass if it dares talk to me" in two easy
steps ? This is vile.
-- 
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

Ok, you made me actually look at pgp263iamulti06. :-)


I almost feel like I should apologize.


However, the entropy gathering seems overly optimistic:


*wince*

That's quite a bit worse than I remember.  (I haven't looked at 2.6.3 
source code in probably 25 years.)


So, yeah.  I'm comfortable calling the 2.6.3 CSPRNG system fatally 
compromised due to inadequate entropy gathering.


Thank you for looking into this!


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

Re: Preventing public key upload to key-servers

[Robert J. Hansen via Gnupg-users]

Unrelated note: I find the rhetoric of a few posts in this thread
absolutely astounding. From a crypto question to red scare and "my army
is going to kick your country's ass if it dares talk to me" in two easy
steps ? This is vile.


"Tell it to the Marines" is a standard American and British proverb.  It 
even has its own Wikipedia page.  Television shows like "Happy Days" and 
"M*A*S*H" had episodes named "Tell It to the Marines", and it was even 
used in a "Doctor Who" episode once.


The British use it to mean "I am not so foolish as to believe your claims."

In America, it can have the same meaning as the British, but we also 
have a sense of "your plan requires that I comply, and I will not; and 
any attempt to compel my compliance will be resisted with overwhelming 
force."


When someone claims that American citizens without any connection to the 
EU must obey EU laws, "tell it to the Marines" and its rhetorical 
brethren seem entirely appropriate, in both the British and American 
senses.  It's a profoundly silly statement which, if taken seriously, 
would be absolutely guaranteed to be resisted vigorously by the United 
States.


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

Re: First Amendment and Marines?

[Mauricio Tavares via Gnupg-users]

On Sat, Jan 29, 2022 at 10:17 PM vedaal via Gnupg-users
 wrote:
>
> On 1/29/2022 at 5:39 PM, "Mauricio Tavares via Gnupg-users" 
>  wrote
>
>
> Not quite. It cares about personal data from people residing in
> Europe at the time said data was collected. And even then, you need to
> be targeting EU/EEA residents. So, if a German citizen goes to FL and
> needs to stop at the emergency care to have a shark bite taken care
> of, that data now is owned by the hospital forever, which will figure
> out how to make money with it without asking permission.
>
> =
>
> This is NOT true,
> (but may make sense to someone who has never been a hospital patient in the 
> US.)
>
> Every hospitalized patient is given a consent form prior to treatment, which 
> they may edit or refuse to sign.
> -It allows release of medical information to the Insurance Carrier,
> -to the Patient's private Physician,
> -to a third party designated by the patient as a 'next-of-kin-with medical 
> proxy', should the patient not be in a condition to make decisions,
> -or to a third party statistical group following the frequency and outcome of 
> a particular condition requiring hospitalization.
>
1. I myself have been told in more than one occasion by floor
supervisors I would not get service at a certain state-owned medical
institution unless I signed the consent form. I believe that is also
the case with covid vaccines.
2. I sat in a presentation by a certain university owned hospital
about how to get access to their patients' data for research. They did
state once the data is in their system, it is theirs. Yes, since they
are a *medical* organization (this is a subtle detail most people are
not aware of) they are subject to HIPAA, but the data is now theirs.
And that while a patient could oppose to have his data used, he would
have to fill out the forms for each and every single research data,
which meant he had to be aware that the data was going to be used in
the research. That was one of the questions *I* asked. I also asked
about GDPR, to which they replied "oh, we have no European data." I
did get an earful from my boss because of those questions, but hey.
3. Note the data offered was not necessarily deidentified. Let me
rephrase it: deidentification of data per HIPAA, FERPA, the Privacy
Act of 1974 (and its revisions), and NIST sp 800 series  is at best
pseudoanonymized data per GDPR. So, to quote
https://www.theverge.com/2021/6/23/22547397/medical-records-health-data-hospitals-research,
it is a "privacy placebo." (I really like that term)
4. https://www.nejm.org/doi/full/10.1056/NEJMp2102616 talks about
"deidentified" EHR data being aggregate and sold.

> The patient can choose any, all, any combination, or none of them.
> And still get treatment.
>
  Can you provide which regulation states that? I could have used
it many times.

>
> Vedaal
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

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

Re: pgp263iamulti06

[vedaal via Gnupg-users]

On 1/29/2022 at 11:02 PM, "Robert J. Hansen"  wrote:> Please
comment if this is adequate, or there is still a problem with
> Disastry's Linux Version.

Why?

I've been trying to get people to move to OpenPGP for literally a 
quarter-century, Vedaal.  I'm not going to suddenly switch gears and 
work on giving people reasons *not* to migrate.
=
I have publicly posted here that GnupG should not have to make a
considerations with backward compatibility with Disastry's version,
those who use Disastry's version among each other will continue to do
so, and among those who communicate with GnuPG user's, will use GnuPG.

If person1 has a signed and encrypted email to person 2, but which
used IDEA and MD 5, and now wants to decrypt, and re-encrypt and sign,
and send to person 2, who will then destroy the original email, why
shouldn't they be allowed to know if this is safe.  They still use
GnuPG for current email and will not be discouraged by knowing that
there is a safe way to do this in Linux based Diastry's version, which
cannot be sent to person 2's v3 key in GnuPG 2.x

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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

If person1 has a signed and encrypted email to person 2, but which
used IDEA and MD 5, and now wants to decrypt, and re-encrypt and
sign, and send to person 2, who will then destroy the original
email, why shouldn't they be allowed to know if this is safe.


They *are* allowed.  The source code is there for them to study.

What I said is that I'm not going to do that work for them, because I 
think PGP 2.6.3 is best abandoned.  Full stop.  No exceptions.  Migrate 
your data already, you've had over a quarter century.


People are of course free to disagree with me: some do.  But that is my 
position, and I think it's kind of incredible that someone would ask me 
to come up with reasons that would allow PGP 2.6.3 users to justify 
their continued use.  :)


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

Re: First Amendment and Marines?

[vedaal via Gnupg-users]

On 1/29/2022 at 11:06 PM, "Mauricio Tavares via Gnupg-users"  wrote:
> The patient can choose any, all, any combination, or none of them.
> And still get treatment.
>
  Can you provide which regulation states that? I could have used
it many times.

=

It's in the HIPPA act which requires the patient's consent to share
the date, and is in the pre-treatment or pre-hospittalization consent
form itself.
The worst the hospital can do, if the person refuses release to the
Insurance Company, is to bill the patient as self-pay.
The hospital cannot refuse treatment.
Can't speak about Covid, because  *The Science* seems to vary between
conservative and liberal states.
There are many horror stories, but it is not for this mailing list.
Vedaal___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users