Re: HOW to upgrade: 2.0.22 --> 2.3.3 ???

[Robert J. Hansen via Gnupg-users]

A nation state with the ability to crack 1024 bit RSA would not spend
years and billions of dollars on the messages/files of a single
entity.


They absolutely would, in a heartbeat, and they'd consider it a bargain.

Imagine some major world power has a copy of an old message from 
Vladimir Putin, signed in '99 using 1024-bit RSA.  Is it worth a billion 
dollars to break the key, allowing them to forge authentic-looking 
messages that could be useful in disinformation campaigns?


Israel is believed to be a nuclear power but hard information on it is 
rare.  If you were Iran and were in possession of a 20-year-old copy of 
their nuclear weapon locations, would you spend a billion dollars to 
break that, even if 50% of the site locations have changed?  Probably.



They would be able to get the information they wanted for much
less.


When it comes to breaking archival intercepts there may not be an 
alternative.  The U.S. in particular is well-known for archiving old 
encrypted data in the hopes of breaking it later.  VENONA, for instance. 
 In the digital forensics community there are stories of the USG 
holding onto the shattered fragments of a CD-ROM that are being held for 
the day when 3D scanning and modeling matures to the point they can 
reassemble the CD-ROM from its fragments.  Of the DF nerds I worked 
with, all of us believed the story.  We argued instead about whether we 
had that capability yet, or how far away we were.



So for current OpenPGP usage, 1024 bit RSA is for all practical
purposes secure.


No.  Just a flat no.  If breaking RSA-1024 is feasible today, even if 
it's not practical, it will be practical *soon*.


In the United States, Top Secret-rated national security information is 
by default considered a grave threat to national security for 25 years. 
The CIA even has some they've declared major threats for 50 years.


I have zero confidence RSA-1024 will be safe for even *five* years.

Stop using RSA-1024 today.  The best time to stop using it was 25 years 
ago, but if you missed that opportunity, today's the next best bet.


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

Re: HOW to upgrade: 2.0.22 --> 2.3.3 ???

[Robert J. Hansen via Gnupg-users]

to skip PGP-2 keys in existing keyrings.  And of course the PGP-2
encryption has not been broken - only signatures are vulnerable to the
full MD5 hash algorithm attacks we know for 25 years.


Given that PGP 2.6 offered "military-grade" 1k RSA keys, I think it's 
dangerous to think PGP 2.6 encryption is safe.


1k RSA is conjectured to require resolving about 80 bits of entropy. 
Sixteen years ago (I think) a group of hobbyists broke RC5-64.  An 
equivalent project today would likely be able to threaten RC5-72.  An 
equivalent project spun up on an Amazon computing cloud would get 
terrifyingly close to resolving 80 bits of entropy.


And that's for a hobbyist project run on a commercial cloud provider. 
It seems reasonable to think that as budgets rise, so too does the risk.


PGP 2.6, particularly its defaults, is simply too old and generates keys 
that are too small to effectively protect against today's threats.  I'm 
all in favor of keeping the decryption capability around for archival 
reasons, but really, can we _please_ stop using PGP 2.6 since it's now a 
quarter-century since the first commercial release of PGP 5 and the much 
superior RFC2440 standard?



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

Re: website charset encoding for manual

[Robert J. Hansen via Gnupg-users]

Unfortunately the GPH is way to old to be useful.  I also doubt that we
have a working docbook toolchain availabale to build the GPH from
source.


The FAQ is also increasingly out of date.  Since I put it down years ago 
(as a protest against RMS' continued involvement in the Free Software 
movement) no one has touched it.


OpenPGP_0x1E7A94D4E87F91D5.asc
Description: OpenPGP public key


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

Re: All CPU threads

[Robert J. Hansen via Gnupg-users]

Thank you for reply. I was thinking about speeding up the encryption 
process. But if that's not possible then that's how it is.


Thank you for sending a plain-text email to the list!  :)

The answer is a little complicated, but this should be an 
accurate-enough explanation.


Encryption speed is dominated by disk speed first and foremost.  If 
you're encrypting a 1Mb file, you have to read in the file and write it 
out again when you're done: your absolute minimum time is given by 
however long it takes to read and write a 1Mb file.


This is unfortunate, because disk I/O is *slow*.  Even SSDs, which are 
about ten to twenty times as fast as older spinning metal platter hard 
drives, can't completely bridge this gap.  So at the end of the day, 
your bottleneck for encryption is going to be disk I/O.


There are various games people play, like keeping an in-memory 
filesystem.  If you're doing that, then we can look at other places for 
speed improvement.  Remember, as you read what follows: we're doing all 
of these weird things to improve things by a very tiny bit -- the 
bottleneck is in disk I/O!


=

Encryption generates a random session key and encrypts that with your 
recipient's public key.  Here's your next problem: there are *so many* 
algorithms GnuPG supports, and there isn't a single effective 
parallelization strategy for all of them.  Take RSA as an example: the 
expensive part of the encryption operation is P = C^e (mod n), or as 
normal humans call it, "modular exponentiation".


I've got an IEEE paper on my desk (by Budikafa and Pulungan) dating from 
2017 that says you can parallelize modular exponentiation to get up to a 
28% speed improvement.  That's really nice!  The problem is the phrase 
"up to" a 28% speed improvement, and the fact that only RSA uses modular 
exponentiation, so if your correspondent is using ECC you're kind of out 
of luck.


So, when it comes to the asymmetric part of the encryption: a sequential 
version takes a couple of milliseconds, and best-case scenario by 
throwing multiple threads at it you can save 28% on two milliseconds. 
This is not a big enough win to justify the multithreading.


Once you've encrypted the random session key for each recipient, now you 
have to process the file 16 bytes at a time.  For each block after the 
first, the result of the last block's encryption is an input to the 
current block's encryption.  Block 0 (which is the first -- remember, 
computer scientists are weird, we start counting at zero) doesn't depend 
on anything; block 1 depends on having the output of block 0; block 2 
depends on having the output of block 1; and so on.  Even if you were to 
spin up one thread per block you'd still get no speed improvement. 
You'd be encrypting sequentially, one block at a time until you were 
complete.  Multi-threading is thus theoretically possible, but offers no 
advantages.


(Note that Phil Rogaway kind of disagrees with me: he characterizes 
parallelizing cipher feedback modes as possible "but awkward".  When 
Phil Rogaway, one of the sharpest cryptographers in the world, describes 
an optimization as "awkward", I very quietly turn around and start 
moving in the opposite direction.  Clearly I am in over my head and I 
need to escape.)


https://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf -- search for the 
words "but awkward".


Etcetera, etcetera.  Speeding up encryption operations with multiple 
threads is a *deeply* challenging cryptographic engineering problem, and 
for the vast majority of users isn't worth it.  The easy wins (28% cost 
savings on RSA encryption!  Whee, almost half a millisecond!) are too 
trivial, and the big wins are somewhere between "Rogaway says it's 
awkward" and "Rogaway says it's impossible".


That said, the next RFC draft -- when it comes out -- will be offering 
new encryption modes that may offer better parallelization performance. 
I'm sure that if and when the next RFC is officially released, there 
will be interest in getting parallelization support for them.


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

Re: All CPU threads

[Robert J. Hansen via Gnupg-users]

Please do not send HTML to this list.  Many of the people you very much 
hope to read your questions will not read HTML email.


Anyone knows if there is a way to use all CPU threads with 
*gnupg-desktop-2.4.3.0-x86_64.AppImage* ?


What exactly are you hoping to speed up?  The classic mode of encryption 
used in RFC2440 and RFC4880 is a hacked-up cipher feedback mode, which 
is not parallelizable and doesn't benefit from using multiple threads. 
You can of course use multiple threads, but you won't get any benefit.


So my question is, what exactly is it that you need to speed up?  Once 
we know that, we'll be able to give suggestions for how you might proceed.


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

Re: gpg: signing failed: No secret key

[Robert J. Hansen via Gnupg-users]

Please don't send HTML to this list.


gpg: key "6O0PDA84A36B6C98B261AC2020546703CDADFA53" not found


That's not a valid key ID.  Key IDs are strings of hexadecimal digits. 
Your second 'digit' there is the letter O, which is not a valid hexit.



gpg --delete-secret-keys CDSXFA53


That's not a valid key ID.  Neither S nor X are valid hexits.


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

Re: 32768-bit key

[Robert J. Hansen via Gnupg-users]

My name is Snowden.


I don't care.


And I cannot send a decrypted version of the mail.


Then please learn how to do so.

To recap:

1.  There is no point in a 32kbit RSA key.
2.  For that reason, GnuPG doesn't allow you to generate one.
3.  I will not help you do something that has no point.
4.  Do not send encrypted messages to the mailing list.
5.  Do not sent HTML messages to the mailing list.

I hope I am being clear.  If you have further questions that are not 
completely answered above, we look forward to hearing them.


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

Re: 32768-bit key

[Robert J. Hansen via Gnupg-users]

I will not answer encrypted messages posted to the list.  This is a 
public mailing list.  Signatures are fine, but encrypted 
person-to-person messages are not.


Also, please do not send HTML email to the list.  Many of the people you 
hope will read your email refuse to read HTML email.


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

Re: 32768-bit key

[Robert J. Hansen via Gnupg-users]

I don't know that there's anything to file a bug about.  I
don't see any non-rsa4096 keys on the Tails website:


One of their certificates has a Curve-25519 subkey.  I wonder if that's 
what the original poster saw, and mistook it for being a 25,519-bit 
subkey.


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

Re: 32768-bit key

[Robert J. Hansen via Gnupg-users]

How do I upp the limit of the RSA-key to 32768?


First, come up with a reason why you need one.

A 2048-bit key is hypothesized to possess about 112 bits of entropy; a 
3072-bit key, about 128; a 16k-bit, about 256.  You very rapidly reach a 
point of dramatically diminishing returns.  A 32k key gives you 
essentially nothing in terms of resistance to cryptanalysis, while 
making it impossible for the rest of the OpenPGP ecosystem to work with 
you because your public certificate is so unreasonably large.



The TailsOS team has a key that's wy over 16384-bit.


I suggest filing a bug report with them and asking them why they ignore 
the best practices of cryptography.


OpenPGP_0x1DCBDC01B44427C7.asc
Description: OpenPGP public key


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

Re: Multithreading with GPGME Python Bindings

[Robert J. Hansen via Gnupg-users]

(Please forgive the HTML email, sending from my phone)Given Python is effectively single-threaded through the global interpreter lock, this may turn out to be a total non-issue. Although I don't have an immediate answer for you I'd suggest starting by learning how Python's multi-threading support is more smoke and mirrors than reality. That may lead you to an answer to your question.On Jan 16, 2023 1:55 AM, Jan Girlich  wrote:Hi,

I want to use the GPGME Python bindings in a concurrent way.

In the documentation of the Python bindings at
http://files.au.adversary.org/crypto/gpgme-python-howto.html I find no
mention of multithreading.

In the GPGME documentation at
https://www.gnupg.org/documentation/manuals/gpgme/Multi_002dThreading.html#Multi_002dThreading
I find the note, that I need to call "gpgme_check_version" before doing
any multithreaded operations.

Then again I find only this section about version checking in the
Python binding's documentation:
http://files.au.adversary.org/crypto/gpgme-python-howto.html#gpgme-version-check
In this section the version check is done via a subprocess call to
"gpgme-config --version".

Is the call to "gpgme_check_version" maybe done implicitly by the
Python bindings?

Do I have to call "gpgme-config --version" before to safely do
multithreaded operations with the Python bindings?

Thank you for any insights,
Jan

___
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: Difference between versions--Question

[Robert J. Hansen via Gnupg-users]

It would be helpful to know why I can't get compression in my build. 
I've tried to build from source three times now.


The answer is very simple: because you are building it incorrectly.  We 
can provide you with the answers, but we can't give you the software 
development skills needed to correctly use the answers.


There are so many packages in Ubuntu with zip, zlib, and bzip2 in the 
name I can't begin to try them all. I've looked at config.log and it 
doesn't give much help.


If you're unable to recognize which packages provide development headers 
for common system libraries, that would be a sign your skill level is 
not up to this task.


