Re: robots.txt and archiveteam.org...

[Listo Factor via Gnupg-users]

1. GDPR, as any other bloated, convoluted, written in inhuman juridical
language law, mostly benefits two kinds of people: lawyers and
government-related officials. It incurs a lot of ado and expenses, gives
vast grounds for power abuse and so on and so forth.


It also benefits third kind of people: new companies that specialize
in GDPR busywork.


As a side effect, it somewhat helps ordinary people to control the usage
of their personal data. Since data lifespan on the Net is hardly
controllable in whole, the abuse potential of GDPR is limitless. Cheer
the politicians for this excellent masterpiece of legislation.


'Helps' is a big word.  Any company sufficiently evil to abuse your
personal data will continue to do so, and ignore any requests to
the contrary.


As any law or regulation, it has undeniable and numerous detrimental
side effects, which I fully acknowledge. But it establishes an
important principle, completely new to the Internet (and thus often
very irritating to those that are forced to change their MO):

*An individual has the right* to demand that his personally
identifiable information be removed from some specific public
information source, *even if*, at some previous time, in his
ignorance or naivete, he himself made that information publicly
available.

The GDPR as a solution is neither perfect nor without warts, but
our agreement or disagreement with this principle - in my humble
observation - determines how harsh we judge its warts.

lf

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

robots.txt and archiveteam.org...

[Listo Factor via Gnupg-users]

On 7/5/19 10:13 AM, Wiktor Kwapisiewicz via Gnupg-users - 
gnupg-users@gnupg.org wrote:


As for robots.txt not all archiving sites respect it:
https://www.archiveteam.org/index.php?title=Robots.txt


Thanks for posting the link. To quote from the text there:

> What this situation does, in fact, is cause many more problems than 
it solves - catastrophic failures on a website are ensured total 
destruction with the addition of ROBOTS.TXT. Modifications, poor choices 
in URL transition, and all other sorts of management work can lead to a 
loss of historically important and relevant data. Unchecked, and left 
alone, the ROBOTS.TXT file ensures no mirroring or reference for items 
that may have general use and meaning beyond the website's context.

 This is both stupid and arrogant. It is precisely the owner of the
website and data contain therein to decide what is and what isn't of
"general use and meaning beyond the website's context", not of some 
aggregator/archiver's management.


GDPR has indeed changed the nature of Internet forever, and it is for
the better. If Google was put in its place (well, at least first steps
have been made..) by the EU, surely it will be possible to force other,
lesser operators of "archived information" to toe the line. Among other,
to respect the straight and simple Robot Exclusion Protocol. It is not
at all something difficult to do.



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

Privacy vs. security

[listo factor via Gnupg-users]

On 01/16/2018 06:05 PM, Andrew Gallagher - andr...@andrewg.com wrote:


Ultimately, the PGP ecosystem prioritises security over privacy. They
are not the same thing, and in some cases they are in conflict.



Somewhat of a generalization, but essentially correct. More
precisely - if I may - it's point of balance between the privacy
and security represents our thinking about the relative importance
of these two categories at the time the system was conceived,
decades ago.

Since that time, our view about the importance of security has
changed very little. Our view about the importance and desirability
of privacy has changed a whole lot.

Consequently, it is time to re-examine the point of balance
between the two.



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

Re: a step in the right direction

[listo factor via Gnupg-users]

On 01/16/2018 01:17 AM, Robert J. Hansen - r...@sixdemonbag.org wrote:


The SKS community has been discussing a considerably worse nightmare
scenario for the past seven years.


Considering the possibility that this particular system will
be forced to conform to a more contemporary (and I would argue
more enlightened) legislative framework in respect to the right to
privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)
should not be viewed as "discussing a [...] nightmare scenario",
it should be considered as planning for demands that will be placed
on the system by developments outside of it, i.e., by developments
of the society that the system is supposed to serve.

If there is merit to the principle that an Internet server operator
can not keep publicly serving private data over the objections of
the owner (the same as today, after many battles, he can no longer
publicly serve data of commercial value over the objections of its
owner), then it is not unreasonable to assume that most enlightened
jurisdictions will sooner or later enact such legislation. Yes, it
is DRM, but in my view ethically much more justifiable than DRM over
the data of commercial value.

The fact that one large jurisdiction is well on its way with
enacting this, while another is not there yet, should be viewed
as a fortunate circumstance, one that buys us time to do what needs
to be done, not as an excuse to bury our heads in the sand.


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

Re: a step in the right direction

[listo factor via Gnupg-users]

On 01/15/2018 10:45 PM, Robert J. Hansen - r...@sixdemonbag.org wrote:

Which would be step in the right direction when compared
with the current situation.



..> First, people in bad places like Syria and Iran lose the ability to...

I would never allow my opinion of what are the "good places" and what
are the "bad places" to enter into a technical discussion.
(On immigration, or on security engineering).

...

_Literally every major FOSS package manager breaks.  Updates become
impossible._

Let that sink in for a moment.

I don't think you understand anything about the ecosystem here.  You're
advocating burning down a _critically important part of the entire FOSS
landscape._