This isn't to say you shouldn't learn.  Learning is good, even 
essential!  It's only to say the problem isn't with GnuPG.


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

Re: symmetric encryption of '[stdin]' failed

[Robert J. Hansen via Gnupg-users]

why can't gpg accept passphrase in the terminal?


Depending on how you invoke GnuPG, it can.  It supports a lot of 
different ways of providing the passphrase.


The one that might work best for your purposes is to put the passphrase 
in a file, passphrase.txt, and then invoke GnuPG like this:


gpg -c --pinentry-mode loopback --passphrase-file passphrase.txt -o 
[myfile].tar.zstd.gpg



Why does it need to start a daemon?


Because GnuPG 2.x already starts the daemon.  It should be running by 
the time you finish logging into your system.



Besides, when I use "gpg -c file", it works fine. I =get asked for
passphrase (via pinentry, I think)


And what do you think launches pinentry?


so I am not sure what you mean by "Where in that command line do you
specify a passphrase"


Really simple.  Where in that command line did you specify a passphrase?

You didn't tell GnuPG a passphrase file to use, a passphrase file 
descriptor to use, or an actual passphrase to use.  So the only thing 
GnuPG could do was ask you for one, and that means using gpg-agent to 
facilitate the interaction with the user.


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

Re: symmetric encryption of '[stdin]' failed

[Robert J. Hansen via Gnupg-users]

Why does gpg-agent interject itself into symmetric encryption at all?


Where in that command line do you specify a passphrase?

You don't.

gpg-agent is getting fired up in order to ask you what passphrase to use 
for the symmetric encryption.


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

Re: How to create v4 key

[Robert J. Hansen via Gnupg-users]

When I choose a RSA3076 key, keyserver.pgp.com will accept it.
When i choose an ed25519 key, keyserver.pgp.com tells me it is a v3-key.


keyserver.pgp.com is *old* and doesn't understand how to use ed25519 
keys.  It is erroneously telling you it's a v3 key, when the reality is 
keyserver.pgp.com is in desperate need of upgrades to support new 
algorithm types.


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

Status of original PGP?

[Robert J. Hansen via Gnupg-users]

On a lark I went looking for the current iteration of PGP.  It was 
bought by Symantec some years ago, and the last I heard they'd renamed 
it to "Symantec Encryption Desktop".  However, Symantec no longer has it 
available for sale or download, and scouring their site turns up 
basically nothing.


Does anyone know what happened to PGP?

Please note: I'm not encouraging anyone to use proprietary, non-free 
software.  My interest in this is purely historical.





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

Re: How did Edward Joseph Snowden use GnuPG to uncover the secrets of the National Security Agency?

[Robert J. Hansen via Gnupg-users]

Subject: How did Edward Joseph Snowden use GnuPG to uncover the
secrets of the National Security Agency?


Short answer: he didn't.


GnuPG is one of the tools that Snowden used to
uncover the secrets of the NSA.


This is incorrect.

According to Glenn Greenwald, he used GnuPG to communicate privately 
with a couple of journalists.  GnuPG played no role in his exfiltrating 
data out of Fort Meade.


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

Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

[Robert J. Hansen via Gnupg-users]

Some years ago after they first published their OpenPGP certificate, Enigmail reached out to them offering training on effective use of OpenPGP and technical support for GnuPG and Enigmail. No cost, Enigmail had a core member who lived near their offices (namely, me), let us know how we can support you.The Washington Post never responded to repeated emails, not even to say "no thank you".Draw your own conclusions.On Aug 5, 2022 6:49 PM, Francesco Ariis  wrote:Il 05 agosto 2022 alle 18:13 Michael Richardson ha scritto:
> Francesco Ariis  wrote:
> > Il 05 agosto 2022 alle 17:28 Jay Sulzberger via Gnupg-users ha scritto:
> >> Does the PGP public key at
> >> https://www.washingtonpost.com/anonymous-news-tips/ work?
> 
> > It gets copied in a weird way (i.e. some characters that should be
> > newlines are instead spaces); I am not able to import it.
> 
> Yeah, the marketing department screwed it up, and should have put  on it.
> It suggests that it has never really been used.
That was what I was thinking. It would be interesting to see how long
the key has been there in such a state.
If the answer is “a long time”, that is quite a field report: it means
signal and whatsapp (!) are more popular options (way more popular
options) than PGP + email for secure communications.
___
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: a bit off topic, how to find encrytped files (ransom attack)

[Robert J. Hansen via Gnupg-users]

 3. I could use the ent command which measure the entropy, high
entropy is an indication of encryption (but jpg have also high
entropy). However I should then study the distribution of each
letter to be sure.


A JPEG *body* has high entropy.  The JPEG *header* has very low entropy. 
 That's a relatively good way to spot container files: you look for a 
low-entropy header followed by high-entropy data.  Zip files, tar.bz2 
files, JPEG files, MPEG, the rest, they're all detectable this way.


However, the output of a straight-up block cipher operating in any 
modern mode (no ECB!) is going to be totally indistinguishable from a 
random number generator for any reasonably-sized file.



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

Re: gnupg2 vs gnupg

[Robert J. Hansen via Gnupg-users]

It seems not as much the binary name seemed the problem but the 
dnf/yum/rpm dependency.


Here's where I hate to sound like a jerk, but I can't help you.  I'm not 
an AIX guy and I don't do packaging for it.  This is a packaging issue, 
not a GnuPG one.  :(


There might be an AIX person on the list who can help, but I'm unable to.



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

Re: gnupg-users@gnupg.org

[Robert J. Hansen via Gnupg-users]

1 What is the difference between gnupg2 and gnupg-2.X.X?


Possibly quite a lot.  GnuPG exists in three different branches.  For 
sake of simplicity I'll call them "modern", "standard", and "classic".


Modern: GnuPG 2.3 and later.
Standard: GnuPG 2.2
Classic: GnuPG 1.4

The differences among them are principally what version of the OpenPGP 
standard they track.  OpenPGP has been around for decades.  The Modern 
branch has some bells and whistles the other two lack (principally 
authenticated encryption, which *technically* exists in the other two, 
but the Modern branch does it in a technically superior way).


Standard and Classic are roughly equivalent in terms of features, but 
Standard exists to support desktop environments, while Classic may be 
more useful in standalone server environments.


We would like to see Classic go away and move everything to Modern, but 
that's not possible right now.  Maybe not ever.



It is looking for gnupg2 but currently my compilation is as gnupg.


If you're downloading the 2.2 or 2.3 branches, you can set the 
executable name by passing a flag to ./configure.  I think it's 
"--program-suffix=2" will add a 2 to the end of all the binaries created 
by GnuPG.  Or, to just set the name of the gpg binary to gpg2, use 
"--enable-gpg-is-gpg2".


Hope this helps.  :)


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

Re: Backing up your PGP key by hand

[Robert J. Hansen via Gnupg-users]

Since paper as we know it today doesn't even exist so long that can't
be true. Maybe you are pointing to the few surviving papyrus texts?
Most have not survived.


I've personally seen paper ballots from elections in the Senate of
ancient Rome.  Admittedly, this was 15 years ago so I can no longer say
precisely which century they were from, but they were indeed paper and
the marks on them were still legible.

The reason why few paper texts survived to the modern day isn't that
paper isn't durable.  It's because paper *IS* durable.  It's a
fantastically useful material and, for most of human history, was
incredibly expensive.  Rather than preserve paper, people re-used it
again and again until it just wore out.  (They did the same thing with 
vellum, too, which was preferred not because it stood up to repeated use 
better, but because it was so much *cheaper*.)


Many Gutenberg Bibles are still in fine condition today.  Of about 160
copies printed, about fifty still exist today.  The paper in question is
linen, which is still used by archivists looking for long-term
preservation.

So, yeah.  I'm going to be solidly on the side of "no, really, paper is
a magic technology, just be sure to talk with an archivist first to
ensure you're using the right kind of paper."

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

Re: using OpenPGP card to unlock a LUKS device on boot

[Robert J. Hansen via Gnupg-users]

You're barking up the wrong tree: It wasn't me who brought politics to
this list.


You're the one who is turning a single throwaway line in someone's 
signature block into an angry argument.



Nonsense. The OP issued a statement, I replied and that could have been
it. It is you who is obviously thriving on extending this discussion.


It "could have been it", I am certain, if he had apologized, removed the 
line from his signature block, and stopped.  Had he done otherwise we'd 
be right where we are now.


Regardless: I think I've made my position clear.  He is under no 
obligation to remove a line from his signature block that you object to 
on purely political grounds.  Let's drop this subject and return to 
talking about GnuPG.




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

Re: using OpenPGP card to unlock a LUKS device on boot

[Robert J. Hansen via Gnupg-users]

Just as I am free to comment on a political statement that I find
provocative, blatantly wrong and in the context of current events almost
derisive.


Excepting that this is not a mailing list for politics.

Matthias has a line in his signature that you object to.  I object to 
it, too, but the only thing we need to do is nothing.  Perhaps you'd 
like to place your own line in your own signature file making your 
pro-NATO feelings clear?  Either way, bringing it to the forefront of 
discussion is incredibly off-topic.


We'd like to keep this mailing list on-topic.  Thanks for understanding.  :)


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

Re: using OpenPGP card to unlock a LUKS device on boot

[Robert J. Hansen via Gnupg-users]

Given recent events: can't you spare us your stupid signature?


Matthias should be, and is, free to advocate for his beliefs in his 
signature.


If we don't stand up for people's right to peacefully say things we 
don't like, we have failed as a community.


I say this as an American who's a fanatical supporter of NATO.  Leave 
the guy alone, and let's get back to discussions about GnuPG.  Thanks.  :)




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

Re: Help with "config.h file not found error" on Gnupg version 1.4.13

[Robert J. Hansen via Gnupg-users]

First of all, thank you for taking your time to reply to this email. I
tried it using the -l flag. The config file was found in the directory
before that. Below is the command I executed.


I don't want to sound dismissive or discouraging, but you may want to 
consider whether you have the necessary C skills for the task you're 
undertaking.  Learning C development is difficult; learning 
cybersecurity is difficult; doing both at the same time borders on the 
impossible.



I tried copying the header file mpi.h into the directory gnupg-1.4.13
and compiling the mpi-pow.c program, now the error is like given
below:


The easiest way to find all the directories you need to include is to 
take a look at the Autotools build script.  GnuPG was never meant to be 
compiled by hand, file-by-file.  Instead, there's an automated system to 
do it, and you can learn everything you need about how to build an 
individual file by studying this system.  Again, it's something you 
learn in the course of becoming a C developer.



Is there anything wrong with the way I used the -l flag ? If so could
anyone guide me in the right direction?


This is a compile-time (include file location) problem, not a link-time 
(library file location) problem.  Again: something discovered in the 
course of becoming a C developer.


Have you considered reaching out to the FLUSH+RELOAD paper authors, to 
see if they have a pre-built binary they might be willing to share with 
you?  It would be a heck of a lot faster than learning enough C to 
implement your own FLUSH+RELOAD on GnuPG.


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

Re: Help with "config.h file not found error" on Gnupg version 1.4.13

[Robert J. Hansen via Gnupg-users]

You will have much better luck if you send only plain-text emails to 
this list.  Some of the people you'd really like to see your email 
refuse to read HTML email, on the grounds that it's a security risk. 
I've quoted your entire message below as plaintext to help you reach 
these people.


To resolve your problem I'd suggest finding where the Automake-created 
config.h header file lies, and including that directory in your GCC 
invocation by using the -I flag.


Hope this helps.  :)

On 3/30/2022 1:21 AM, Francis Kp via Gnupg-users wrote:

Hi all,
As in exercise in understanding Cybersecurity in IoT better, I'm trying 
to implement the flush-reload attack from the paper "FLUSH+RELOAD: A 
High Resolution, Low Noise, L3 Cache Side-Channel Attack". The crux of 
the attack is to extract the private key of RSA encryption used in 
Gnupg. One of the steps to initiate the attack is to find certain memory 
addresses to feed to a spy function. For that I'm trying to open a C 
executable in Gnu debugger(gdb). The program is part of the Gnupg 1.4.13 
version. My aim is to get the memory address of a particular function by 
setting breakpoint at that line. While compiling the c program using 
**gcc -g mpi-pow.c**, (And yes I tried without the -g option) I'm 
getting this error:




*mpi-pow.c:28:10: fatal error: config.h: No such file or directory
        28 | #include 
           |          ^~
     compilation terminated*



These were the exact steps I did:-->

 1.   - Extracted the Gnupg source code using tar xjvf gnupg-1.4.13.tar.bz2
 2.   - cd gnupg-1.4.13/
 3.   - ./configure
 4.   - sudo make
 5.   - sudo make install


The source code of Gnupg 1.4.13 is at Link_to_code 

The original paper is here Link_to_paper 



A quick google search told me that "In computing, configuration files 
(commonly known simply as config files) are files used to configure the 
parameters and initial settings for some computer programs". /And as far 
as I understood, the config file is made when the "./configure" command 
is run and in this case, it simply means there is no config.h file in 
the current directory/. There were no errors during the compilation of 
Gnupg.


I'm using the Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz processor.
I tried it on WSL and on Ubuntu 20.04 installed on dual boot.

  1. What might be the reason ?
  2. How can I rectify this error ?

Any help would be highly appreciated.

___
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: TB weirdness

[Robert J. Hansen via Gnupg-users]

Sounds like a defect to me, do you have a problem report ticket with
Thunderbird or a forum entry which described the problem in more detail
(like which version is affected).


It turns out the actual behavior is a little different than I originally 
described.  If you have a valid certificate with a given email address, 
and a revoked certificate (or certificates) with that same email 
address, it will silently add the revoked certificates, as well as the 
valid one, to your email.  This is still a bad idea.


On the other hand, Thunderbird now says it's a deliberate choice on 
their part, so...


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

Re: Who protects the private key (was: Changing the encryption algorithm used for PGP/GPG private key)

[Robert J. Hansen via Gnupg-users]

Whoever told you SHA-1 is broken was gravely in error. There are certain areas of the cryptographic space where it is no longer recommended. There are others where it's strong as a rock.As part of an iterated key derivation function, SHA-1 is still believed safe.  There's no reason to shy away from it, or AES128.(Forgive my terseness, please, writing this from my phone.)On Feb 19, 2022 11:02 AM, Daniel Colquitt via Gnupg-users  wrote:
> On 19 Feb 2022, at 14:52, Werner Koch  wrote:
> 
> gpg does not encrypt private keys.  This is done by gpg-agent.  The
> method how the keys are protected internally are out of scope for
> OpenPGP.  See gnupg/agent/keyformat.txt for the specification of the
> internal format.

Apologies for conflating gpg and gpg-agent. I also appreciate that the protection of keys is not part of the OpenPGP specification. 

> However, for allowing gpg to export a private key in the OpenPGP
> specified format, gpg-agent applies the encryption.  For this S2K mode 3
> with AES128 and SHA1 is used. 

Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 years. Hence, my question about specifying alternative algorithms for the internal storage and exporting of private keys.

I now understand that it is not possible for the user to alter the encryption algorithm used by gpg-agent to secure private keys. Perhaps it would be a good idea to say this explicitly in a documentation? I appreciate that the manual does not say explicitly that this is possible, it certainly gives that impression.

Anyway, thank you for your help.

Dan
___
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: Can't synchronize keys using Seahorse

[Robert J. Hansen via Gnupg-users]

How can I fix this?


Specify a different keyserver.

keyserver.pgp.com was a commercial keyserver run by PGP Corporation, or 
whichever corporate entity owned the PGP intellectual property at the 
time.  Network Associates gave way to PGP Security gave way to Symantec 
gave way to...


The PGP intellectual property is for all intents and purposes dead at 
this point.  Symantec has even stopped using the PGP trademarks: they 
may still sell the software, but they've stopped issuing new releases 
and they've rebranded it to something as bland as cottage cheese.


keyserver.pgp.com is still operational today, but nobody knows for how 
long.  It would be wise to assume that it will go away at some point, 
and start migrating to another keyserver.


OpenPGP_0x1E7A94D4E87F91D5_and_old_rev.asc
Description: OpenPGP public key


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

TB weirdness

[Robert J. Hansen via Gnupg-users]

Yes, I know, Thunderbird doesn't use GnuPG.  However, for those who do: 
apparently, Thunderbird is a big fan of attaching public certificates 
(and/or revocation certificates, for revoked keys) to outgoing emails 
for *every private certificate on your keyring*, regardless of whether 
that private key is actually associated with the account in question.


This has the potential to leak personal information, especially if 
you're in a use case where you have two or more keys presenting 
different pseudonymous identities.  Without knowing it, you might 
accidentally reveal you're the common actor behind both.


I apologize for bringing the non-GnuPG content to the list, but please 
make sure your correspondents are aware of the possible risk in how 
Thunderbird likes to attach public certificates.  That's all.  Thank you!


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

Re: Current state and contact (various questions)

[Robert J. Hansen via Gnupg-users]

this is my first post here. I'm an experienced Dev and FOSS contributor 
which worked quite some with gpg recently.




Welcome to the party, pal!



:)


1. Who takes care for tasks like updating the website?


Ingo already addressed this fully and correctly, so I'll skip.

2. Difference of public key between gpg and Thunderbird. What do I have 
to do to yield the same public key file?


In my last email I included a link to what I said the last time this 
came up on-list.  If you still have questions after reading that I'm 
happy to answer them.


3. I'm already asking the Ubuntu community but want to ask here too: gpg 
on Ubuntu jammy is 12 months old running 2.2.27. How is the current 
process / communication handled? Is there anything I can do to 
support/speed up this process?


JFYI, the 2.2 series is a long-term support release.  That's probably 
why Ubuntu and derivatives are still using it.  (Pop!_OS, an Ubuntu 
derivative, is still shipping with 2.2.20.  Just think, it could be 
worse...)  Ubuntu is pretty good about backporting security fixes to 
older versions of GnuPG, so we don't believe there's any reason to 
despair over the version they're shipping.


The 2.3 series is actually an experimental release.  As Werner said in 
April of 2021, "We are pleased to announce the availability of a new 
GnuPG release: version 2.3.0.  This release marks the start of public 
testing releases eventually leading to a new stable version 2.4."


The entire 2.3 branch is a public beta of what will ultimately become 
version 2.4.  I'm not going to tell you that you shouldn't encourage 
Ubuntu to adopt version 2.3 -- you do you, guy -- but I strongly 
recommend that before you do, you have a good answer to this question:


"Why should Ubuntu drop a long-term support release of GnuPG in favor of 
an experimental branch?"


The better your answer to that question, the better your chances of 
convincing Ubuntu.


Good luck!


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

Re: Current state and contact (various questions)

[Robert J. Hansen via Gnupg-users]

Forgive my terseness, on from my phone. The OP may find this message from the archives to be useful:https://lists.gnupg.org/pipermail/gnupg-users/2021-December/065639.htmlOn Feb 2, 2022 3:59 AM, Ingo Klöcker  wrote:On Mittwoch, 2. Februar 2022 08:30:56 CET B1773rm4n via Gnupg-users wrote:
> Hello,
> 
> this is my first post here. I'm an experienced Dev and FOSS contributor
> which worked quite some with gpg recently.
> 
> I got some questions:
> 
> 1. Who takes care for tasks like updating the website?
> For example https://gnupg.org/documentation/manpage.html would be easy
> to update. Someone could easily do it. Who is responsible? How can I do
> it myself?

The source code of the website is at
https://dev.gnupg.org/source/gnupg-doc/browse/master/web/

You can submit patches via dev.gnupg.org or per email to the gnupg-devel 
mailing list.

> 2. Difference of public key between gpg and Thunderbird. What do I have
> to do to yield the same public key file?
> I create a key pair in gpg and then import it to thunderbird. When using
> the "attach pub key to mail" option another pub key is used than I have
> saved in my gpg exported file

Don't bit-wise compare the result of key exports of different applications. 
There is more than one representation of the same public key. As long as all 
exports carry the same information, there is nothing to worry about.

Differences between armored public key blocks created via different ways was 
recently discussed on this mailing list. Check the archive.

> 3. I'm already asking the Ubuntu community but want to ask here too: gpg
> on Ubuntu jammy is 12 months old running 2.2.27. How is the current
> process / communication handled? Is there anything I can do to
> support/speed up this process?

That's entirely up to Ubuntu. Talk to the maintainer of the gpg package for 
Ubuntu.

> 4. Is there any IRC channel or other way of chat communication available
> for gpg?

See at bottom of https://gnupg.org/documentation/mailing-lists.html although 
the information about the channel at freenode.org is probably outdated. I 
haven't check, but I assume that the channel has moved off of freenode.org 
like many other FOSS channels.

Regards,
Ingo
___
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: First Amendment and Marines?

[Robert J. Hansen via Gnupg-users]

However, the opposite also occurs: some US companies appear to be
shocked when I, as a European without any ties to the US, claim I won't
comply to a DMCA request because we don't have such a law here.


Yes!  And when American companies are so foolish as to demand an EU 
citizen comply with a DMCA takedown notice, I encourage you to laugh at 
the silliness.  :)



___
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: 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: 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]

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: 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: Preventing public key upload to key-servers

[Robert J. Hansen via Gnupg-users]

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.


"Right to be forgotten" doesn't exist in the United States.  It's a 
violation of our First Amendment, which guarantees our right to 
communicate essentially anything that's true -- and even many things 
that are false! -- so long as we haven't signed a security clearance 
agreement.


We take this so seriously that when a major news magazine wanted to 
publish accurate details about the design of nuclear weapons, they were 
allowed to do so and no one went to jail for it.  (_The Progressive,_ 
November 1979, if you feel like looking it up in your library.  It was 
the first public release of the physics behind the H-bomb.)


If the United States is forbidden from stopping me from sharing facts 
about nuclear weapon design, it's also going to be forbidden from 
enforcing the GDPR's prohibition on my telling other people your email 
address.


The EU likes to claim the GDPR applies everywhere information on EU 
residents is kept.  So long as we've got United States Marines, y'all 
are going to have real problems convincing us of that.  :)


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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

Would you be able to suggest the version to use in "portable" mode?


GnuPG 1.4, but I'd honestly prefer to run a bootable Linux distro. 
Portable apps are a monstrous security hazard if they're used on 
computers beyond your control.  USB malware is a very real thing.


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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

I remember using a Windows-95-native PGP years ago that also used 
keyboard and mouse events to acquire entropy; presumably, there was not 
that much determinism, or every PGP key generated on Windows is likely 
to be weak.


Win95 still allowed direct access to underlying hardware.  In the 
XP-and-beyond world, direct hardware access virtually requires a driver.


If it reads /dev/random, you are fine; the Linux kernel collects very 
good entropy and GPG uses (and has always used) that source.  If it does 
something else, you probably have a problem, possibly a "Debian OpenSSL" 
problem...


/dev/random didn't exist in 1991-2 when PGP 2.6.3i was written.  At 
least on SGI IRIX, the standard way of getting random bytes was to open 
an audio device and sample the least significant bits of the input stream...



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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

Is this also used when generating symmetric keys? Or only used by secret
key generation? If the last is the case, then existing keys generated on
DOS (or Linux?) might be safe (apart from a possibly short key length).


Existing certificates would be unaffected, but since the CSPRNG is used 
for all sorts of things in signatures and encryption, it absolutely 
should not be used for anything more than reading old traffic.


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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

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.



the command-line build tools were still available). So is
the same (i.e., a problematic source of randomness when
generating the session key) likely to be the case
compiling/running 2.6.3iamulti06 under Linux today?


I wouldn't say "almost definitely" the way I do for DOS, but I'd still 
say I'd find it a disturbing possibility I'd want to investigate and 
rule out before I used PGP 2.6.3 in a UNIX environment.



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

Re: pgp263iamulti06

[Robert J. Hansen via Gnupg-users]

Are there known, documented security deficiencies in it?


The CSPRNG is almost certainly broken.

PGP 2.6.3 was a DOS program, which meant it could easily get direct 
access to hardware.  That meant it could use the uncertainty of the 
physical world as a key factor in the CSPRNG.