Burning it down is not what I was advocating. I am advocating orderly
evacuation and replacement of a system that has clearly outlived its
usefulnesses. If it is not replaced in time, it will, at some point,
burn ignited by forces we have no control over. ~Then~ it will have
to be abandoned in rather more painful manner - just as you are
alluding to.

EU legislation, among other things, will see to that. The times are 
changing, and nobody is free to keep serving publicly someone else's

private information over the objections of the owner. "This is the
way we always did it" is a poor response and it will not be a valid
one forever.


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

a step in the right direction

[listo factor via Gnupg-users]

On 01/15/2018 06:53 PM, Andrew Gallagher wrote:



On 15 Jan 2018, at 16:39, Stefan Claas  wrote:

Maybe we need (a court) case were a PGP user requests the removal
of his / her keys until the operators and code maintainers wake up?


You also need to prove that removal is technically possible. Otherwise all that 
such a court case will achieve is to shut down the keyservers.


Which would be step in the right direction when compared
with the current situation.


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

Re: New smart card / token alternative

[listo factor via Gnupg-users]

On 11/08/2017 03:45 PM, Peter Lebbing wrote:

On 08/11/17 16:27, ved...@nym.hush.com wrote:

or, more practically, just post anonymously to a blog or website,
using --throw-keyid, with a pre-arranged understanding that the
sender and receiver post to and check certain websites


I did not phrase it properly, leading to a misunderstanding.

We are talking about using a smartcard on a compromised computer. I
reasoned from the OpenPGP Card specification[1]. You can simply ask the
smartcard for the public key; the actual cryptographic public key.

So as an attacker with control over the computer, you see that someone
succesfully decrypts a document using his OpenPGP card. You ask the
smartcard for the public key that was used to encrypt the document, and
you have a fully unique identifier for the key that was used.


there are many real-world use cases where the recipient does not mind
that an adversary knows he is receiving encrypted communication, as
long as the content is secure, but where the sender can be exposed
to various levels of unpleasantness if the adversary can find out
he is communicating with a specific recipient, using encryption.

The ownership of a device such as one discussed in this thread is
trivial to conceal, especially when compared to a computer equipped
to participate in encrypted communications.

Real-life threat-models are much more varied than what Alice, Bob
and Eve would have us believe.


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

Re: New smart card / token alternative

[listo factor via Gnupg-users]

On 11/06/2017 10:26 PM, ved...@nym.hush.com wrote:


On 11/6/2017 at 4:55 PM, "Tim Steiner"  wrote:

With this solution you can keep the key offline, carry it with you and it  > 
works even on a computer where you can't install software...

>

We are interested to hear feedback on this approach from the community.


=

Using this on anything except your own computer, or laptop, is problematic...


=

This is a mantra from another, more gentle time.

Today, there is a whole class of real-world use cases where the
protection of the user demands that it not be known to the adversary
he or she is communicating with someone, as much - or even more -
than it is required that the content of the communication is kept
confidential. If the connection between the user and the computer
is transient, there may well be many instances where the adversary
will not be able to identify the user, even if he manages to learn
the content, and where the content, without the identity of the
communicator, is of very limited value to the adversary.

It therefore appears to me this is a worthwhile project, provided,
like always, *and for any crypto*, the user understands his or her
threat model.



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

Re: Key Storage Abstraction?

[listo factor via Gnupg-users]

On 10/15/2017 08:35 PM, Jamie H. via Gnupg-users wrote:
> ...I'd like to actually access GPG*as*  a library, but all the tools 
I see seem to invoke GPG as a program and then operate on its standard 
output...


What you need is GPG as a pure crypto-engine; completely divorced from 
all key management and user interface functionality, so that both of 
these tasks can be performed by applications that are tailored to meet 
specific user population operational requirements.


This ("GPG crypto-engine" ?) would be a software package of significant 
general utility.


In addition to the requirements you outlined, I would add one more: it 
should abandon all attempts to protect the secrets (private key or 
plaintext) from other users and processes running on the computer on 
which it is running, and it should sacrifice the execution efficiency 
whenever it significantly impacts the code. This would reduce the 
complexity of the code, so that it could be more easily audited and made 
platform independent. Ideally, it would be a BSD or similarly licensed, 
so that it could be included in source form into applications such as yours.





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

Attack costs

[listo factor via Gnupg-users]

Firstly, I think it's really easy to get carried away here with
security measures one probably doesn't really need.  If you do have a
need for air-gapped computers then you also have a need for a lot of
other security measures.

1) How good are the locks on the doors to your house?
2) What about your windows?

(...)

Just my opinion and it's not meant as criticism just as "food for thought"


Well, here goes:

A competent adversary can spend $100K to develop and deploy a software 
tool that will compromise computers of one thousand of its opponents. 
Thus the cost per compromised computer is $100.- If it costs $1000.- per 
opponent to send an operative (or, more likely, a team of operatives) to 
physically enter the computer location in order to compromise it, the 
total cost to the attacker is one million.


The numbers are, obviously, for illustrative purposes only. But my 
thoughts is this: when it comes to mass surveillance, over-the-net 
attacks may indeed be of significantly greater concern than physical 
attacks.


(Another, perhaps tangential, thought: in the era of mass surveillance, 
money is the principal limiting factor for a whole class of large 
institutional attackers - both ethical and legal limitations are long gone).


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

Safe transfer via USB devices

[listo factor via Gnupg-users]

Use a USB floppy disk reader/writer and shred the floppies with 
cleartext after the use. Writing sensitive cleartext to USB flash 
"drives" that could potentially fall into the adversary's hands should 
be avoided.


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

Re: Key expiration question

[listo factor via Gnupg-users]

On 06/13/2017 01:02 PM, Peter Lebbing wrote:


An expired key will definitely not be able to issue valid signatures
after the expiration date. 


There is nothing ~in the key itself~ that prevents any key
from being used to create signatures, it is only a feature of
the software used to create the signature to compare a date in
the key with some arbitrary external information (computer
system date) that may or may not observe such limitation.
The key expiration date should therefore be considered a only
~suggestion~, and not a ~limitation~ for creating or not
creating signatures.

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

Re: Don't send encrypted messages to random users

[listo factor via Gnupg-users]

On 05/29/2017 11:52 PM, Konstantin Gribov - gros...@gmail.com wrote:

Primary reason to publish a key is to make it available for fetching. It
isn't a permission for anyone to annoy a person anyhow.


Keservers have every characteristic of a public directory.

What possible reason there could be for placing one's
e-mail in the public key if not to make it possible
for anyone to send an e-mail to the owner. To make
a piece of information publicly available on the net
and then depend on "netiquette" for that piece of
information not be used in a manner the owner finds
objectionable strikes me as a rather outdated notion.


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

Don't send encrypted messages to random users

[listo factor via Gnupg-users]

This I find surprising: if one does not want receiving
encrypted messages from those that he does not have
existing relationship with, why does he publish his
public key on public keyservers?

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

Re: "general purpose OS is fundamentally inadequate for trusted operations"

[listo factor via Gnupg-users]

On 04/24/2017 12:42 AM, Robert J. Hansen wrote:

-- but [smartcards] do not rise to the level listo is

> ascribing to them...

The central argument I've been making in this thread is not the
promotion of smartcards, it is something best summarized by
the quote from the Laurie-Singer paper: "...the general purpose
operating system is fundamentally inadequate for trusted
operations." The problem has grown immensely since that paper
was written, so that today *it affects the average gpg user*.

The use of smartcards is to me only a welcome sign that a
growing segment of gpg users appears to agree with that
proposition. They should be helped and advised how to better
tackle the problem, instead of being told that the problem
exists only for those that face some arcane class of
adversaries with mythical powers.



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

yes, Virginia...

[listo factor via Gnupg-users]

On 04/22/2017 11:12 AM, Peter Lebbing wrote:


It feels like you are saying "if you have a real need for
communication security, a smartcard will make you more secure";


No, this is not what I'm saying...

When asked, I simply repeat that I completely agree with the above
quoted "Laurie/Singer proposition". For those that agree, the
practical (but not effortless) options are:

a) Simulate their "Nebuchadnezzar device" on an air-gapped general
purpose computer with a general-purpose OS, equipped with crypto 
software, that never connects to the Internet.


b) Set up their primary general purpose computer as a dual boot
machine, with the trusted OS that does not include access to the
network hardware, that can read the data extents of the connected OS,
and that is regularly refreshed from a verified static system image.

c) Smart card can be, in some marginal instances, only "better than
nothing". Tea-spoon better.

I also tell them that using encrypted mail on an Internet connected
general purpose OS computer is good for practice and "fun factor",
but not much else.

Finally, I completely agree that it would be irresponsible to say
to those with real need for communication security, that simply using
a Smartcard will increase their general security level. However,
vague statements to the effect that "yes, Virginia, you can preserve
the security of your endpoint system" are not any better.


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

"general purpose OS is fundamentally inadequate for trusted operations"

[listo factor via Gnupg-users]

On 04/10/2017 03:25 AM, Robert J. Hansen - r...@sixdemonbag.org wrote:


Preserve the security of your endpoint system.  Nothing else will do.



The year is 2017 and this is simply no longer a practical strategy:

"...Our position is that the general purpose operating system is 
fundamentally inadequate for trusted operations. One can have a

general purpose system or a trusted system, but one can't get both
in a single package. So one needs two..."

Quoted from an almost 10 year old paper "Choose the Red Pill and
the Blue Pill" by Ben Laurie and Abe Singer. Full paper pdf can
be found on the 'net. It's more than worth reading the whole text.

Smart card is not the device authors discuss in that paper, but
it is a small, evolutionary step toward it. It is the best that
many users who agree with the quoted sentence have at their
disposal at the moment. It might not prevent all imaginable
attacks, but it could prevent enough of those to make it worth
deploying.

Use of smart card is an operational complication, and it does
present a "barrier to entry". Consequently, the promotion of it's
use is frowned upon primarily by those that are more interested
in spreading the use of gpg for philosophical and political
reasons among those that don't have any real adversaries, rather
than in the protection - however imperfect - of those that have
real need for communication security.



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