But ever since August 2001 and the release of Windows XP, DOS programs 
no longer get direct access to hardware.  Everything is abstracted away 
through the Windows Hardware Abstraction Layer (HAL) or other similar 
layers.


The core assumption of the PGP 2.6.3 CSPRNG ("we can use direct access 
to hardware to sample entropy from the physical world") no longer holds 
and hasn't been valid for more than twenty years.


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

Re: Short question regarding config

[Robert J. Hansen via Gnupg-users]

What's the difference between `|--personal-cipher-preferences' and 
`default-preference-list'?|


The former is your preferences for the traffic you generate.  The latter 
is your advertised list of preferences that are affixed to new 
certificates you generate.


E.g.: if you have p-c-p of CAMELLIA256, TWOFISH, AES256, you will use 
Camellia if your recipient supports it, Twofish if your recipient 
supports it but not Camellia, AES256 if your recipient supports it but 
neither Camellia nor Twofish, and if your recipient supports none of 
them you'll use 3DES (which all recipients support).


If your d-p-l reads AES256, CAMELLIA256, TWOFISH, then any new 
certificate you generate will have a note on it telling people "I can 
read traffic encrypted with any of those algorithms."


99% of users will never have any need to use these options.


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

Re: Side-channel attacks

[Robert J. Hansen via Gnupg-users]

Migrate? That data is in my mail archive. While it would be possible for
me to write a program to scan the mail file for pgp blockes, check which
pgp version is used, decrypt the data, re-encrypt it with a modern gpg
version and replace that textblock, it would still lose information
about dates and signatures.


No, and that entire line of argument is disingenuous.

You use PGP 2.6 to decrypt/verify each message.  You verify the 
signature to whatever degree you feel is necessary, and write an 
attestation: "On January 21 at 12:56am I successfully decrypted this 
message with hash value X and verified the PGP 2.6 signature as 
belonging to Y.  I then re-encrypted it to myself, and that ciphertext 
has hash value Z."  Sign the attestation.  You re-encrypt the plaintext 
to your current OpenPGP certificate.  You attach (via PGP/MIME) the PGP 
2.6 ciphertext and your attestation.


Presto.  You now have encrypted text you can use with GnuPG 2.3.  If you 
need to verify the document you can verify the signature on the 
attestation.  If the signature is good, clearly no one has tampered with 
your declaration.  To do a more rigorous verification you can check the 
hash values of the ciphertexts.  To do a most-rigorous verification you 
can run PGP 2.6.3 on the original attachment.


We've known how to do this for at least a quarter-century, Johan.

25 years.

Twenty.  Five.  *Years*.

Now, it's true that hardly anyone does this, and there's not exactly 
much demand for tools that do this.  That is, I'm convinced, because in 
the real world, there's nobody who needs to do this.


I repeat: if you really needed this functionality, you've had a 
quarter-century to do something about it, a quarter-century where we've 
known what to do about it.  If you're not migrating, that's on you.


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

Re: Side-channel attacks

[Robert J. Hansen via Gnupg-users]

Lucky for me I never use that version, as I never respected the
copyright of the RSA and IDEA algorithms (questionable in Europe anyway).


Patents, not copyrights.


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

Re: Side-channel attacks

[Robert J. Hansen via Gnupg-users]

1.4 should be able to decrypt all 2.6 generated data.


Not from the Disastry builds, which extended 2.6 to support newer 
algorithms.



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

Re: Side-channel attacks

[Robert J. Hansen via Gnupg-users]

Well, a bit more respect for backwards compatibility would help a lot
by that. Now I'm forced to keep an 1.4 and pgp 2.6 version installed
just to be able to read all my old data. Some people just refuse to
update to versions that routinely break backwards compatibility.


You've had literally 27 years to migrate your data.  I have zero sympathy.


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

Side-channel attacks

[Robert J. Hansen via Gnupg-users]

On this mailing list we sometimes see requests for help from people 
running dangerously antique versions of GnuPG.  Wasn't all that long ago 
I was asked for help with something in the 1.2 series (!!).  Without 
exception, our first response is usually "for the love of God, upgrade!"


They rarely do.  It's worked fine for them for a decade or more, and 
they're not going to change...


On another mailing list I shared the story of how an AES256-encrypted 
drive was bypassed by law-enforcement and the plaintext recovered.  The 
subject was using PGPdisk 6.0.2 on a Windows XP laptop, hibernated it, 
and the AES key was written to disk where a forensic examiner later 
picked it up.


This didn't happen because of bugs in either PGPdisk or Windows XP: it 
was entirely due to the user ignoring Network Associates when they 
warned him, "PGPdisk 6.0.2 was never designed for Windows XP and you 
might be putting your data at risk by using it."


Interested in the full story?  The write-up is below.

Not interested?  Skip it, but please remember to upgrade your GnuPG 
installation at least every few years.  :)


=
=
=

> Technically, your team didn't break (or crack) AES256, it
> merely spotted the key (no small feat for sure!)

(Long and nerdy.  All of this history is off the top of my head, no 
notes.  I may be in error in some places.)


Depends on how one considers side channel attacks!  It's true that we 
didn't successfully cryptanalyze the AES256 cipher, but we mounted a 
successful attack on a *correctly-implemented* AES256 system.  (That 
"correctly-implemented" thing matters.)


PGPdisk 6.5.8-CKT is a misnomer.  Network Associates, Inc., stopped 
publishing PGPdisk source code after version 6.0.2.  When NAI stopped 
publishing PGP source code in late 2000, a group of hacktivists, 
"Cyber-Knights Templar", led by a guy named Imad Faiad, took the last 
published source code for 6.5.8 and used it to build their own version, 
6.5.8-CKT.  When people asked them to also include PGPdisk, Faiad took 
the 6.0.2 PGPdisk source code, built PGPdisk 6.0.2, and included it in 
the 6.5.8-CKT package.


Why does this matter?

'01 was a very interesting year for home computing.  That was the year 
Windows XP was released to home users.  Prior home editions of Windows 
were fundamentally MS-DOS... MS-DOS pushed as far as it could humanly 
go, sure, but still MS-DOS.


There are two big mistakes people make when discussing Windows 95: one 
is to think it was a graphical version of MS-DOS (it wasn't, it had 
genuine hard breaks from its MS-DOS heritage), and the other is to think 
it wasn't (it was, as evidenced by how it had to launch a new MS-DOS 
instance, at least briefly, for every program it ran, including native 
32-bit Windows ones).


Part of it being MS-DOS meant that pretty much every bit of hardware had 
its own specialized device driver.  Yes, we had laptops in 1995-2001 
that could hibernate when you closed the lid -- but only if you had a 
specialized device driver for your laptop (to make Windows aware of what 
to do), and good luck with application support for hibernation. 
Application developers couldn't be expected to support every device 
driver directly!


This meant that PGPdisk 6.0.2 was *correctly written* for that era.  It 
wasn't aware of hibernation events because, well, pretty much nothing 
was except Windows, and even then only with custom drivers loaded.


Then in August of 2001, Microsoft switched the consumer version of 
Windows from MS-DOS to Windows NT.  (Yes, every version of Windows from 
Windows 2000 onwards is actually Windows NT.  And Windows NT is 
basically OpenVMS with the serial numbers filed off.  Microsoft hired 
Dave Cutler to design "Windows New Technology", and Cutler was the chief 
architect of OpenVMS.  Windows NT is basically a next-generation 
OpenVMS, the same way MacOS is a next-generation NeXTSTEP.)


Anyway.  We never saw *good* hibernation support in consumer grade 
hardware until Windows XP... released August of 2001.


(Kinda true.  Microsoft actually finally found a hackish way to do it 
tolerably well in Windows Me, in 1999.  But since all of about four 
people worldwide bought Windows Me, we can discount this.  Windows 2000 
introduced good hibernation support, but that was a 
business-and-enterprise Windows version.  Windows XP was when it became 
common in consumer-grade Windows.)


Whew.  I'm getting somewhere, I promise.

So, post-XP, Microsoft had a standard, uniform way to do hibernation. 
The user signals a hibernation event, and Windows in turn blasts a 
message to each process saying "WE'RE CLOSING UP SHOP, WIPE ALL YOUR 
SENSITIVE STUFF."


But that message wasn't standardized until Windows 2000!

PGPdisk 6.0.2 was released in ... '98, I think?  There's absolutely no 
way PGPdisk could have known about it.  And so, when it received that 
notification, it does what every application does when it gets an 
advisory message it doesn't know what 

Re: one ecc key-pair for both encryption and signature?

[Robert J. Hansen via Gnupg-users]

Likewise, Edwards DSA can be tortured into becoming a Curve25519 key.
But once you do that, *you're no longer using Edwards DSA*.


Can you be more specific why this is a problem?


I apologize in advance for sounding grumpy (I am, it's been an annoying 
day so far) and condescending (which I'm trying not to be, but...).


=

I used to volunteer at my old elementary school.  Due to budget cutbacks 
they had to eliminate their math program for gifted students, so I came 
in once every few weeks to talk to kids who should've been in gifted 
mathematics and try to keep their inspiration alive.  I loved these 
kids: they were the best.


One of my standard questions to them, early on each year, was "are 
addition and subtraction the same thing, just looked at differently?" 
And that's a great question to ask kids -- heck, even some adults! -- 
because it forces us to ask what it means to be the same thing.


Ultimately, we start talking about not just what addition and 
subtraction do, but what the *nature* of them are.  And ultimately we 
discover that addition and subtraction are two different things.  The 
nature of addition is that it's both commutative (A + B) and associative 
(A + (B + C) = (A + B) + C).  But subtraction is neither commutative nor 
associative.


And that means that although each addition problem can be converted into 
a subtraction problem, and vice-versa, addition and subtraction are not 
the same, not at all.  They're not "the same thing just looked at 
differently".  The existence of a way to make one act like the other 
does not mean the same inputs can be used for both.


=

With me on the elementary-school algorithm theory?  Please re-read that 
a few times, because I'm about to give *exactly the same lesson* except 
now I'm going to make it unnecessarily harder by talking about DSA and 
Elgamal keys.


=

A public key is not just a large prime number.  It's an entire 
mathematical structure, of which a large prime number (or point on an 
elliptic curve, or what-have-you) is only one of many different components.


For a DSA key you have to choose a hash algorithm H, key length L, a 
modulus N such that N < L and N <= len(H), an N-bit prime q, an L-bit 
prime p such that p-1 is a multiple of q, an integer randomly 
distributed among {2, p-2}, and finally, let g be h^((p-1)/q).  Once 
you've done all of this, write down the triplet (p, q, g): these are 
your DSA parameters.  Now choose an integer randomly distributed among 
{1, q-1} and compute y = g^x modulo p.  Your private key is x, your 
public key is y.


Now you're saying, "why can't I use the same x and y for Elgamal?  I 
mean, they're both computing discrete logs over a finite field..."


An Elgamal public key is closely related but different.  For Elgamal, 
you need a cyclic group G of order q with generator g, an integer x 
randomly selected from {1, q-1}, and h = g^x.  Your public key is (G, q, 
g, h) and your private key is x.


You can see some similarities there.  In both algorithms you need to 
select some random numbers, and you could view y = g^x modulo p as being 
a special case of h = g^x, and if you torture things enough you can 
*probably* create a one-to-one mapping between DSA signature keys and 
Elgamal encryption keys, what computer scientists call an isomorphism...


... *but that's not going to let you use the same key for both, because 
they're different algorithms*.


Or, as I said:

>> Likewise, Edwards DSA can be tortured into becoming a Curve25519 key.
>> But once you do that, *you're no longer using Edwards DSA*.

There is no possible universe in which "your public key is y, and oh, 
hey, post these parameters" can be used as "your public key is these 
four numbers".  The fact one can be converted into the other via some 
kind of complex number-theoretic mapping does not mean they can ever be 
made directly interchangeable in algorithms that depend on keys having 
specific mathematical structures.





(Disclaimers: I'm not a cryptographer.  I am at best a cryptographic 
engineer.  There are other people on this list far better suited than I 
to talk about the deeper mathematics of cryptography.  Thanks to 
Wikipedia for having easily-available terse descriptions of these 
algorithms. Standard Wikipedia disclaimers apply: if you need 
authoritative descriptions look elsewhere, like the _Handbook of Applied 
Cryptography_.)


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

Re: GPG key generated on Windows...

[Robert J. Hansen via Gnupg-users]

5) Importing the key on Linux does not generate any warning or error. And I
can also properly use the keypair generated on Windows to encrypt, decrypt,
sign and verify files between Linux clients without problem. It's just
encrypting on Windows and decrypting on Linux with a keypair generated on a
Windows client.


GnuPG has made some long-overdue changes between 2.2 and 2.3.  2.2 
defaults to "let's generate traffic like we've done since 2000", and 2.3 
defaults to "let's use some newer and better cryptography".  It's 
possible to create traffic in 2.3 that cannot be read in 2.2.


Adding "rfc4880" to your %APPDATA%\gnupg\gpg.conf file on your Windows 
box might help: this forces GnuPG to use the older style of cryptography.


Let us know if this helps!


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

Re: one ecc key-pair for both encryption and signature?

[Robert J. Hansen via Gnupg-users]

There is anequivalence given (two functions) in the Ed25519 wikipedia page,
but I don't know if this allows the same curve used in both algorithms.


Yes, in the same way that if you torture a DSA key long enough you can 
get the Elgamal encryption algorithm out of it.  But once you do that, 
*you're no longer using DSA*.


Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. 
But once you do that, *you're no longer using Edwards DSA*.



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

Re: one ecc key-pair for both encryption and signature?

[Robert J. Hansen via Gnupg-users]

I know that "ed25519" and "cv25519" are different algorithms,
but from my limited understanding the same key-pair should be
usable for both encrypting and signing in theory?


Ed25519 is (effectively) a Schnorr signature done over an Edwards curve. 
 Schnorr signatures have really no capability of being used for 
encryption, unless you want to do it just a few bytes at a time.


Schnorr signatures were also used as the basis for DSA during the 
cryptowars of the 1990s.  The US government was very worried that any 
federal crypto standard not be able to be used for encryption 
(seriously): they wanted to give American citizens and businesses a 
strong signature algorithm, but not give us a strong encryption 
algorithm.  Hence, Schnorr was adapted into becoming the Digital 
Signature Algorithm...


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

Re: [Announce] A New Future for GnuPG

[Robert J. Hansen via Gnupg-users]

I did spend about six months doing a clean-room implementation of
RFC2440 in PHP3.  It was a vile experience and one I don't recommend.


I am simultaneously shocked, impressed, and disgusted. ;-)


I rarely talk about that job because it's sort of like saying you made a 
healthy and tasty meal out of raw sewage.  Even if it's true, you still, 
uh... yeah.  Let's just say that although few people could do it, those 
of us who have actually done it are filled with shame at our 
'accomplishment'.  :)


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

Re: [Announce] A New Future for GnuPG

[Robert J. Hansen via Gnupg-users]

Werner, this is amazing news.  Thank you for sharing it!

For the list: as you may remember, each Christmas I run a fundraiser for 
GnuPG.  You pledge $X and I match it, that sort of thing.  I didn't do 
one this year because Werner contacted me earlier asking me not to, 
saying he would soon have news that would put GnuPG on much more solid 
financial footing.  I'm happy the news is finally ready for sharing.  :)


I first started using GnuPG in '99, when I was twenty-four years old and 
hired by a major telecommunications firm to secure their billing 
back-end.  Although the full scope of that project isn't relevant here, 
I did spend about six months doing a clean-room implementation of 
RFC2440 in PHP3.  It was a vile experience and one I don't recommend. 
But GnuPG was about to hit 1.0, and I leaned on the 0.99 and 1.0 code 
very heavily to make sense of the RFC2440 spec.


I continued to use it throughout the years since, and once the NDA with 
the telecommunications firm expired joined the mailing list.  I've been 
here ever since.  I hope to be here for some years to come.  It's been a 
pretty good 23 years so far!


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

Re: detached signature, "can't hash datafile: No data"

[Robert J. Hansen via Gnupg-users]

> I would've thought that a clearsign signature preserves the data 
above the pgp signature, in plaintext.  Isn't the plaintext above the 
signature the original data?


In that case, it is.  I spoke inartfully: I meant to say that detached 
signatures can be done in either a binary format or in ASCII-printable.



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

Re: detached signature, "can't hash datafile: No data"

[Robert J. Hansen via Gnupg-users]

Shouldn't I be able to verify the signature independently?


Why?

A signature is a piece of data that attests another piece of data is 
unchanged.  If it doesn't have a second piece of data to compare to, all 
it can say is "I have a good digital signature that attests to a hash 
value of XYZ for some piece of data, but, uh ... where's the data?"


Detached signatures (clearsign signatures being one kind of them) do not 
include the original data.  You can sign gigabytes of data and the 
detached signature will still be only a few hundred bytes in size, 
because the original data isn't there.




OpenPGP_0x1DCBDC01B44427C7.asc
Description: OpenPGP public key


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

Re: fingerprint associated public key does not match displayed public key

[Robert J. Hansen via Gnupg-users]

seems as though my entry into this realm was clearly... bad.  I wanted
to learn the system without using separate encryption software like
kleopatra.  I wanted to know how to do it with just gpg and any email
provider.  It's difficult, and I have a lot to learn.


Don't do that.  Seriously.  This is like saying "I want to learn how to 
farm like my grandparents did!"  Farming is hard enough: voluntarily 
doing without, you know, *electricity* is just crazy.  (In the United 
States, many farms were without electricity until the 1940s!)


These easy-to-use tools exist for a reason: to make GnuPG easy to use. 
If you insist on doing things the hard way you have only yourself to 
blame.  First learn how to use GnuPG, and then figure out how to use 
GnuPG like you would if it was 1992 after you've got your basic skills down.



and... I was hoping that, since I have your email, key ID, and fingerprint ;)
I could write an encrypted message to your sixdemonbag email.  I'd
completely understand if you'd rather not.  I just have now found
myself luring friends and relatives into learning this with me and
exchanging encrypted emails and... it's not going well.


You may want to check out a mailing list like PGPNET, which exists 
specifically to give people experience in sending/receiving encrypted 
mail. :)


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

Re: fingerprint associated public key does not match displayed public key

[Robert J. Hansen via Gnupg-users]

What other keys would it hold?


Behold:

pub   ed25519/1E7A94D4E87F91D5 2021-02-22 [SC]
  7D8EC4B85B6FEDD6C10D3C791E7A94D4E87F91D5
uid [ultimate] Robert J. Hansen 
uid [ultimate] Robert J. Hansen 
sub   cv25519/7D6CCDB66CA1202F 2021-02-22 [E]


My public certificate has two keys: an Edwards-25519 signing key and a 
Curve-25519 encryption key.


Back in the '90s, certificates almost always held a single key that was 
used for both encryption and signing.  Then we realized, "if the courts 
force us to give our decryption key to the cops so they can read our 
traffic, we're also giving them the ability to impersonate us."  Since 
then, virtually every OpenPGP certificate has had at least two keys: one 
for signing and one for encryption.


There are cases where three or more keys are appropriate, but they're 
kind of outside the scope of the current discussion.



Sure it does.  I did that no more than twenty minutes ago myself.


So I typed the gpg --import > certificate.txt command and it says "no
such file or directory: certificate.txt" (certificate has a different
name of course).


Did you notice the command is "gpg --import < certificate.txt"?


I placed the file in my .gnupg hidden folder.


Then you'd need to do "gpg --import < ~/.gnupg/certificate.txt".  If 
certificate.txt isn't in your current directory, you need to tell Linux 
where to look for it.



Here is really the root of my problem.  As you probably know, I'm not
using a Web Key Service/Directory enabled email provider, so if I were
to get an encrypted message intended for me, I'd have to copy the
encryption text, paste it into txt file, then import/decrypt it like
that with: gpg --decrypt ~/Desktop/encryptedfile.txt | perl
-MMIME::QuotedPrint -0777 -nle 'print decode_qp($_)'


That's shockingly bad.

Try using an email client with OpenPGP support built-in.  On Linux the 
two major choices are Evolution and Thunderbird.



That's a command I found online from a source that I've been using for
learning pgp.


Please stop using that resource.  As mentioned above, it's shockingly bad.

As the FAQ says, "The good news is the internet is a treasure trove of 
information. The bad news is that the internet is a festering sewer of 
misinformation, conspiracy theories, and half-informed speculations all 
masquerading as informed commentary."


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

Re: fingerprint associated public key does not match displayed public key

[Robert J. Hansen via Gnupg-users]

The document snapshot analogy really helps.


I'm glad it's helped!


No, and I'm going to strongly encourage you to stop asking

implementation questions.

I think I'll take that advice.


When you think you're ready, we'll be here to answer your implementation 
questions.  It would break my heart if you thought you should never ask 
them -- I just, only, think that diving into implementation details is 
almost always a bad idea for new users.


If you want to teach someone poetry you start by showing them the witty 
banter and playful puns in Shakespeare, and encourage them to laugh and 
enjoy the show.  Learning about iambic pentameter can wait.  :)



I'm getting the picture now.  The pgp key block is really the
certificate.  The certificate holds the key and metadata.


Key(s): a certificate holds at least one, but usually more than one. 
Beyond that minor detail you've got it perfect.



gpg --import < certificate.asc


So, when dealing with a displayed certificate (what I was calling a
pgp public key block), the only method I thought of was copying and
pasting it onto a txt file.  But the import command doesn't work with
txt.


Sure it does.  I did that no more than twenty minutes ago myself.

How were you trying to do this?

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

Re: fingerprint associated public key does not match displayed public key

[Robert J. Hansen via Gnupg-users]

That key block did not match the one on his profile. That’s what
confused me. But I’m learning (from you guys) that the key blocks
don’t necessarily have to match.  So I can assume that:


More accurately, they're very unlikely to match.  The version on his 
site may lack some signatures or user IDs present on the keyserver copy, 
or vice-versa.  Think of them as two different snapshots of the same 
document at different points in time, as various minor edits are made to 
it.  But the important bits, the stuff you care about, will be 
consistent through revisions so long as the fingerprint remains unchanged.



- the fingerprint is specific for the secret key component of the
generated key pair and does not change.


No, and I'm going to strongly encourage you to stop asking 
implementation questions.  You're not ready for them.  For now, learn 
how to use the system, and only then start paying attention to the fine 
detail of how the system is implemented.


But if you insist, see section 12.2 of RFC4880.  "A V4 fingerprint is 
the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet 
packet length, followed by the entire Public-Key packet starting with 
the version field.  The Key ID is the low-order 64 bits of the fingerprint."



- the pgp public key is, in a way, fluid. It can take many different
forms but encrypts specifically for the matching secret key only. The
same public key can have different key blocks.


No.  This will probably become easier to understand if we use the 
correct language.  *Keys* are not fluid.  *Certificates* can be.  What 
you're calling a "key block" is a certificate, not a key.  A certificate 
includes cryptographic keys and metadata about those keys.  The keys 
generally don't change (although I can think of pathological cases where 
they do).  The metadata about those keys can change a lot.


Most of the data in a certificate is metadata.


- I could’ve used the keyserver-obtained public key (retrieved via the
fingerprint), or I could’ve used the displayed public key that was
given in armor text form.  They are one and the same, even though
their revealed text is different.


You could have used it and the odds are quite good it wouldn't have 
mattered in the slightest.



When you want to give someone your public key, do you normally just
give your email, fingerprint, key ID, or the armor form key block?


I use WKS.


is there a command i could've used to directly import the key using
the displayed key block?  I've tried some different ones I found in
various places but nothing worked.


gpg --import < certificate.asc

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

Re: fingerprint associated public key does not match displayed public key

[Robert J. Hansen via Gnupg-users]

when i compared the imported pgp public key block (which I obtained
using the import command and the provided fingerprint) to the
displated pgp public key block, they didn't match

shouldn't they match?


No.

The key block is not a human-readable format.  It's a binary format 
that's meant to be read by computers.


Imagine a word processing document.  You open up a blank document and 
type "Hello, World!".  You save that as document-1.  Then you think 
about it, erase your text, write something else, delete that, too, and 
after some more hemming and hawing you go back to "Hello, World!".  You 
save this as document-2.


Now open up document-1 and document-2 in a hex editor.  Despite the fact 
they have exactly the same *human-meaningful* information, the two 
documents will look different to a computer.  Things like a timestamp 
for when it was last edited, things like a revision history, things 
like... etc.


For all human purposes, document-1 and document-2 are the same.  But 
they're different on disk, and that's okay.


The exact same thing happens with OpenPGP certificates.  When you import 
the certificate, GnuPG starts tracking other information -- the same way 
the word processor does.  But that doesn't mean the certificate is 
*different*, really, not in any way you care about.


Hope this helps!

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

Re: Continuing 2.3 weirdness

[Robert J. Hansen via Gnupg-users]

I make different observations (using self-compiled gpg installed to /opt/
gnupg/master with a non-standard GNUPGHOME):


It turns out the source of the trouble was systemd, which was starting 
gpg-agent on demand, and was forcing it to use /usr/bin/gpg-agent. 
Setting a user override file fixed the behavior.


Really annoying to hunt down, though.  My thanks to Phil Pennock for 
helping me debug this.


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

Continuing 2.3 weirdness

[Robert J. Hansen via Gnupg-users]

Turns out the problem was keyboxd was waiting for a lock.  Unfortunately 
I wasn't able to find the lock: so, after making a backup, I decided to 
resort to harsh measures: I nuked my .gnupg directory.  Now GnuPG is 
getting a little further along, but it's still not working properly.


Let's start by nuking the .gnupg directory and shutting down all GnuPG 
daemons:


rjh@ripley:~$ rm -rf .gnupg
rjh@ripley:~$ /usr/local/bin/gpgconf --kill all
rjh@ripley:~$ ps ax|grep [g]pg-agent

No output: gpg-agent is gone, and I'm assuming other GnuPG daemons are, 
too.  Next, verify we have a /usr/local/bin/gpg-agent and that it points 
to the correct GnuPG helper programs:


rjh@ripley:~$ ls -lh /usr/local/bin/gpg-agent
-rwxr-xr-x 1 root root 2.3M Dec  5 20:19 /usr/local/bin/gpg-agent
rjh@ripley:~$ /usr/local/bin/gpgconf --check-programs
gpg:OpenPGP:/usr/local/bin/gpg:1:1:
gpgsm:S/MIME:/usr/local/bin/gpgsm:1:1:
keyboxd:Public Keys:/usr/local/libexec/keyboxd:1:1:
gpg-agent:Private Keys:/usr/local/bin/gpg-agent:1:1:
scdaemon:Smartcards:/usr/local/libexec/scdaemon:1:1:
dirmngr:Network:/usr/local/bin/dirmngr:1:1:
pinentry:Passphrase Entry:/usr/local/bin/pinentry:1:1:

All looks good.  Let's launch gpg-agent.

rjh@ripley:~$ /usr/local/bin/gpgconf --launch gpg-agent
rjh@ripley:~$ ps ax|grep [g]pg-agent
 229366 ?SLs0:00 /usr/bin/gpg-agent --supervised

Wait, what?  Why was /usr/bin/gpg-agent (system-provided, version 2.2) 
used instead of 2.3?


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

Re: 2.3 --list-keys weirdness

[Robert J. Hansen via Gnupg-users]

"gpgconf --kill all" solved my problem, but I'd still advise y'all to 
look into where it got wedged and why -- this was an incredibly annoying 
problem to solve, and the total lack of debugging output elevated it to 
tremendously frustrating.


I'm such an idiot, I forgot I was sshed into another machine.

Nope, problem still exists, and gpgconf hangs just like everything else. 
 GnuPG is still unusable.


=

rjh@ripley:~$ gdb --args gpgconf --kill all

[boilerplate stripped]

(gdb) run
Starting program: /usr/local/bin/gpgconf --kill all
[Detaching after fork from child process 101626]
[Detaching after fork from child process 101629]
[Detaching after fork from child process 101632]
[Detaching after fork from child process 101634]
^C
Program received signal SIGINT, Interrupt.
0x77d2b83a in __GI___wait4 (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffdd24, options=options@entry=0,
usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
30  ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory.
(gdb) backtrace
#0  0x77d2b83a in __GI___wait4 (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffdd24, options=options@entry=0,
usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x77d2b7fb in __GI___waitpid (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffdd24, options=options@entry=0)
at waitpid.c:38
#2  0x55570610 in gnupg_wait_process (
pgmname=pgmname@entry=0x55589eb0 
"/usr/local/bin/gpg-connect-agent",

pid=101634, hang=hang@entry=1, r_exitcode=r_exitcode@entry=0x0)
at exechelp-posix.c:672
#3  0xe0a3 in keyboxd_runtime_change (killflag=1)
at gpgconf-comp.c:919
#4  0xd5e4 in do_runtime_change (component=3,
killflag=killflag@entry=1) at gpgconf-comp.c:1018
#5  0xe5de in gc_component_kill (component=)
at gpgconf-comp.c:1027
#6  0xbcbf in main (argc=, argv=)
at gpgconf.c:793

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

Re: 2.3 --list-keys weirdness

[Robert J. Hansen via Gnupg-users]

Try attaching gdb to see where it hangs.


(gdb) run
Starting program: /usr/local/bin/gpg --list-keys
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 41865]
^C


"gpgconf --kill all" solved my problem, but I'd still advise y'all to 
look into where it got wedged and why -- this was an incredibly annoying 
problem to solve, and the total lack of debugging output elevated it to 
tremendously frustrating.


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

Re: 2.3 --list-keys weirdness

[Robert J. Hansen via Gnupg-users]

Which version exactly are you using?


2.3.3.


Try attaching gdb to see where it hangs.


(gdb) run
Starting program: /usr/local/bin/gpg --list-keys
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 41865]
^C
Program received signal SIGINT, Interrupt.
0x77c70e87 in __libc_recvmsg (fd=fd@entry=4,
msg=msg@entry=0x7fffd490, flags=flags@entry=0)
at ../sysdeps/unix/sysv/linux/recvmsg.c:28
28  ../sysdeps/unix/sysv/linux/recvmsg.c: No such file or directory.
(gdb) backtrace
#0  0x77c70e87 in __libc_recvmsg (fd=fd@entry=4,
msg=msg@entry=0x7fffd490, flags=flags@entry=0)
at ../sysdeps/unix/sysv/linux/recvmsg.c:28
#1  0x77c96437 in __assuan_recvmsg (ctx=ctx@entry=0x55681ec0,
fd=fd@entry=4, msg=msg@entry=0x7fffd490, flags=flags@entry=0)
at system-posix.c:133
#2  0x5556eacf in _assuan_npth_recvmsg (ctx=0x55681ec0, fd=4,
msg=0x7fffd490, flags=0) at gpg.c:1037
#3  0x77c94923 in uds_reader (ctx=0x55681ec0, buf=out>,

buflen=) at assuan-uds.c:113
#4  0x77c8f23f in readline (ctx=ctx@entry=0x55681ec0,
buf=buf@entry=0x55682010 "", buflen=buflen@entry=1002,
r_nread=r_nread@entry=0x7fffd56c, r_eof=r_eof@entry=0x5568200c)
at assuan-buffer.c:79
#5  0x77c8f419 in _assuan_read_line (ctx=ctx@entry=0x55681ec0)
at assuan-buffer.c:151
#6  0x77c8ea50 in assuan_client_read_response (
ctx=ctx@entry=0x55681ec0, line_r=line_r@entry=0x7fffd660,
linelen_r=linelen_r@entry=0x7fffd65c) at client.c:87
#7  0x77c8edbb in _assuan_read_from_server (
ctx=ctx@entry=0x55681ec0, response=response@entry=0x7fffd6b0,
off=off@entry=0x7fffd6b4, convey_comments=convey_comments@entry=0)
at client.c:209
#8  0x77c93f07 in _assuan_connect_finalize (
ctx=ctx@entry=0x55681ec0, fd=fd@entry=4, flags=flags@entry=1)
at assuan-socket-connect.c:125
#9  0x77c942e8 in assuan_socket_connect 
(ctx=ctx@entry=0x55681ec0,

name=,
name@entry=0x55686de0 "/run/user/1000/gnupg/S.keyboxd",
server_pid=server_pid@entry=0, flags=flags@entry=1)
at assuan-socket-connect.c:343
#10 0x5562004b in wait_for_sock (secs=5,
did_success_msg=, ctx=0x55681ec0, verbose=0,
connect_flags=1, sockname=0x55686de0 
"/run/user/1000/gnupg/S.keyboxd",

module_name_id=13) at asshelp.c:358
#11 start_new_service (r_ctx=r_ctx@entry=0x7fffd930,
module_name_id=module_name_id@entry=13,
errsource=errsource@entry=GPG_ERR_SOURCE_GPG,
program_name=, opt_lc_ctype=opt_lc_ctype@entry=0x0,
opt_lc_messages=opt_lc_messages@entry=0x0, session_env=0x0, 
autostart=1,

verbose=0, debug=0, status_cb=0x0, status_cb_arg=0x55684b70)
at asshelp.c:548
#12 0x5562025c in start_new_keyboxd 
(r_ctx=r_ctx@entry=0x7fffd930,

errsource=errsource@entry=GPG_ERR_SOURCE_GPG,
keyboxd_program=, autostart=,
verbose=, debug=, status_cb=0x0,
status_cb_arg=0x55684b70) at asshelp.c:635
#13 0x5558a0ba in create_new_context (r_ctx=0x556850d8,
ctrl=0x55684b70) at call-keyboxd.c:143
#14 open_context (r_kbl=0x55684c70, ctrl=0x55684b70)
at call-keyboxd.c:219
#15 keydb_new (ctrl=ctrl@entry=0x55684b70) at call-keyboxd.c:277
#16 0x555b28fb in list_all (ctrl=ctrl@entry=0x55684b70,
secret=secret@entry=0, mark_secret=0) at keylist.c:527
--Type  for more, q to quit, c to continue without paging--c
#17 0x555b2f34 in public_key_list 
(ctrl=ctrl@entry=0x55684b70, list=0x0, locate_mode=0, no_local=0) at 
keylist.c:146
#18 0x5556acf2 in main (argc=, argv=out>) at gpg.c:4638



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

2.3 --list-keys weirdness

[Robert J. Hansen via Gnupg-users]

rjh@ripley:~$ gpg - --list-keys
gpg: using character set 'utf-8'
gpg: Note: RFC4880bis features are enabled.
gpg: key 1DCBDC01B44427C7: accepted as trusted key
gpg: key 1E7A94D4E87F91D5: accepted as trusted key
gpg: key A3C418D1C6F3453A: accepted as trusted key


... No output is ever produced: it just hangs without ever giving a hint 
as to what's going on, what's wrong, or how to fix it.  This is not the 
behavior I expect from a high-verbosity output.  What's going on here?


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

Re: User id's without person's name, only email

[Robert J. Hansen via Gnupg-users]

Mapping a "Real Name" to an email address is a conceptually different
thing from mapping an email address to a public key.


Except that should we be mapping keys to email addresses in the first 
place?


When we sign a certificate we make an assertion that this cryptographic 
material is controlled by this entity.  I control the cryptographic 
material associated with certificate 0x1DCBDC01B44427C7.  
r...@sixdemonbag.org controls nothing -- it's just one of several places 
I pick up mail.


I have long considered mapping keys to email addresses to be a 
fundamental flaw.  It obscures exactly what it is we're trying to 
assert: that cryptographic material is controlled by *people*.


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

Re: Using gpg to add digital signature to a linux executable

[Robert J. Hansen via Gnupg-users]

Why not do a detached signature using e.g. gpg -sb --output file.sig
file? Then, someone can run gpg --verify file.sig file to ensure that
the signature is valid.


(a) because the OP specifically said he was looking for integrated 
signatures, and


(b) detached signatures have a way of getting lost, not distributed with 
the executables, and so on.





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

Re: v2.3 of gnupg for automation?

[Robert J. Hansen via Gnupg-users]

We’ve been using v1.4 of gnupg because I read in the documentation
and user comments and in my testing, that v2.X couldn’t be used in
software automation workflows.


This might have been true several years ago, but it isn't true today.


there was a feature (that seemed intentional) that the passphrase had
to be entered manually in a popup window in v2.X.


That's true, and is correct.  If you're passing a passphrase via the
command line, that passphrase becomes visible to anyone with the
privileges to get a list of processes and arguments.  At that point the
passphrase really isn't providing much in the way of security.


And that even when that was supposedly not required, it still
happened occasionally to users, that their automation couldn’t
process the file because gnupg v2.X required the manual input.


I'm unaware of any instance of this being true.  I am aware of *many*
instances of people discovering they did, in fact, have a passphrase on
their key after swearing up and down they didn't.



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

Re: Using gpg to add digital signature to a linux executable

[Robert J. Hansen via Gnupg-users]

all is well and good. At least, on Windows. But what about linux?


As a general rule, Windows signs executables more than it signs 
packages; Linux signs packages more than it signs executables.  The best 
practice seems to be to use GnuPG to attach a digital signature to an 
RPM or DEB (or Snap or Flatpak or what-have-you), rather than to sign 
the executables directly.


doing it. So, much as I detest Windows, this seems to be one area in 
which Windows is slightly ahead.


"Ahead" might be putting it a little strongly.  The two operating 
systems are different and have different approaches to supply chain 
security.  :)





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

Re: how to add a passphrase to a keypair

[Robert J. Hansen via Gnupg-users]

gpg -k and gpg -K both show my main key.  I compiled a copy of gpg1 (not 
installed to the system) to try to use locally, since it doesn't enforce 
the use of a passphrase for the secret key.  Unfortunately, without 
secring.gpg, it doesn't see the secret key at all.


I haven't tried this, but it might be exactly what you want to do:

/path/to/gpg2 --export-secret-keys 0xMY_KEY_ID > secret.gpg
/path/to/gpg1 --import secret.gpg

When you import the secret key, secring.gpg will be recreated, and the 
corresponding public key will be automatically imported into 
pubring.gpg.  (A copy of the public key is embedded into each secret key.)


At that point you'll have the necessary pubring.gpg/secring.gpg files, 
and should be able to change the passphrase at a GPG1 command line.



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

Re: Call me crazy, but ...

[Robert J. Hansen via Gnupg-users]

Is 'Стефан Васильев ' the same person that
was ban from this very list a fiew month back?


No, because no one was ever banned.  One user, also named Stefan, was
set to moderation (his messages had to be approved by an admin before
appearing on list), but this was only for two weeks, and he was never
banned.




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

Re: GPG : "No secret key found" error

[Robert J. Hansen via Gnupg-users]

I am trying to write in plain text mode so hopefully you won't be
seeing it in HTML.


Success!  Thank you.


Can you please suggest to me the steps that I should follow to
redesign my solution, considering the password security?


I already have, twice.

For the third time: remove the passphrase from your private key, and 
make sure the location where you're storing your private key is safe.


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

Re: GPG : "No secret key found" error

[Robert J. Hansen via Gnupg-users]

I am writing this email to you in plain text... I am surprised how is it 
coming to as HTML.


As I don't use GMail, I can't help you.  You'll need to ask Google. 
Your message comes through as having both plaintext and HTML parts. 
This, for instance, is part of the source of your email:


Content-Type: text/html; charset="UTF-8"

Content-Transfer-Encoding: quoted-printable



I am writing this email to you in plain text... I am surp=

rised how is it coming to as HTML.Any idea?Any speci=

al things I need to check before sending the email?-RegardsAbhisht Sharma+61 4204=

10228On Thu, 10 Jun 2021, 02:58 Robert J. Hansen, <mailto:r...@sixdemonbag.org";>r...@sixdemonbag.org> wrote:>.8ex;border-left:1=


px #ccc solid;padding-left:1ex">I'm not going to respond to this until =

you re-send it as plain text 

without HTML.=C2=A0 The very first thing I wrote in my last email was that =



this mailing list strongly prefers plain text without HTML.



We're willing to help you, but you need to follow the rules.



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

Re: GPG : "No secret key found" error

[Robert J. Hansen via Gnupg-users]

But, this command had a risk of exposing *$PASSPHRASE* to the UNIX 
console if any user executes *ps -ef* command while the code is running. 
This was a huge security breach so I chose the *--passphrase-file* 
option to read the decryption password from a file.


Now, all I need is to place the file, which stores the decryption 
password, with strict user permissions.


And this is probably a bad idea.

Clearly, you have a place where you feel it's safe to store a file 
containing the passphrase for your certificate.  So remove the 
passphrase from your certificate and store it there, in that safe place 
on your filesystem.



Having said that, just to add a little bit of more security...


This is a really bad habit: thinking that "I'll just add one more step 
to add a little bit more security."  It's endemic to the community -- 
you are far from the only person to have it.  But it's a bad habit, and 
here's why: security decisions always need to be connected to your 
threat model.


Is there something in your threat model you can point to and say, 
"because of this particular threat we're concerned about, this step I 
want to take is warranted"?  If so, go for it.  If not, don't.


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

Re: GPG : "No secret key found" error

[Robert J. Hansen via Gnupg-users]

I'm not going to respond to this until you re-send it as plain text 
without HTML.  The very first thing I wrote in my last email was that 
this mailing list strongly prefers plain text without HTML.


We're willing to help you, but you need to follow the rules.

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

Re: GPG : "No secret key found" error

[Robert J. Hansen via Gnupg-users]

Please do not send HTML to this mailing list.  Many of our members 
refuse to open HTML emails from unknown parties, so when you send HTML 
email to this list you're limiting the number of people who can see your 
question -- and maybe be able to help you!


Step 2. Instead, I have thought of storing the passphrase in a file 
(passphrase.dat.pgp), encrypted that file without password and passing 
the password to do the work using below command.


How exactly do you "encrypt that file without password"?

At any rate, this is probably a bad idea.  Often the best way to proceed 
for scripting GnuPG tasks is to remove the passphrase from the certificate.


Step 3. To my wonder, when I execute Step 1 first and then Step 2 
(within a short span), it works, but if I directly run Step 2 ( which 
actually will be happening as a part of solution), then it doesn't and 
fails for "No secret key" error.


This tells me that GnuPG is caching your passphrase with gpg-agent. 
When you run it the second time GnuPG sees the passphrase is in the 
cache and uses that, without ever needing to ask you for the passphrase.


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

Re: How would you do that ...

[Robert J. Hansen via Gnupg-users]

I have literally never in my life seen any meaningful use case for the OTP 
after about 1974.

It's not part of a sensible discussion. :)

On May 4, 2021 4:46:31 PM CDT, vedaal via Gnupg-users  
wrote:
>Or, for the really paranoid ;-)you can have random data on a read-only
>mini cdrom,and use it as an OTP, and throw it into a garbage
>incinerator afterwards.
>If you are up against adversaries where this is necessary,this methods
>may ultimately not help ...
>=
>
>On 5/4/2021 at 1:19 PM, "Ingo Klöcker"  wrote:On Dienstag, 4. Mai
>2021 18:47:50 CEST Robert J. Hansen via Gnupg-users wrote:
>> For modern SSDs I generally recommend a single pass with random
>data:
>> 
>> dd if=/dev/urandom of=/dev/foo bs=1M
>> 
>> (Don't forget the blocksize [bs] parameter; it can improve speed
>> significantly.)
>> 
>> This is enough to foil the vast majority of forensic analysis.  Yes,
>> yes, SSDs have remapping capabilities which means certain memory
>cells
>> won't get hit even if you do this, and it's theoretically possible
>for a
>> good forensics nerd to do all kinds of wild magic to pull off data
>you
>> didn't even know was there... but that kind of very high-level
>forensics
>> nerdery costs a lot of money, and few people are worth that kind of
>> investment.
>
>I'd always use full disk encryption ideally with the key stored on a
>USB 
>token. Otherwise, with a very good passphrase.
>
>And, after use, wipe the disk and destroy the token.
>
>Modern enterprise-level SSDs also have secure erase, but, of course,
>you'd 
>have to trust the hardware manufacturer to implement it properly
>without any 
>backdoors which you probably don't want to do in the above scenario.
>
>Regards,
>Ingo

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How would you do that ...

[Robert J. Hansen via Gnupg-users]

Modern harddisks don't allow that anymore. Should I assume that
"low-level format" in this case means something like

dd if=/dev/zero of=/dev/sdX


[puts on forensics professional hat]

Good question!  The tl;dr of it is that the technique to wipe a hard 
drive will vary according to the kind of technology used in 
manufacturing the drive, and to a lesser extent the kind of forensics 
nerdery you're afraid of.


This is the origin of the myth of the 30-odd-pass "Gutmann shred".  It 
was always a complete myth that you needed 30-odd passes to wipe a hard 
drive.  The 30+ passes were if you had no knowledge about the underlying 
technology of the drive and needed to account for antique FM-coded 
drives all the way up through modern SSDs.  If you were thinking of 
doing a 30+-pass shred, the best thing to do was smack yourself in the 
face for being so foolish and then go off and read the label on your 
hard drive.  :)


For modern SSDs I generally recommend a single pass with random data:

dd if=/dev/urandom of=/dev/foo bs=1M

(Don't forget the blocksize [bs] parameter; it can improve speed 
significantly.)


This is enough to foil the vast majority of forensic analysis.  Yes, 
yes, SSDs have remapping capabilities which means certain memory cells 
won't get hit even if you do this, and it's theoretically possible for a 
good forensics nerd to do all kinds of wild magic to pull off data you 
didn't even know was there... but that kind of very high-level forensics 
nerdery costs a lot of money, and few people are worth that kind of 
investment.



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

Re: How would you do that ...

[Robert J. Hansen via Gnupg-users]

Neal Stephenson's novel Cryptonomicon is excellent. I strongly
recommend it to anyone who enjoys reading & is interested in crypto.
Part of the plot involves a cipher that operates a bit like RC-4,
permuting an array, but the array is a deck of cards.
https://www.schneier.com/academic/solitaire/


Please don't.  Solitaire is not a particularly well-designed cipher, in 
either the human factors sense or in the cryptographic strength sense. 
Even Schneier himself says it's mostly of interest only as a curiosity 
and not for serious purposes.



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

Re: How would you do that ...

[Robert J. Hansen via Gnupg-users]

I have dealt with a similar problem in real life, as a real problem with real 
people.

We created a custom Linux environment, burned it to Blu-Ray, and Alice crossed 
the border with her Linux environment tucked into her CD player.

On the other side she acquired a laptop, Blu-Ray drive, and USB drive locally, 
booted into this custom environment, then flashed her BIOS and gave her drives 
a low-level format.

Rebooting into Linux (to reduce the likelihood of BIOS-based malware being 
present in memory) she used her system normally, although never touching the 
local hard drive. All storage was on USB stick.

Prior to departing the country she wiped the laptop hard drive and donated it 
to a school. The Blu-Ray disc and USB drive were physically destroyed and 
discreetly dumped.

I am not at liberty to say who Alice was, where she was, or why her needs were 
so extreme. But yes, we actually did this.


On May 3, 2021 4:24:01 AM CDT, Stefan Vasilev via Gnupg-users 
 wrote:
>Hi all,
>
>here is a little scenario. Alice and Bob needs to find a way to do 
>encrypted communications globally.
>
>The task is the following: Alice needs to travel to a foreign country 
>without any devices (laptop, smartphone etc.).
>
>At arrival she needs to communicate daily (no real time communications)
>
>with Bob to exchange encrypted documents.
>
>Alice is not allowed to login in any services, like her Gmail account, 
>social media etc. to not reveal her login credentials.
>
>She can't use Tor, because at her destination Tor is blocked. The only 
>option she has is to use Internet Cafés or public libraries etc.
>
>She is aware that at an Internet Café keyloggers may be installed. Last
>
>but not least she does not carry any notices on paper with her.
>
>
>How would you solve this task?
>
>
>Regards
>
>Stefan
>
>
>
>
>
>___
>Gnupg-users mailing list
>Gnupg-users@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Follow-up on L'Affaire Stallman

[Robert J. Hansen via Gnupg-users]

The only thing that I can say is that I would rather see a FAQ that
reflect the current inplementation of GPG than a non-up to date FAQ per
lack of user consensus (1).


The problem there is without community buy-in, the FAQ lacks 
credibility.  It's supposed to be the *community's* FAQ, which is why 
people consider it authoritative.  "This is Rob's thinking" would be, to 
say the least, controversial: some people think I explain things 
accurately and clearly, and others think I've been sniffing glue since a 
tender age.


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

Re: Follow-up on L'Affaire Stallman

[Robert J. Hansen via Gnupg-users]

The FAQ (https://www.gnupg.org/faq/gnupg-faq.html) claims the other
way round, namely:


Yep.  Which was why I stepped away: I've ended my affiliations with FSF 
and GNU.  However, that FAQ was last overhauled in October 2017, and 
apparently the relationship has changed in the last three and a half years.


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

Follow-up on L'Affaire Stallman

[Robert J. Hansen via Gnupg-users]

A few weeks have passed, and I figured a recap might be appropriate:

* FSF continues to support RMS

* FSFE has ended collaboration with FSF and GNU ("we see
  ourselves unable to collaborate both with the FSF and any
  other organisation in which Richard Stallman has a
  leading position")

* GnuPG has clarified it's not part of GNU

* RMS is still welcome to contribute, as is anyone else,
  but has no authority in either FSFE or GnuPG

Thank you, Bernhard and Werner: I really appreciate your quick 
statements on this.


Given this is the current position, I'm starting a complete rewrite of 
the FAQ for the 2.3 release.  I don't know when I'll be finished: not 
only is it a lot of writing and reviewing, but I have some personal 
matters that are demanding a lot of my attention.


If anyone in the community has strong feelings about the FAQ -- what 
should go in, what should be left out, etc. -- now's the time.


Werner, are you still set on org-mode as the native format, or has 
Markdown+Pandoc matured enough to also be acceptable?



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

Re: So long, and thanks for all the fish.

[Robert J. Hansen via Gnupg-users]

So to me, your statement is too general and may provoke some folks.
(You could see that Werner and myself also refrained from general
reasoning. :) )


I would also like to say that I have tried to make my stepping-away as 
painless and as friendly as possible.  I don't want to see ill will 
erupt in our community.  I like this community.  If anyone turns this 
into an occasion to launch a political flamewar, I will be very sad. 
Please don't do that.


My reasons for stepping away are simple.  I don't like RMS.  I think he 
is unkind.  I don't want to be associated with anything where he's in a 
position of authority.  It really is that simple.  It has nothing to do 
with politics, "cancel culture", or anything else like that.


Kindness counts.  Let's practice some.  :)




OpenPGP_0x1DCBDC01B44427C7.asc
Description: OpenPGP public key


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

Re: So long, and thanks for all the fish.

[Robert J. Hansen via Gnupg-users]

The FSFE is an independent sister organisation with a separate
leadership, and the framework agreement FSFE has with FSF does not give a
single person a special influcence or one of the organisations a special
power over the other.


Regardless of whether he officially has power, he clearly unofficially 
has power.  He's contacted me a few times over the years to insist on 
changes to the FAQ, usually over incredibly silly details like saying 
our pronunciation guidance was wrong because we advised people to 
pronounce GNU as two syllables, guh-NOO.  When I spoke to someone within 
FSFE (name omitted for their privacy) about his 'help', I was told to 
just do what he wanted in order to make him go away.


If the FSFE was independent of Stallman, no one would feel the need to 
appease him.


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

So long, and thanks for all the fish.

[Robert J. Hansen via Gnupg-users]

There's a song I really enjoy[*] with a line that always hits me as 
being both beautiful and wise:


"You talk far too much for someone so unkind."

I first heard of the GNU Project and the Free Software Foundation in 
1995.  For twenty-six years I've supported the FSF and FSFE in a variety 
of different ways.  For these twenty-six years, Richard Stallman has 
been at the forefront of the FSF.  In all that time I have trouble 
remembering when I have ever seen him be kind.


My direct experiences with him have all been frustrating.  I know many 
hackers whose direct experiences have been harrowing.  I do not know a 
single hacker whose direct experiences have been marked by kindness.


Last year when the FSF removed him from the Board of Directors, I 
welcomed the news.  I hoped the FSF would appoint better leaders.  They 
did not: instead, they've reappointed him to the board.


None of us have to tolerate toxic leadership.  We can always leave.  For 
that reason, I'm stepping down as the FAQ maintainer.  It was never a 
particularly big job, but I tried to do it responsibly.  I will also be 
ending my financial support of the FSF, FSFE, and affiliated groups for 
so long as Richard Stallman has influence in these organizations.


I'm not leaving the mailing list.  I'm not leaving the community. 
You'll continue to see me around.  And, should Richard Stallman resign 
or be removed from positions of influence in the FSF and FSFE, I will be 
happy to pick up the FAQ maintainer role again.


Thank you, Werner, for the chance to contribute to GnuPG (in my 
admittedly small way).  It's been a true pleasure doing this.


Be kind.  Expect kindness.  Especially demand kindness from your leaders.

[*] "Leave a Trace" by Churches.

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

Re: Best practices for obtaining a new GPG certificate

[Robert J. Hansen via Gnupg-users]

The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations.  Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.


Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys. 
That's not a niche implementation.


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

Re: Best practices for obtaining a new GPG certificate

[Robert J. Hansen via Gnupg-users]

I'd like to know current best practices for obtaining a new one?


This question gets asked so often that it has its own FAQ entry.  Yes, 
parts of the FAQ are outdated, but this particular one is very current.


https://www.gnupg.org/faq/gnupg-faq.html#tuning

* You don't need to "tune" GnuPG before using it
* The defaults for key generation are conservative and safe
* Don't overthink things.  :)

My sometimes-snarky (but completely-sincere) opinion on this evergreen 
question is, "unless you know what you're doing and why you're doing it, 
stick with the defaults."


The other piece of sometimes-snarky (but also completely-sincere) advice 
is that a good 90% of the web pages you find that talk about how to 
create the "perfect" GnuPG key are absolutely full of it.


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

Re: [EXT] Best practices for obtaining a new GPG certificate

[Robert J. Hansen via Gnupg-users]

Reading the URLs given by the OP, I see that the GPG FAQ (1) talks about
a default of '2048' but in the latest (2.2.17) release of GPG it looks
like the default is now '3072':


Yep.

[puts on maintainer hat]

The last time I suggested revisions to that text there was no community 
consensus on what should replace it.  Each proposed replacement met 
significant criticism.


My current plan is to wait until GnuPG 2.3 is released and then update 
the FAQ to reflect those changes, and hope that by that time there's 
community consensus to support the changes.


The FAQ isn't being ignored.  I'd like to do a total overhaul of it. 
However, the FAQ isn't meant to be my opinions and rants: it's meant to 
be *the community's* voice.  So I'm kind of dependent on the mailing 
list for support.


[takes off maintainer hat]

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

Re: question - Gnupg compatibility with Symantec

[Robert J. Hansen via Gnupg-users]

Our legacy Symantec users (who have not yet transferred over to GNU) are 
unable to decrypt/read GNU PGP emails.


Symantec is unfortunately not keeping current with the latest iterations 
of the OpenPGP specification.  Further, some features of current GnuPG 
keys are not supported by Symantec PGP.


A good way to begin would be to find your gpg.conf file, and add "pgp8" 
as the first line.  This will force GnuPG to use PGP 8 compatibility 
mode, which should be a good lowest common denominator for both platforms.


Hope this helps!

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

Re: New to GnuPG, having some difficulty

[Robert J. Hansen via Gnupg-users]

Hello gnupg-users!


Hello and welcome!

First, please only send plain text (not HTML) to the list.  Some of the 
most knowledgeable people here refuse to open HTML mails from people 
they don't know.  :)


I have recently been required to use GnuPG to encrypt messages, and have 
been endeavouring to create a master key however I think I have fumbled.


The best way to begin is to just run "gpg --gen-key" and use the 
defaults.  Really, the defaults are good: we picked them for good 
reasons.  The vast majority of the webpages you find about "creating the 
perfect GnuPG key!" are at least 90% whaleshit.



Is there a safe way to delete everything and start over?


gpgconf --kill gpg-agent
gpgconf --kill scdaemon
gpgconf --kill dirmngr
rm -rf $HOME/.gnupg

Then the next time you start GnuPG you'll be starting anew.

Also, I need to create and export a public key *and* an encryption 
subkey.


Again, I really recommend just running --gen-key unless you have a clear 
and compelling reason otherwise.


Thanks in advance, and I apologise if I'm asking basic questions, it's 
not often I feel like a novice but this encryption business has me doing 
so.


We were all newbies once.  :)

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

Re: Fundraising

[Robert J. Hansen via Gnupg-users]

*Appologies* Robert for highjacking your thread!!!


I have never understood why people apologize for doing something they 
know is wrong, and then do it anyway.  You could see that starting a new 
thread was appropriate; you know that starting a new thread is easy; you 
apologized for your inappropriate behavior; and then behaved 
inappropriately.  Your apology is not accepted, as it is clearly insincere.


Further, in just the last month and change on this list you've hyped 
Bitcoin scams, poorly-designed password managers, sown wild confusion 
about TLS and WKD, and now you're trying to raise funds for politically 
controversial figures unrelated to GnuPG's mission.


I cannot be the only one here who has noticed your track record.  I urge 
you to think long and hard about it, and to turn yourself around.


OpenPGP_0x1DCBDC01B44427C7.asc
Description: application/pgp-keys


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

Fundraising

[Robert J. Hansen via Gnupg-users]

A little more than a month ago I said I'd match all donations made to
GnuPG from December 10 to January 6.  I'm happy to report y'all made me
contribute 370 Euros, or about $450 USD.  The money has been paid and
is sitting in GnuPG's account.

I hope this encouraged some of y'all to donate to GnuPG this year.  And
if you missed out, why not consider making a recurring monthly
contribution of your own?  It's a great way to tell the crew thank-you
for all the work they do.

Thanks, all the GnuPG contributors.  I really appreciate it!



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

Re: On future of GnuPG

[Robert J. Hansen via Gnupg-users]

> The landscape has changed dramatically from the times when the
> original PGP fundamentals were introduced. Today, for any secure
> personal communication system to be of practical use, it must
> be designed from the ground up observing the following simple
> principle: *anonymity is the necessary condition of privacy*.

This borders on ridiculous.

One of the problems we have in privacy discussions is there is no
single agreed-upon definition of privacy.  Privacy is defined by
culture, and unless we share a culture we're very unlikely to share a
privacy definition.

In the United States, the prevailing culture cares a lot more about
government's ability to learn things about me without a warrant than it
does about the ability of corporations or businesses.  And we also
believe that government limiting our ability to speak infringes on our
privacy: "why the hell is the government getting in my business if all
I'm doing is sharing true things with my buddy?"  Whereas in Europe,
right-to-be-forgotten laws, enforced by the government, are seen as
wins for privacy, in America they would be (a) blatantly unlawful and
(b) considered massive invasions of our privacy by the government.

In Europe it's a lot different.  There, the prevailing culture cares a
lot more about limiting the ability of businesses to learn things about
a person than with limiting the ability of governments.  The national
security exemption in the GDPR is big enough to drive a truck through:
it is so all-encompassing that I, as an American, look at the GDPR and
think it's a nightmare for privacy rights.

And, you know, *this is okay*.  Privacy is culturally defined.  Enjoy
your culture, accept or reject its definition of privacy as you like. 
Just don't think that your culture's definition is somehow the only
one, or universally agreed-upon, or...

If there is no agreed-upon universal definition of privacy (and there
isn't), then any attempt to make sweeping statements like "anonymity is
a necessary condition of privacy" is just a bunch of freshman
Philosophy 101 crap that's entirely disconnected from the real world.



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

Re: Plan B - Who carries the torch?

[Robert J. Hansen via Gnupg-users]

On Tue, 2021-01-05 at 15:38 +0100, Werner Koch via Gnupg-users wrote:
> Virtually nobody uses the WoT...

Strangely, the Linux kernel folks still use it a decent amount. 
They're the only large group I can think of offhand, though.



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