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

[Jacob Bachmeyer via Gnupg-users]

On 10/10/24 10:09, Björn Persson wrote:

Mike Schleif wrote:
[...]

encryption error:
gpg: 9B51B2A5C71BDCEC: There is no assurance this key belongs to the named
user

Such assurance is provided by signing the key. Maybe the signatures
have been lost somehow, or the key that signed all the other keys is
missing or untrusted, or you never signed the keys in the first place.
Use --list-sigs to see what signatures exist. Then use --check-sigs to
see whether the signatures are valid.
The thought occurs to me:  we already know that this user has a bunch of 
PGP2 keys in their keyring.  Could the local signatures intended to 
validate trust on other keys have been from now-unusable PGP2 keys?


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

Re: ftp down

[Jacob Bachmeyer via Gnupg-users]

Björn Persson wrote:

Jacob Bachmeyer via Gnupg-users wrote:
  
Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks 
(which motivated the rush to HTTPS) because there is no in-protocol 
redirect.



So FTP isn't vulnerable to that particular attack,


... which is important because that particular attack (and a 
whistleblower reporting that it had been deployed on a large scale) was 
most of the motivation for the rush to HTTPS.



 and attackers have
to resort to TCP hijacking or DNS poisoning or BGP hijacking or
whatever.


All of which are far more detectable than the simple Man-on-the-Side 
attack.  BGP hijacking and DNS poisoning in particular are likely to 
affect large numbers of users.  That itself can be a deterrent.  
Remember that the threat model here is substituting a backdoored GPG.  
Such an attacker loses if the attack is merely /discovered/.  Each user 
affected increases the risk of discovery.



 Without cryptography there is no security.


Yes, and the transport by which GPG is delivered is already untrusted, 
thus the signatures on the tarballs and the digests in the release 
announcements.



 Anyone who wants
to argue in favor of FTP from a security point of view should at least
argue for FTP over TLS.
  


I specifically addressed that TLS is of little or no benefit to the 
distribution of GPG.  It does not even provide privacy as to what was 
downloaded, because passive traffic analysis reveals a connection to the 
GPG distribution server and that N bytes were received, which is likely 
enough information to determine /which/ tarball a client downloaded.



[...]
I would encourage resuming FTP distribution, since I see no plausible 
security benefit to omitting it.



For the download usecase, I see no plausible benefit to providing FTP
service in addition to HTTPS. A web server plus an FTP server will
always be a larger attack surface than only the web server. I recommend
leaving the FTP server off.


FTP is a longstanding and simple protocol; accordingly, FTP servers were 
all hardened long ago.  The incremental risk is slight, compared to the 
complexity of a modern httpd.  Especially if the FTP server can be 
further sandboxed using SELinux or similar, since it should need no 
write access whatsoever:  logs can be sent through syslog if needed or 
simply not kept at all.


I stand by my previous recommendation.


-- Jacob


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

Re: ftp down

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Wed, 21 Aug 2024 19:09, Jacob Bachmeyer said:

  

configured for anonymous-only.  FTP is both simple and ancient, so I



Yes, the protocol is simple but most server implementaions are pretty
complex.  That is why we settled for oftpd nearly decades ago.  And as
we see we are already building a file shed ;-)


Indeed; my point there was that not providing FTP does not necessarily 
avoid discussions about providing FTP.  ;-)


If you provide it, you can have people suggesting turning it off.  If 
you turn it off, you will have people suggesting to turn it back on.  ;-)


(This thread started when a user noticed that it was down, so it was 
being used, if rarely.)



-- Jacob

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

Re: ftp down

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Tue, 20 Aug 2024 19:19, Jacob Bachmeyer said:

  

I would suggest checking what ftpd Debian ships and using that.



They don't provide oftpd anymore which is an anonymous only ftpd.  All
others have a way larger attack surface.


I would be very surprised if whatever they do have cannot be configured 
for anonymous-only.  FTP is both simple and ancient, so I would expect 
all of the longstanding ftpds to be well-hardened by now.



-- Jacob


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

Re: ftp down

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Tue, 20 Aug 2024 00:26, Jacob Bachmeyer said:

  

I would encourage resuming FTP distribution, since I see no plausible
security benefit to omitting it.



I agree with your arguments.  However, not providing FTP saves us from a
lot of bike shedding discussions ;-)
  


Like what?  Whether to provide FTP?  ;-)


Another reason why we stopped FTP is that I currently don't anymore
trust the oftpd we are using because it seems I have to maintain it
myself.  Moving to Apache might be an option but that can only be done
when we also move the web server to Apache.  We are still running Boa
instances behind Pound on pretty old hardware.  This needs to be
changed, I know.
  


Admittedly, I was assuming currently-maintained software on the server.  
(Although FTP is simple enough that I would expect the exploitable bugs 
in *ftpd to have all been fixed by now.)  If you need to disable FTP for 
the time being until new software can be installed on the server, well, 
that is what it is.


I would suggest checking what ftpd Debian ships and using that.


-- Jacob


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

Re: ftp down

[Jacob Bachmeyer via Gnupg-users]

Werner Koch via Gnupg-users wrote:

Hi!

Thanks for mentioning this.

On Sat, 17 Aug 2024 13:49, Jan Palus said:
  

FTP service at ftp.gnupg.org appears to be down for some
time. Couldn't find any
info about FTP decommissioning so just letting you know about the problem.



I would not considere this a problem but something which we should have
done years ago.  Sorry for not annoucing this but my impression was that
nobody is using ftp anymore since the rush from http to https about 10
years ago.

Mapping ftp.gnupg.org URLs is a easy:

  ftp://ftp.gnupg.org/foo => https://gnupg.org/ftp/foo


Unlike HTTP, FTP is /not/ subject to simple Man-on-the-Side attacks 
(which motivated the rush to HTTPS) because there is no in-protocol 
redirect.  The attack on HTTP depends on winning a race and having the 
client close the connection before the server's legitimate response 
arrives.  (The attacker sends a fake 301 response with "Location:  
http://pwn.me.now/..."; and "Connection: close" headers.  The HTTP client 
then closes the connection and the client system sends TCP RST to the 
server when the legitimate response arrives.  The HTTP client the 
processes the redirect and contacts the attacker's server...)  In HTTPS, 
the attack is much harder---the attacker must win a much longer race to 
negotiate a fake TLS session and must hold a plausible certificate.  
(Actual "zero RTT" TLS set-up could make Man-on-the-Side possible 
against HTTPS if the attacker can get a phony certificate---you should 
assume that rogue states and transnational criminal organizations can 
obtain phony certificates from legitimate CAs by coercion or fraud.)  In 
FTP, the control connection must remain open during the transfer and 
there is no way for an attacker's response to redirect the client to a 
malicious server.


There is still a lack of confidentiality, since FTP is almost always run 
in plaintext, but that is not much of a concern when distributing 
publicly available software, especially when the mere fact that user X 
contacted gnupg.org and received N bytes is a good hint of what they 
were doing and possibly even exactly what they downloaded.  (In other 
words, traffic analysis easily breaks confidentiality in this case, even 
for HTTPS.)  For GPG, integrity is assured by signing the distribution 
tarballs directly, and the transport is untrusted anyway.


I would encourage resuming FTP distribution, since I see no plausible 
security benefit to omitting it.



-- Jacob


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

Re: GNU Privacy Handbook typo

[Jacob Bachmeyer via Gnupg-users]

Eric Pruitt wrote:

On Fri, Jun 07, 2024 at 06:03:22PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
  

Strictly, "their" is plural in English



No, it is not. "They" and "their" have been used as gender-neutral,
singular pronouns for centuries. Even if that wasn't the case, it's
widely accepted in modern colloquial usage.


Colloquial usage is /highly/ inappropriate in a reference that needs to 
be understood by people for whom English is a second language and who 
may have limited English proficiency.  Few English-as-a-foreign-language 
courses should be expected to mention singular "they", so its use is 
inappropriate in documentation.



 We can't just ossify the
language because some people don't like that a word can have multiple,
context-sensitive meanings.


Clarity is important here; if we can avoid requiring the reader to 
understand context-sensitive meanings, we should.



 "They/their" isn't even unique in that
manner when it comes to pronouns; [...]


While it can have that meaning, it is still wrong in this context:  we 
have "...you can be sure that the key really does belong to him..." just 
before the typo, therefore, the correct correction is to say "the key" 
or "his key", but the former is more specific that we are talking about 
the same key in both places, while the latter could describe one key 
that you are certain belongs to someone and /another/ key (possibly also 
belonging to the same person) that you have signed.


(It might also be interesting that I made (and fixed) the exact same 
typo ("they" instead of "the") while typing <<"the key">> in the above 
paragraph.)


The broader context is:

[...] a correspondent's key is validated by personally checking his 
key's fingerprint and then signing his public key with your private 
key. By personally checking the fingerprint you can be sure that the 
key really does belong to him, and since you have signed they key, you 
can be sure to detect any tampering with it in the future.




This suggests a better correction:  "...since you have signed *that* key..."


-- Jacob


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

Re: GNU Privacy Handbook typo

[Jacob Bachmeyer via Gnupg-users]

Patrick F. Marques via Gnupg-users wrote:

Hi,

I was reading the gnupg documentation and although I’m not an English 
native, I believe there is a “tiny” typo in this page 
https://www.gnupg.org/gph/en/manual/x334.html


In the first paragraph:

(…) By personally checking the fingerprint you can be sure that
the key really does belong to him, and since you have signed they
key, (..)

I believe it should be “their key” instead of “they key”


Strictly, "their" is plural in English and the antecedent here would be 
singular, since the text has already referred to the key's owner as 
"him".  A better way to fix the typo would be to change "they key" to 
"the key" instead.



-- Jacob

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

Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?

[Jacob Bachmeyer via Gnupg-users]

Bee via Gnupg-users wrote:

Its is called "USER DATA" for a reason - you have to decide what to do
with it.



But a novel pinentry must be created to receive the data. Again, this
is circular.

  

If your really really want a passphrase, what about passing
the filename of a file holding the passphrase.



AGAIN, this requires clear text storage trying to be avoided in the
first place, or ... decrypting the encrypted file on the fly ... which
requires a passphrase to be passed ... and we're circular again.
  


Yes, this is a fundamental limitation of public-key cryptography:  to 
decrypt a message or generate a signature, the private key must be 
available in cleartext.  Some would say that that is the point.


If you are trying to have some semblance of security with an unattended 
application, have you considered using a smartcard or HSM to store the key?



-- Jacob

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

Re: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout?

[Jacob Bachmeyer via Gnupg-users]

Bee via Gnupg-users wrote:

However if you known the passphrase, you can pass it to gpg directly using 
--passphrase-file and --pinentry-mode=loopback.


I figured, but am trying to avoid having the passphrase land on disk at all.
  


Could you set up a RAM disk for this?  (I think Windows still has those, 
but it has been a few years since I have used Windows any significant 
amount.)



-- Jacob

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

Re: Second OpenPGP-card

[Jacob Bachmeyer via Gnupg-users]

Matthias Apitz wrote:

El día miércoles, febrero 28, 2024 a las 10:32:43 +0100, Werner Koch via 
Gnupg-users escribió:
  

On Tue, 27 Feb 2024 20:52, Jacob Bachmeyer said:



Therefore, pass(1) almost certainly has its own list of keys stored
  

pass stores the fingerprints of the keys in a .gpg-id file and allows to
set different ones per directories.



Werner,

I have only one .gpg-id file on my L5 mobile in my password-store:

purism@pureos:~$ find .password-store/ -name .gpg-id
.password-store/.gpg-id

purism@pureos:~$ cat .password-store/.gpg-id
CCID L5
  


That .gpg-id file would be the list I was talking about.  It seems that 
pass(1) stores the actual keys on your main GPG keyring, but keeps a 
list of /which/ keys should be able to decrypt passwords separately.  
(Also ensure that there is never a rogue PASSWORD_STORE_KEY variable in 
your environment:  if set, it overrides the search for a .gpg-id file.)  
There is also a facility for maintaining GPG signatures on those .gpg-id 
files, which would make sneaking in Mallory's key far more difficult if 
you were to use it.  I suspect that the pass(1) manpage has more 
information and may be interesting reading.  Overall, this seems to be a 
good design.


I would also suggest using the key fingerprints instead of names when 
you reencrypt your password store, as I suspect that your new and old 
smartcard keys may have similar names.


As Werner mentioned, you can also have different .gpg-id files for 
different parts of your password store, if you wanted some passwords to 
only be available with certain smartcards.



-- Jacob


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

Re: Second OpenPGP-card

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Tue, 27 Feb 2024 20:52, Jacob Bachmeyer said:
  
[...]

logarithm problem and /vice versa/.  Accordingly, RSA1024 is now
considered sufficiently dubious that some implementations no longer
support it, such as the go-crypto/openpgp library used by the newer



Which is a Bad Idea because it is up to the user or their implementation
to decide which keys are trustworthy.  Being able to revoke rsa1024 keys
is a useful feature.  Although MD5 (PGP2) can be considered as fully
broken, rsa1024 is not in general broken.
  


Agreed; I was not endorsing that position, but I see that I should have 
said "apparently considered" to make that a bit more clear.  I trust 
that GPG will continue to support the shorter RSA keys for the 
foreseeable future.



But ist is pretty fashionable to use an easy to exploit OS (e.g. not
using the latest Linux kernel) and musing about RSA key strength.  Keep
Shamir's law in mind.


Or even Windows, which remains disturbingly common in applications that 
probably need far less attack surface, like industrial control 
systems...  (Is the stupidity of management a main driver of Shamir's law?)



-- Jacob


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

Re: Second OpenPGP-card

[Jacob Bachmeyer via Gnupg-users]

Matthias Apitz wrote:

El día lunes, febrero 26, 2024 a las 06:40:26 -0600, Jacob Bachmeyer via 
Gnupg-users escribió:

  

Matthias Apitz wrote:


[...]
Said/showed that, I can't imagine that, when I SCP the file
.password-store/test.gpg to another mobile with another OpenPGP card,
that this system would be able to decrypt the file and reencrypt it
again with the new card.
  

Correct.  You must first copy the *new* public key to the *old* system and
re-encrypt the password store to *both* public keys on the *old* system,
then transfer the encrypted blobs to the new system.
...



Thanks for the clarification and clear instruction.
  


You are welcome.


While you are here, this is a good time to remind you to regularly check the
list of public keys used with your password store.  If Mallory can sneak
*his* key onto that list, he will be able to get your passwords!



It says:

purism@pureos:~$ gpg --list-keys
/home/purism/.gnupg/pubring.kbx
---
pub   rsa2048 2021-10-30 [SC]
  336EB96892FE9FE7F6...
uid   [ultimate] Matthias Apitz (GnuPG CCID L5) 
sub   rsa2048 2021-10-30 [A]
sub   rsa2048 2021-10-30 [E]

[...]


Are you sure that *that* is the list of public keys used by pass(1)?  It 
almost certainly is not, since GPG's public key collection is meant to 
collect keys for a variety of uses.  For example, sending encrypted 
emails or verifying signatures.  You probably do not want your password 
store encrypted to everyone you correspond with!


Therefore, pass(1) almost certainly has its own list of keys stored 
somewhere else.  Your regular public key was probably copied to that 
list when you initialized the password store.  That is the list that you 
need to regularly check, lest Mallory be able to sneak his key onto it.  
That list is *also* where you need to add your new public key in order 
to migrate your password store.


Lastly, I know that you are using a smartcard, but you are storing 
long-lived (and presumably valuable) authentication tokens here.  Does 
the card support RSA4096 or at least RSA3072?  If so, I would strongly 
recommend migrating to longer keys, as RSA2048 is currently the shortest 
not probably already broken by increasing conventional computing power 
to throw at factoring.  If I understand correctly, this is the reason 
that DSA is obsolete:  DSA (to support smartcard implementations) 
specifies exactly one allowed key length:  1024 bits.  While DSA uses 
discrete logarithms, the discrete logarithm and factoring problems have 
a mathematical equivalence that means a factoring algorithm can be used 
to derive a solution to the discrete logarithm problem and /vice 
versa/.  Accordingly, RSA1024 is now considered sufficiently dubious 
that some implementations no longer support it, such as the 
go-crypto/openpgp library used by the newer "hockeypuck" keyserver 
software, which led to an interesting recent thread on gnupg-devel and 
bunch of old keys effectively falling out of the Web of Trust.



-- Jacob


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

Re: Second OpenPGP-card

[Jacob Bachmeyer via Gnupg-users]

Matthias Apitz wrote:

[...]
Said/showed that, I can't imagine that, when I SCP the file 
.password-store/test.gpg to another mobile with another OpenPGP card,

that this system would be able to decrypt the file and reencrypt it
again with the new card.


Correct.  You must first copy the *new* public key to the *old* system 
and re-encrypt the password store to *both* public keys on the *old* 
system, then transfer the encrypted blobs to the new system.


If you want to continue to use both cards, you will also need to copy 
the *old* public key to the *new* system and arrange for it to also 
encrypt the password store to *both* keys.  Once that is done, you may 
use any method to synchronize the encrypted blobs between the systems 
and you will have your passwords on both systems.


While you are here, this is a good time to remind you to regularly check 
the list of public keys used with your password store.  If Mallory can 
sneak *his* key onto that list, he will be able to get your passwords!


-- Jacob


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

Re: No SSH public key authentication using smartcard

[Jacob Bachmeyer via Gnupg-users]

Thomas wrote:

Hi,
this is exactly what I thought.
However, there's no solution for it.

Let me repeat my comments posted previously to get an overview what is 
working...
Actually I have a working setup on Windows 10, but here I use another 
terminal emulator: MobaXterm.

And in the settings of MobaXterm I enabled SSH forwarding.
As of now I don't want to continue using MobaXterm on Windows 11, but
using Windows Terminal.
I can run ssh-add.exe -L in Windows PowerShell and get the correct SSH 
public key fetched from secure card.


If you are using a Windows port of OpenSSH, try "ssh.exe -o ForwardAgent 
JUMPHOST" and see if that makes your local SSH agent available at the 
jumphost.  As I do not use Windows, I do not know where that Windows 
port would expect to find its configuration file.



-- Jacob

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

Re: No SSH public key authentication using smartcard

[Jacob Bachmeyer via Gnupg-users]

Thomas via Gnupg-users wrote:

Hello Stephan,
 
thanks for your reply.
 
When you say I should modify ~/.ssh/config, where is this file?

On jumphost?


You need to configure SSH agent forwarding on your client, which will 
provide access to your local SSH agent at the jumphost via the SSH 
connection between your client and the jumphost.  Since you are using a 
Windows client, ~/.ssh/config may not be relevant to your configuration.



-- Jacob

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

Re: gnupg 'signing server'? Looking for advice on key management/security

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Tue, 14 Nov 2023 20:52, Jacob Bachmeyer said:
  

succeed in either case.  If this condition is not met, Mallory will
eventually be able to forge a signature.  Therefore, smartcards do not
actually provide additional security in the typical PGP usage.



In all environments you have the advantage that you don't need to
re-deploy your public keys after a compromise of your signing box.
Sure, there are signatures on software/data out there which are not
legitimate but this is not different from the easier attack of modifying
the software/data before doing the signature.
  


This can vary with policy; I consider the known existence of an 
illegitimate signature to require the revocation of the signing key.


The easier attack you mention requires the same condition as breaking 
GPG's built in security or abusing the user's smartcard:  Mallory must 
plant persistent malware on the device that would have an opportunity to 
modify the item to be signed before GPG reads it and builds the signature.



Further, by inserting the smartcard only when required you limit the
exposure time of the key and hinder attackers to do a lot of
illegitimate signatures or decryption.
  


Yes; that is the "physical isolation" I mentioned as a further layer of 
security.



The OpenPGP cards feature a signature counter which can give you a hint
on whether it was used by something else than you.  It is not a perfect
solution but raises the hurdle for the attacker.  By using the smartcard
on different machines you can even avoid malware which fakes the
displaying of the signature counter.
  


The convenience of easily using multiple machines is one of the use 
cases for smartcards.  While I do not believe that it further 
/increases/ security, using a smartcard if keys are used on multiple 
machines certainly /preserves/ security while increasing convenience.


On a related note, the easier attack you mention of modifying the item 
to be signed would evade checks of the signature counter, since only the 
authorized signing event occurred, but the item signed had been tampered 
and was not the item the user intended to sign.



For a policy POV having the key material securely locked away is also an
advantage - even if the data can be decrypted/signed using a smartcard
by malware.  The security of the key material and the ability to use the
key material are different topics in a security policy.


Fair enough, although in my security model, the ability for an attacker 
to use the key material is the critical failure; insecurity of the key 
material implies that failure but the illegitimate use is the problem.



-- Jacob


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

Re: gnupg 'signing server'? Looking for advice on key management/security

[Jacob Bachmeyer via Gnupg-users]

Henning Follmann wrote:

On Mon, Nov 13, 2023 at 10:23:16PM -0600, Jacob Bachmeyer via Gnupg-users wrote:
  

Daniel Cerqueira wrote:


Jacob Bachmeyer  writes:
  

[...]
  


Yes it does. The key can't be copied and taken away from the device. This
is an advantage.
  


It is an advantage that is not relevant to network-connected 
general-purpose computing devices.


In both cases, the key is secure when not in use.  An encrypted private 
key is useless without the passphrase and a card is useless without the 
PIN.  In both cases the key can be further secured by physical 
isolation, storing the encrypted key on removable media or keeping the 
card out of the reader when not in use.  In both cases a "smash and 
grab" attack yields nothing of value, either an encrypted key or nothing 
at all (smartcard or removable media).  That means an intelligent 
attacker will attempt to place persistent malware to backdoor the 
device.  While the theft of both encrypted key and passphrase enables 
Mallory to forge signatures at his leisure, persistent malware could 
just as easily submit Mallory's messages to the smartcard for signing 
after locally stealing the PIN and simply waiting for the unsuspecting 
user to insert the card (or bring the token into NFC range... how many 
people would put phone and token into the same pocket without a second 
thought?).


Once the conditions necessary for an attacker to break GPG's built in 
private key security are met, the use of a smartcard is merely an 
inconvenience to an attacker.  In both cases, the attacker must wait for 
the key to be unlocked to produce a legitimate signature and can then, 
having stolen the authentication token (passphrase or PIN) used to 
unlock the key, produce additional (illegitimate) signatures.  The 
smartcard adds the minor inconvenience of having to wait for the user to 
insert the card, but this does not actually raise the bar for a 
successful attack, which is the forging of at least one signature, after 
which the key must be revoked.


Note that assuring the integrity of the device at all times that the 
card is connected generalizes to "at all times the key is used" for the 
GPG built in security case.  (If the integrity of the device is assured, 
then there can be no malware waiting to steal the passphrase and store 
it for later.)  If this condition is met, no attack can succeed in 
either case.  If this condition is not met, Mallory will eventually be 
able to forge a signature.  Therefore, smartcards do not actually 
provide additional security in the typical PGP usage.


Where smartcards are useful is protocols that require an untrusted or 
marginally trusted device that does not belong to the user to be able to 
produce a signature with the user's key for a short period of time but 
not afterwards.  Modern payment card systems supposedly are an example 
of this, but the EMV protocol has several less-secure legacy modes that 
may or may not still be in use.  (I do not know if the magstripe 
emulation mode has actually been phased out, for example.)




[...]

That is ignoring the additional risk that few if any smartcards use Free
firmware, and are, by design, nearly impossible to verify.  A secret
backdoor on the smartcard cannot be categorically ruled out, although such a
violation of trust would be expected to effectively remove the card's
manufacturer from the market should it come to light.



nitrokey publishes its card firmware and it can be updated and
independently audited.
There is also the OpenPGP card. IIRC the firmware is also available.

Yubikey does not publish the key firmware but they have an independent
auditing process in place IIRC.
  


Those are improvements in the field since I had last checked, although 
those are still two suppliers out of an entire industry.  Thank you for 
that information.



-- Jacob

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

Re: gnupg 'signing server'? Looking for advice on key management/security

[Jacob Bachmeyer via Gnupg-users]

Daniel Cerqueira wrote:

Jacob Bachmeyer  writes:

  

The problem here is that, while the key never leaves the smartcard,
the /entire/ device that accesses the smartcard must be trusted, as a
backdoor on the device could steal plaintext or submit extra items for
signing.  A PIN does not solve the problem, since the PIN is entered
on the device, which could be backdoored to store the PIN and submit
it along with Mallory's messages for the smartcard to sign---and the
card will sign it, since the PIN checks out...

Smartcards make silently duplicating the key difficult (supposedly
infeasible) but do not solve the general problems with
network-connected devices.



If you don't trust pinentry, maybe you should also not trust gnupg. They
are from the same project (gnupg.org).

I believe is best for you not to use gnupg and pinentry, until you
review it.


My point is that smartcards do not magically increase security beyond 
the private key wrapping encryption built in to GPG, and provide little 
actual security benefit unless less-common steps (such as using a card 
reader with its own PIN pad) are taken.  (The convenience of being able 
to simply move the card between devices may be useful for some users.)


The issue here is not GPG or its associated pinentry program or any 
question of their integrity.  The issue is the possibility of the 
computer being tampered while I am away from it, or potentially, via the 
network, right under my nose.  (Consider the overall security of the 
typical Android device.)  So far, smartcards do not seem to provide any 
better protection in this case than GPG's own security features.  Such 
tampering would enable the theft of the GPG key passphrase or card PIN 
in either case.  In other words, the same attacks that can effectively 
break GPG's built in security also effectively break a smartcard by 
enabling the unauthorized use of the key on the card.


That is ignoring the additional risk that few if any smartcards use Free 
firmware, and are, by design, nearly impossible to verify.  A secret 
backdoor on the smartcard cannot be categorically ruled out, although 
such a violation of trust would be expected to effectively remove the 
card's manufacturer from the market should it come to light.



-- Jacob


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

Re: gnupg 'signing server'? Looking for advice on key management/security

[Jacob Bachmeyer via Gnupg-users]

Daniel Cerqueira via Gnupg-users wrote:

Jeff Schmidt  writes:

[...]
You may want to consider using an OpenPGP smartcard (for example, a
Yubikey). Seems that you are a good fit.

Using a OpenPGP smartcard, the private key never leaves the smartcard.
The smartcard can also be used on a smartphone that has NFC support.
  


The problem here is that, while the key never leaves the smartcard, the 
/entire/ device that accesses the smartcard must be trusted, as a 
backdoor on the device could steal plaintext or submit extra items for 
signing.  A PIN does not solve the problem, since the PIN is entered on 
the device, which could be backdoored to store the PIN and submit it 
along with Mallory's messages for the smartcard to sign---and the card 
will sign it, since the PIN checks out...


Smartcards make silently duplicating the key difficult (supposedly 
infeasible) but do not solve the general problems with network-connected 
devices.



-- Jacob


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

Re: How to send a signed git patch

[Jacob Bachmeyer via Gnupg-users]

Daniel Cerqueira via Gnupg-users wrote:

Hi everyone.

I want to send my po translation of GnuPG.

Werner told me to send a signed git patch to a list.

So, I signed my git commit with my GnuPG key. And when I do
`git format-patch master` the created patch does not have this signature.

How can I create a git patch with a GnuPG signature?
  


You would have to sign the output of `git format-patch` separately.

Git signatures are stored in tag objects which refer to the signed 
commit.  An exported patch is only part of a commit and therefore does 
not carry the commit ID, which is what Git signs, if I recall correctly.


Another option would be to attach a Git bundle to an email, generated 
using `git bundle create origin/master..SIGNED-TAG-FOR-PATCH` although 
this would be less easily reviewed.



-- Jacob


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

Re: Finding all files encrypted with a certain key

[Jacob Bachmeyer via Gnupg-users]

raf via Gnupg-users wrote:

[...]
While testing these, I just noticed that /usr/bin/file
on my macOS-10.14 laptop shows a different keyid to
what libmagic shows. That's bizarre.

For some encrypted files of mine, /usr/bin/file (v5.33)
shows 3A0FC449 817C22BA but libmagic/rh shows 49C40F3A
BA227C81 for the same files. A more recent version of
file (v5.45) installed via macports shows the same as
libmagic/rh. So choose your version of file(1) wisely. :-)
  


You have an endianness-mismatch issue somewhere.  The octets are 
reversed in each 32-bit group between the samples.



-- Jacob


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

Re: All CPU threads

[Jacob Bachmeyer via Gnupg-users]

Werner Koch wrote:

On Mon, 11 Sep 2023 22:29, Jacob Bachmeyer said:

  

So using threads to compute a blinded RSA operation would just about
recover the computational cost of blinding the calculation?  How would



No.  I gave this as an example where you could else see on how to speed
up things.  For example if you do not need to mitigate local
side-channel attacks.


OK, I get it now:  you were suggesting that there are easier trade-offs 
for similar performance gains.  Thanks.



-- Jacob


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

Re: All CPU threads

[Jacob Bachmeyer via Gnupg-users]

Werner Koch via Gnupg-users wrote:

[...]

On Sat,  9 Sep 2023 22:07, Robert J. Hansen said:
  

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



The blinding we use for RSA (to mitigate side-channel attacks) should be
in the same range as these wins.  I bet that by adding threads to the
computation you will open another can of side-channel attacks.
  


So using threads to compute a blinded RSA operation would just about 
recover the computational cost of blinding the calculation?  How would 
hypothetical thread-related side channels matter if we are using 
blinding around the parallel calculation?



-- Jacob

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

Re: Resurrecting the Monkeysphere 🐒

[Jacob Bachmeyer via Gnupg-users]

John Scott via Gnupg-users wrote:

Reduce, reuse, and recycle: why make a fresh public key pair when you can 
reduce, reuse, and recycle one you've already got?


Simple:  to limit the exposure of the corresponding private key and the 
work required to rotate any given keypair.  Closely related, if 
different applications use different cryptographic keypairs (i.e. 
subkeys) you also have some indication where your private key got leaked 
based on which subkey was compromised.  This could be very important for 
tracking down an unknown exploit, since it tells you where to start looking.


OpenPGP does have a solution to this problem (subkeys) that I hope 
Monkeysphere will fully support.  Will there be support for importing, 
say, a Tor onion service keypair onto an OpenPGP certificate as a 
subkey?  (Obviously, tying Tor onion services to OpenPGP certificates 
blows the whole "anonymous" thing to bits, but Tor onion services have 
other uses, too.)  Or, perhaps more practically, importing an existing 
OpenSSH keypair as an OpenPGP subkey?



-- Jacob

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

Re: Strange message seen on FreeBSD 14.0 amd64

[Jacob Bachmeyer via Gnupg-users]

Dennis Clarke via Gnupg-users wrote:


Dear GnuPG type folks :

I don't know what this means. Can we just compile with a decent C
 compiler such as the LLVM/Clang in FreeBSD ?


[...]

Libgcrypt v1.10.2 has been configured as follows:

[...]

   Please not that your compiler does not support the GCC style
   aligned attribute. Using this software may evoke bus errors.

hydra$


So what does that mean ? I *must* use GCC to compile this source ?


It means that the sources use a GNU extension that configure has 
detected that Clang does not properly implement.  The specific example 
cited ("aligned") should be non-critical for you, since you are running 
on AMD64 and that architecture does not actually require proper 
alignment.  The resultant executables should work in your case, but at 
reduced performance (unaligned accesses are permitted on x86-64, but are 
slower than aligned accesses) unless SSE (which *does* have hard 
alignment requirements) is used.  Since I note that you are disabling 
the use of assembler modules, SSE will probably *not* be used in your 
executable.


In short, try it---if it works for you, great!  If GPG crashes with 
SIGBUS, try rebuilding it with GCC before reporting a bug in GPG.  If it 
works when built with GCC, you have found a bug (a missing feature that 
Clang claims to have) in Clang.  Clang typically defines __GNUC__, thus 
claiming to support GNU extensions, so this is a bug in Clang if your 
Clang-compiled GPG does not work.



-- Jacob


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

Re: get OpenPGP pubkeys authenticated using German personal ID

[Jacob Bachmeyer via Gnupg-users]

Alexander Leidinger via Gnupg-users wrote:

[...]

I don't remember if there was a challenge/response or not. As I still 
have the email with the signed key, I can tell that the signature can 
arrive via a TLS encrypted SMTP channel directly from governicus (and 
they have a SPF setup but not DKIM):

---snip---

Received: from smtp.governikus.de (smtp.governikus.de [194.31.70.126])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
  key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
  client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "VPR-BOS004.dmz.bosnetz.de", Issuer "VPR-BOS004.dmz.bosnetz.de" 
(not verified))
  


---snip---



Am I misreading that header or does Governikus' outgoing SMTP have a 
self-signed client certificate for 'VPR-BOS004.dmz.bosnetz.de'?  That 
does not inspire confidence...



-- Jacob


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

Re: ADK's

[Jacob Bachmeyer via Gnupg-users]

Michael Richardson wrote:

Jacob Bachmeyer  wrote:
>> I'm unclear if this is a new feature (I think so), and if so what 
happens if
>> the sender hasn't upgraded yet?
>>

> My understanding:  ADKs are new and do not work without support on the
> sender's side.  The ADK is a request to also encrypt any message to the
> subkey to the ADK.  If the sender's software does not understand that
> request, it does not happen.  If the sender rejects that request, either
> by setting an option or by patching their software to ignore the request, 
it
> does not happen.

Does it still (by default) encrypt to the main key?
  


My understanding:  Yes, if ADKs are not supported, the message is 
encrypted only for the main key.



[...]

>> > I would also note that, for a work email system in an environment 
where there
>> > is a legal or quasi-legal requirement (not uncommon in finance) to 
archive
>> > messages, simply dropping any incoming message not decryptable with the
>> > archive ADK as spam would be reasonable.  Since the primary concern
>> > motivating message archival in this example is deterring insider 
trading,
>> > simply not allowing unreadable messages to be delivered accomplishes 
the same
>> > objective.
>>
>> Yes, reasonable.
>> OTH, the emails investigating the insider trading by the HR people might 
need
>> to avoid the ADK.

> If we are talking about investigating HR malfeasance, those messages would
> not be going to the traders' regular inboxes in the first place.  You are
> right that an HR ADK could be a very bad idea in this example, since it 
could
> allow HR to front-run their own employer.  The expected solution would be 
to
> give the trading archives only to the audit or legal departments, and only
> after some period of time has passed.  That still leaves potential 
auditor or
> lawyer malfeasance, but that is an existing risk such businesses already
> handle.

It's the initial investigation of an irregularity where there could be a 
problem.
There is also an issue with 2FA and password reset emails: it's something
that may be a vulnerability to archive.  Okay, few are encrypted today, but
we can hope.   Many companies with forced proxis are starting to realize that
they become liable when they store banking login cookies.
  


Really, the banks should be recognizing those networks and denying 
logins.  Perhaps corporate forced proxies should be required to insert 
an additional header reporting that the connection is not actually 
point-to-point encrypted, which banks and other sensitive services could 
use to reject sessions.


The main problem here seems to be a work-life balance issue.  People 
should not be conducting personal business on the company network, and, 
in turn, companies need to understand that personal time outside of work 
is /personal/ /time/ /outside/ /of/ /work/.  I am not sure in which 
direction this first broke down, but it is the root cause of a wide 
variety of problems.



Anyway, I think senders need to be made mildly aware that it's occuring, and
I think they should be allowed to pick a specific ADK or suppress them all in
certain circumstances best decided by them.
  


I believe that is substantially what I proposed, so at least two of us 
agree.



-- Jacob

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

Re: ADK's

[Jacob Bachmeyer via Gnupg-users]

Michael Richardson wrote:

Jacob Bachmeyer via Gnupg-users  wrote:
> ADKs seem particularly valuable to me as a solution to the "group inbox"
> problem that avoids actually sharing private key material:  simply
> attach encryption subkeys for all recipients to the "group inbox"
> certificate.  This requires publishing new certificates when the
> recipient list changes and discloses the recipient list to some extent, 
but
> that is the trade-off for end-to-end security in this context.  Could a
> "--notify-ADK-encrypt" option that could be placed in the configuration 
file
> be appropriate to address user concerns about possible improper 
proliferation
> of ADKs?  Should a notification that an ADK was used actually be default?
> After all, there are legitimate uses for ADKs, but an ADK turning up where
> not expected could be a strong hint that you have a bogus certificate.

That would be really useful for secur...@example.com
  


That is an almost prototypical example.  In that case, the "archive" key 
would actually be the main subkey, and the list recipients' personal 
keys would be attached as ADKs.


Another example:  suppose I have multiple hardware tokens and wish to be 
able to use them interchangeably, but also want maximal security with 
this arrangement, so have generated an encryption keypair on each 
token.  I list all of the per-token subkeys as ADKs.  In this case, the 
ADKs really would all be /my/ keys.  Again, I would have to publish a 
new certificate every time my collection of live tokens changes, which 
may or may not leak useful information to an adversary.



I'm unclear if this is a new feature (I think so), and if so what happens if
the sender hasn't upgraded yet?
  


My understanding:  ADKs are new and do not work without support on the 
sender's side.  The ADK is a request to also encrypt any message to the 
subkey to the ADK.  If the sender's software does not understand that 
request, it does not happen.  If the sender rejects that request, either 
by setting an option or by patching their software to ignore the 
request, it does not happen.


My primary reason for arguing to support some way to suppress the use of 
an ADK when encrypting is that, as Johan noted, this is an issue where 
feelings are strong enough to provoke forks, which are likely to simply 
rip out ADK support entirely, thus making its legitimate uses (group 
inboxes, multiple tokens, business-related) unreliable.



> I would also note that, for a work email system in an environment where 
there
> is a legal or quasi-legal requirement (not uncommon in finance) to archive
> messages, simply dropping any incoming message not decryptable with the
> archive ADK as spam would be reasonable.  Since the primary concern
> motivating message archival in this example is deterring insider trading,
> simply not allowing unreadable messages to be delivered accomplishes the 
same
> objective.

Yes, reasonable.
OTH, the emails investigating the insider trading by the HR people might need
to avoid the ADK.


If we are talking about investigating HR malfeasance, those messages 
would not be going to the traders' regular inboxes in the first place.  
You are right that an HR ADK could be a very bad idea in this example, 
since it could allow HR to front-run their own employer.  The expected 
solution would be to give the trading archives only to the audit or 
legal departments, and only after some period of time has passed.  That 
still leaves potential auditor or lawyer malfeasance, but that is an 
existing risk such businesses already handle.



-- Jacob


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

Re: ADK's

[Jacob Bachmeyer via Gnupg-users]

Johan Wevers via Gnupg-users wrote:

On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:

[...]
  

The danger of an “ignore ADK” option is that it gives a false sense of 
security. It is already possible for an employer to require escrow of the 
decryption subkeys of their employees - ADK actually makes this process more 
transparent.



That might be, but it is nowhere certain that this escrow will happen,
especially if they roll out adk's. Not providing such an option might be
a case where the perfect is the enemy of the good: it might not be a
perfect solution but it can be better than the alternative.

Besides, this is begging for GnuPG forks to arise, and if those forks
are well implemented remains to be seen.


Maybe the best option here is an "--override-encryption-target 
KEYGRIP/SUBKEYGRIP" option, repeatable to encrypt to multiple specific 
subkeys of the same or different PGP keys, which is why it requires both 
a keygrip and a subkeygrip.  This would also allow encrypting to some 
ADKs while ignoring others and resolve the demands for an "ignore ADK" 
option.


ADKs seem particularly valuable to me as a solution to the "group inbox" 
problem that avoids actually sharing private key material:  simply 
attach encryption subkeys for all recipients to the "group inbox" 
certificate.  This requires publishing new certificates when the 
recipient list changes and discloses the recipient list to some extent, 
but that is the trade-off for end-to-end security in this context.  
Could a "--notify-ADK-encrypt" option that could be placed in the 
configuration file be appropriate to address user concerns about 
possible improper proliferation of ADKs?  Should a notification that an 
ADK was used actually be default?  After all, there are legitimate uses 
for ADKs, but an ADK turning up where not expected could be a strong 
hint that you have a bogus certificate.


I would also note that, for a work email system in an environment where 
there is a legal or quasi-legal requirement (not uncommon in finance) to 
archive messages, simply dropping any incoming message not decryptable 
with the archive ADK as spam would be reasonable.  Since the primary 
concern motivating message archival in this example is deterring insider 
trading, simply not allowing unreadable messages to be delivered 
accomplishes the same objective.



-- Jacob

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

Re: Optimal workflow with GPG signatures from multiple parties

[Jacob Bachmeyer via Gnupg-users]

Ave Milia via Gnupg-users wrote:


Logically, it probably should not be as simple as the developer deploying their 
personal public key into the target environment and then signing their 
artifact, for two reasons: the target environment gets wiped, and it 
practically cannot account for all personal keys of all the developers; and 
then there is not much difference versus giving the developer direct access to 
the main private key.
  


Er, I may be mistaken here, but I understand that if any of the code you 
distribute is GPLv3, installing a personal public key into the target 
environment is exactly what you are required to permit.  (Or the 
"Installation Instructions" required under section 6 of the GPLv3 can 
include the main private key, your choice.)  The only way you get out of 
this is if you are not actually distributing code and this whole 
scenario is internal to some organization.



What are some available solutions? How would you suggest to organize the keys? 
Maybe, there should be some signing server in-place, that the developers sends 
an artifact to?
  


Since you are asking on a list for GPG users, I suspect you are likely 
using GPG to verify artifacts in the target environment, and therefore 
need to comply with GPLv3... addressing that first may solve your problem.



-- Jacob

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

Re: libgcrypt clang asm configure issue.

[Jacob Bachmeyer via Gnupg-users]

Dmytro Kovalov wrote:

Hello Jacob ,

Thanks for the fast response!

So you mentioned the problem is in clang ATT compatibility. But could 
you please confirm the UAL supports ATT style , because I haven't 
found any information there.


UAL is ?

The key hint here for me was that you mentioned removing '%' from 
register names; the use of '%' in that context is (as far as I know) 
characteristic of "AT&T syntax" assembler, which the GNU assembler 
generally supports, even for processors where the vendor assembler is 
radically different.  (x86 is a good example, where GNU as has both AT&T 
syntax and Intel syntax modes.)



-- Jacob

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

Re: libgcrypt clang asm configure issue.

[Jacob Bachmeyer via Gnupg-users]

Dmytro Kovalov via Gnupg-users wrote:

Hello,

I found a strange libgcrypt behavior on ARM with clang built.

There is a big gap in performance of libgcrypt, built by clang, in 
comparison with gcc on my ARM target machine.

The simple profile test shows 100-500% advantage of gcc gcrypt.
I found an awkward workaround to beat this issue, but need your help 
to find the best way to fix it.


The root cause is next:
Due to clang strict assembler syntax rules the unified assembler ARM 
check doesn't pass.

Assembler check fails while ./configure for flags:
HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS
HAVE_GCC_INLINE_ASM_NEON

As a workaround I remove '%' from registers names in
configure.ac ,
arm mips lib *.S files,
cipher/*arm.S,*armv7-neon.S files.

Could you please help with a more correct - polite way to compile 
libgcrypt with assembler code?


I would suggest using the GNU toolchain.  :-)

The problem is that the GNU assembler traditionally expects register 
names to be prefixed with %, using a syntax based on that of the old 
AT&T assembler and known (simply enough) as "AT&T syntax" while many 
vendor assemblers use a different syntax.  Note that the configure tests 
in question are for GCC-or-strictly-compatible.  If clang does not 
support the GNU assembler syntax, then it is not fully compatible with 
GCC, and libgcrypt is being compiled correctly.


Since LLVM claims compatibility with GCC, you should direct your 
complaints there:  CLang apparently claims compatibility with the GNU 
toolchain, but does not support GNU assembler syntax.



-- Jacob

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

Re: WKD: conveying intent of encrypt-by-default?

[Jacob Bachmeyer via Gnupg-users]

Phil Pennock via Gnupg-users wrote:

[...]

Problem: we use PGP for signing and for certain transactions which need
high confidentiality, but for the most part, for most of our staff,
setting up a PGP-capable mail client with our mail-provider is a pain
and we're not interested.  We want the PGP keys _available_ for people
to have a trusted path to the key, but that does _not_ mean that we want
people to default to using PGP for all communications with us.
  


Simple option if most users at your site will be generating PGP 
signatures but not running PGP-capable MUAs:  generate sign-only keys 
and put those in WKD.  You would need a second mechanism for 
distributing the encryption-permitted keys for those users who need 
them, but the encryption keys could in turn be signed with the WKD 
sign-only keys to prevent a man-in-the-middle attack.



-- Jacob

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

Re: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG

[Jacob Bachmeyer via Gnupg-users]

Tony Lee via Gnupg-users wrote:

[...]

I was pleased to receive a rapid response from Werner Koch, who 
explained that the nominated count_value of 1024 actually used a default
count_value compatible with gpg 1.4, and then went on to explain that 
OpenPGP used an SHA1-based Key Distribution Function (KDF).


KDF here is "Key Derivation Function", not "Key Distribution Function".

However, in my Aug 30 response, I noted that I had carefully followed 
the gpg man pages in specifying my wish to use an AES256 cipher, and 
an SHA256 hash function.


If I understand correctly, it probably did:  your data was encrypted 
using AES256 using a key derived from your passphrase using the OpenPGP 
KDF and an integrity check value using SHA256 was included with the 
encrypted data.


[...] As I noted, both AES-128 and SHA-1 are generally deprecated 
functions in cryptography.


This is completely irrelevant to a KDF.  The only purpose of a KDF is to 
expend considerable computational power to derive a key from a 
passphrase, to partially compensate for the expected low entropy of a 
passphrase by making a search dramatically more expensive.


So I am left wondering whether my specified AES-256 and SHA-256 were 
used with my other count_value values.


Most probably yes, although you would need to examine the source code to 
be certain.  GPG 1.4 *did* support AES256 and SHA256, so compatibility 
would not be an excuse to fail to use them.


My Aug 27 submission highlighted a Spectra Secure YouTube which noted 
that the --s2k parameters were ignored for key export without warning, 
and that this "bug" had been the case since 2017.  Do we now discover 
that the --s2k parameters are similarly ignored for _all_ symmetric 
encryption procedures, in contradiction to the man-page instructions 
on use?


If so, that would be a very serious bug, but you would need to examine 
the sources to make sure.



-- Jacob

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

Re: Presentation. Migration to subkeys

[Jacob Bachmeyer via Gnupg-users]

Diez via Gnupg-users wrote:

Is it possible "extract" Sign usage from master key an put it into a
subkey with the same ID and fingerprint? I'm think no.

This email is to verify that, indeed, it is not possible.
  


If I understand correctly, "same ID and fingerprint" would mean that it 
is *exactly* the same key, so while it might be possible to arrange a 
PGP certificate like this, you would gain nothing:  the subkey would be 
an exact copy of the master key.



-- Jacob

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

Re: Cannot import private key into gpgsm

[Jacob Bachmeyer via Gnupg-users]

Gilberto F da Silva via Gnupg-users wrote:

Slackware64 15

slack15@darkstar:~/.config$ gpg --version
gpg (GnuPG) 1.4.23
[...]



I may be misunderstanding, but I do not think that GPG 1.4.x ever even 
supported X.509 at all.  Maybe you also have a gpg2 command?  Maybe 
there is another gpg somewhere else on the machine?



-- Jacob

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

Re: Backing up your PGP key by hand

[Jacob Bachmeyer via Gnupg-users]

Lars Noodén via Gnupg-users wrote:

On 5/5/22 01:11, Jacob Bachmeyer wrote:
> Lars Noodén via Gnupg-users wrote:
>> A removable hard drive might be an option, if the storage time
>> is less than a decade and there are decent storage conditions
>> in regards to chemicals, temperature, humidity, and so on.  Flash
>> memory seems to lose
>> its charge rather quickly, measured in months.
>
> Write-once optical media is my preferred means of long-term backup for
> nontrivial amounts of data,
[snip]

The number of years that the keys and the data they apply to will be
stored unpowered, offline will influence which storage medium is
acceptable for the task.

Old CD-R were short-lived garage from my experience, but certain models
of recently made CD-R should last a while even under slightly
non-optimal storage conditions before they start flipping bits.


This depends on the quality of the media.  I first got a CD-R drive in 
the mid 2000s and have discs from back then that were still readable 
when I last looked at them a few years ago.  Admittedly, these have been 
stored under ordinary room conditions and protected in a disc binder or 
jewel cases and were not the "bargain basement" media that was also 
available at the time.  A friend once lamented having something like 3 
to 5 discs out of a 100-pack of "Great Quality" branded CD-R media that 
were actually usable; the rest were either rejected during burning or 
failed immediately upon readback.  It is doubtful that those "Great 
Quality" discs are still readable today.  There was a significant 
difference in price:  the discs I used (Maxell/Memorex/Verbatim name 
brands stand out thinking back) typically cost about $20 for a 50-pack 
or similar for a 100-pack if on sale, while "Great Quality" was $5 for 
100.  You really did get what you paid for, however.


There were also direct-write DVD-R camcorders fairly popular in the mid 
to late 2000s.  I remember news stories about most of Barack Obama's 
earlier speeches having been lost before his first term as US President 
had ended because the only recordings had been made by his supporters 
using those camcorders and cheap DVD-R media that did not last.



Note that "nontrivial amounts of data" excludes PGP keys; even a 
mini-CD-R holds several megabytes.  I will admit that lack of a 
reasonable backup strategy is one of the reasons I do not presently use 
PGP for encryption.



[...]

Whether that bit flip hits anything important is another matter, but
they do add up over time and with enough of them they will eventually
hit something, worse if it hit something compressed.  [...]


CD-ROM format has considerable data expansion.  If I remember correctly, 
a 650MB data CD actually stores something like 2.1GB after applying the 
various ECC layers.  There are quite a few bits to flip before anything 
is affected.



Air pollution, temperature, light, and humidity are some of the factors
affecting the lifespan of the physical storage medium.


One of the advantages of optical media generally is that the discs are 
(supposed to be) sealed against their environment.  Absent extremes, 
(polycarbonate has a melting point, the data is written using very 
intense light that locally heats the dye layer) environmental effects 
should be minimal.  Along these lines, while fire will obviously destroy 
optical media, discs should remain readable after being in a flood, for 
example.  (Some mold removal may be needed, and the data should be 
copied to new media in case mold or the chemicals used to remove it 
adversely affect the integrity of the environmental seal.)



> I have SD cards and USB sticks with data blocks last written
> many years ago and still readable.  Granted, I have never used
> low-end no-name
[snip]

And by reading them, they have powered up and refreshed the charge.  The
problem applies to such flash storage devices which have been left
unpowered for longer periods of time.


No, it does not.  That is not how flash memory works.  Some flash 
translation layers might do such things in some devices, but I strongly 
doubt that flash-based microcontrollers have undocumented hardware 
functions to periodically rewrite the program storage, for example.  In 
any case, I have both USB sticks and SD cards that have been left 
entirely unpowered for years and found the data to still be there, 
certainly much longer than the "few months" you mentioned earlier.


Theoretically, the stored charge does eventually leak off of the 
floating gate, but EEPROMs (and flash, which is essentially the same 
technology) are generally considered to hold data indefinitely.  The 
data retention specifications are based on "accelerated aging" tests, 
which generally involve elevated temperature.  The processes involved 
are highly nonlinear with respect to temperature and may very easily 
require centuries at room temperature or not occur at all without 
elevated temperatures; we do not know because flash storage is only now 
r

Re: Backing up your PGP key by hand

[Jacob Bachmeyer via Gnupg-users]

Lars Noodén via Gnupg-users wrote:

A removable hard drive might be an option, if the storage time is less
than a decade and there are decent storage conditions in regards to
chemicals, temperature, humidity, and so on.  Flash memory seems to lose
its charge rather quickly, measured in months.


Write-once optical media is my preferred means of long-term backup for 
nontrivial amounts of data, but this view about flash losing data in 
months is completely ridiculous.  Typical data retention specs for flash 
memory are for decades.  If losing data in mere months were acceptable, 
just about nothing would work, including the computer you use for email 
-- its firmware is almost certainly in flash and it is probably more 
than a few months old.


I have SD cards and USB sticks with data blocks last written many years 
ago and still readable.  Granted, I have never used low-end no-name 
Chinesium storage, so that may have something to do with it, but flash 
memory is far more durable than a few months.  Battery-backed SRAM 
typically has batteries that last longer than that; if flash only held 
data for months, it would never have been commercially viable for 
displacing said SRAM.



-- Jacob

___
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

[Jacob Bachmeyer via Gnupg-users]

Francis Kp via Gnupg-users wrote:

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.

$ gcc -I /home/user/Desktop/gnupg-1.4.13
-l/home/user/Desktop/gnupg-1.4.13 mpi-pow.c

Now it's throwing the below error
  
[...]

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:
  
[...]

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


Yes, you should remove the copy of mpi.h you made in 
/home/user/Desktop/gnupg-1.4.13; that is not how you make libraries 
available to C compilations.  Try 
-I/home/user/Desktop/gnupg-1.4.13/include instead of copying mpi.h.


If you are having to ask for help with these problems, I am not sure you 
have the prerequisite programming skills to be doing this.  I think you 
need to learn more about C, compilation and linking, and other fairly 
basic computer science topics before trying to study cybersecurity, lest 
you become another entertaining "security" clown who has no clue how 
computers actually work but thinks that signed integers are magically 
more secure.  (Hint:  "signed" and "unsigned" in C have nothing to do 
with cryptographic signatures whatsoever.)



-- Jacob

___
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)

[Jacob Bachmeyer via Gnupg-users]

Daniel Colquitt via Gnupg-users wrote:

Whilst AES128 is probably okay for now, SHA1 has been broken for well over 15 
years.


Has it really been that long? ... No, it has not been:  a free-start 
collision was found on the SHA-1 compression function in 2015, less than 
7 years ago.


As far as I know, a single collision pair ("SHAttered") has been 
produced, using about 9 months on a very large cluster, against the full 
SHA-1.  There is no comparison here to MD5, for example.  Further, only 
collisions have been demonstrated so far, and if Mallory producing a 
colliding private key is a concern for you, you have bigger problems, 
like Mallory having provided your private key in the first place!


It is also worth noting that SHA-1 is (as far as I know) only used as a 
fancy checksum here to guard against data corruption.  If Mallory even 
has access to potentially replace your private key, you have bigger 
problems than potential weaknesses of the checksum on that key.



-- Jacob


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

Re: Preventing public key upload to key-servers

[Jacob Bachmeyer via Gnupg-users]

jonkomer via Gnupg-users wrote:

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


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


It may *purport* to apply, but if the keyserver is outside of EU 
jurisdiction, the server is outside of EU jurisdiction.


This is a very good thing, or would you prefer to be subject to whatever 
"long arm" nonsense Communist China can cook up?



-- Jacob


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

Re: Limit access to unlocked OpenPGP SmartCard?

[Jacob Bachmeyer via Gnupg-users]

Felix E. Klee wrote:

After I unlock an OpenPGP SmartCard V2.1 in my SPR332 [mod][1], I can
use it to decrypt as many files as I want.  While this is convenient, it
is not great if the system is compromised and I forget to unplug the
card reader.

Is there any way to limit how long the OpenPGP SmartCard remains
unlocked?
  


Does your smartcard reader have its own keypad for entering the PIN?  If 
not and you are concerned about a possible system compromise, you have 
bigger problems, like the possibility for your smartcard PIN to be 
stolen as you enter it.  If you then leave the card in the reader, 
Mallory can abuse it at his leisure.  Even if you only insert the card 
when you intend its use, Mallory could plant malware that waits for the 
card to be inserted, then abuses it.



-- Jacob

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

Re: pgp263iamulti06

[Jacob Bachmeyer via Gnupg-users]

Robert J. Hansen via Gnupg-users wrote:

When generating the key-pair with Re: pgp263iamulti06, the
"randomness" is obtained by user's keyboard input. Is it
then that the above applies only when the session key is
generated?


No, the whole CSPRNG is (probably) compromised.  PGP 2.6.3 used 
keyboard interrupts harvested directly from the hardware to get a 
collection of random bits which it then fed into the CSPRNG to be 
expanded out into a large quantity of randomish bits.  It's just that 
when generating a new certificate it always replenished the CSPRNG's 
entropy -- when generating traffic it didn't, but the CSPRNG was still 
dependent on the randomness collected earlier.


On Windows, you no longer have this direct access to hardware and 
there's almost certainly some determinism introduced by the HAL.


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.



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.


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...



-- Jacob

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

Re: Using two OpenPGP cards

[Jacob Bachmeyer via Gnupg-users]

Matthias Apitz wrote:

El día viernes, octubre 29, 2021 a las 08:35:43p. m. -0500, Jacob Bachmeyer via 
Gnupg-users escribió:
  

Matthias Apitz wrote:


The question here is: Can I somehow transfer the keys from the used
OpenPGP card to this new card (and copy over the tree of encrypted
passwords to the phone) or do I have to move the passwords in clear and
crypt them again with the new card?
  

If I understand correctly that your tool uses public keys,



The password store is a tree of GnuPG encrypted file as:

$ find .password-store
.password-store
.password-store/web
.password-store/web/test1.gpg
.password-store/web/test2.gpg
.password-store/web/test3.gpg
.password-store/web/hwiconnect.net.gpg
.password-store/web/es-la.facebook.com.gpg
...

it was once (2017) initialized with

$ pass init g...@unixarea.de

and one can see the gpg-id in the file of the store:

$ cat .password-store/.gpg-id
g...@unixarea.de

This mail addr is the reference to the (public) key:

$ gpg2 -K
/home/guru/.gnupg-ccid/pubring.kbx
--
sec>  rsa4096 2017-05-14 [SC]
  5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
  Card serial no. = 0005 532B
uid   [ultimate] Matthias Apitz (GnuPG CCID) 
ssb>  rsa4096 2017-05-14 [A]
ssb>  rsa4096 2017-05-14 [E]

[...]

3.  Arrange for your password store to be encrypted for *both* public keys.



Perhaps I should now import the above Public-Key on the laptop and
re-init there the password store with both gpg-id:

$ pass init 'GnuPG CCID' 'CCID L5'

I will test this after making bakups of GNUPGHOME and ~/password-store.
  


I do not know the details of how pass(1) operates, so this will be 
necessarily vague.  What you need to accomplish is re-encrypting all of 
the files in password-store to both keys, where they are currently 
encrypted only for your old key.


Importing your new public key on your old device is certainly a step in 
this process, but I am not sure of the best way to re-encrypt the 
files.  There may be a way to do this with pass(1), or you may need to 
use GPG directly.  Check the pass(1) documentation for a "key rotation" 
procedure.


There is also a question of whether you want to continue to use both 
devices, if so, you will need to import your old public key on your new 
device and configure the new password store to also use both public 
keys.  Then you need only synchronize the encrypted files between 
devices and your passwords will be securely available on both.



Thanks for your hints
  

You are welcome.



-- Jacob


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

Re: Using two OpenPGP cards

[Jacob Bachmeyer via Gnupg-users]

Matthias Apitz wrote:

The question here is: Can I somehow transfer the keys from the used
OpenPGP card to this new card (and copy over the tree of encrypted
passwords to the phone) or do I have to move the passwords in clear and
crypt them again with the new card?


If I understand correctly that your tool uses public keys, you will need to:

1.  Generate keys on your new device.
2.  Export the public key for your new smartcard.
3.  Arrange for your password store to be encrypted for *both* public keys.
4.  Copy the appropriately encrypted password store to the new device.
5.  Use the new card's secret key to access the encrypted password store.

If your tool is using a symmetric key embedded in the smartcard, you 
will need to transfer the passwords "in the clear" but you could use a 
keypair to wrap the bundle during transit.  The entire purpose of a 
smartcard here is that the secret keys cannot be extracted from it.



-- Jacob


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

Re: What are the file in ~/.gnupg ?

[Jacob Bachmeyer via Gnupg-users]

Damien Goutte-Gattat via Gnupg-users wrote:
On Fri, Oct 29, 2021 at 04:04:11PM +0200, Romain LT via Gnupg-users 
wrote:

[...]

private-keys-v1.d/
folder with private keys files, named afte key or subkey keygrip
Is there only the private key part of my own keys in this ? or
is there a way to obtain public+private key from one of those
files ?


Private key only. I believe the purely “mathematical” components of 
the public key can be derived from it (though I may be wrong here), 
but that does not include the User IDs and associated signatures, that 
are necessary to make a ”full” public key – those components are in 
pubring.kbx.


You are correct: key generation for asymmetric systems involves randomly 
choosing a private key and calculating the corresponding public key. The 
mathematics are such that this is easy but the reverse is believed to be 
computationally infeasible. There are a variety of "neat math tricks" to 
make the system more efficient under various conditions, but ultimately 
public keys are derived from private keys and this determines which key 
is which.


For example, RSA relies on the ease of calculating a product versus the 
presumed difficulty of factoring composites of two approximately 
similar-magnitude primes. Either key can decrypt a message encrypted by 
the other; smoothing over some mathematical and cryptographic details, 
this is used for signatures by encrypting the signature with the private 
key which allows the public key to decrypt (verify) it.


Again, the difference between the public and private keys is that, given 
the private key the public key can be calculated, while the private key 
cannot be (feasibly) calculated given the public key.


You may note that I have been very light on details; this is 
intentional. If you are unclear about a basic detail like this, you will 
almost certainly fall into one of numerous pitfalls that make asymmetric 
systems easily breakable. Do not roll your own; use an existing 
well-vetted Free program (like GPG!) instead. ***NEVER*** trust nonfree 
cryptographic software: you have no way to even begin to effectively 
audit such a "black box" for backdoors and the history of proprietary 
encryption is exceptionally bad, ranging from simple incompetence 
(proprietary algorithms tend to fall to cryptanalysis quite quickly once 
they are examined) to deliberate backdoors.



-- Jacob

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

Re: Follow-up on L'Affaire Stallman

[Jacob Bachmeyer via Gnupg-users]

Joel Rees via Gnupg-users wrote:

Can I ask what new reason to make Stallman a scapegoat has emerged?


The recent round of attacks on Stallman seem to have begun after RMS 
returned to the FSF Board.  There is some controversy over the factual 
basis for these attacks.  (In other words, there are accusations that 
the current accusations against RMS have no basis in fact and are 
basically made up.)  There was similar controversy over the events that 
led to RMS leaving the FSF Board previously.


Based on what I have seen, some of the accusations are fabricated, some 
are RMS's words twisted and taken out of context, and some are 
legitimate complaints about Stallman as a person and his past behavior.


That said, this list is supposed to be for discussion of issues related 
to the use of GPG, and RMS is not related to that, so this thread really 
should be dropped and I am only writing this so that future readers of 
the list archive will not be left hanging and thinking that that 
question was dodged.


As to your other question, I cannot speak for the motivations of other 
people.



-- Jacob

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

Re: Weak encryption keys

[Jacob Bachmeyer via Gnupg-users]

Vincent Pelletier wrote:

On Mon, 22 Mar 2021 17:32:14 -0500, Jacob Bachmeyer via Gnupg-users 
 wrote:
  
The difference is that you *know* an unencrypted key is lying around at 
risk of compromise, and you knowingly chose to take that risk when you 
chose to store the key unencrypted.



Pardon my non-gpg-familiarity, but isn't a "weak key" completely
different from a (maybe) divulged key ?
  


There are two keys involved here:  a PGP private key that is stored 
encrypted under a symmetric key.  It appears that that symmetric key has 
been found to be weak.  If an attacker can obtain the encrypted blob and 
crack the symmetric encryption, the PGP key would be divulged.



AFAIK a weak key is a key that, when used, produces a result which is
easier to break than what the cipher promises. In other word, this
would be something specific to this very key, to the value of its
components being poorly chosen, and in no way related to how it was
stored/obfuscated itself.
  


The weak key in this case is the symmetric cipher key used to encrypt 
the PGP private key.



IOW, isn't this specific key one of the identified blowfish weak keys
classes ?
  https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
Also:
  https://en.wikipedia.org/wiki/Weak_key

Meaning not only this key, but anything it signed and/or was encrypted
for (I did not check which one is affected), may be considered
compromised ?
  


The risk is that an attacker may be able to crack the encryption on the 
stored private key because it was encrypted with a weak key.  Given that 
PGP keys are very short, it is possible that Blowfish may be safe here, 
even with a weak key.  If this is the case, using an old version of GPG 
to import the affected private key and change the passphrase should fix 
the problem, since the symmetric key (and possibly algorithm) used to 
store the private key will then change.


If Blowfish is not safe under these circumstances (weak key encrypting a 
limited amount of data), then the PGP key in question should be presumed 
compromised and should be replaced.



-- Jacob

___
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.

[Jacob Bachmeyer via Gnupg-users]

Robert J. Hansen via Gnupg-users wrote:
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.


Perhaps he has turned over a new leaf; I have not had those problems in 
my interactions (admittedly all by email) with him.  Also admittedly, my 
interactions have all been relatively recent, and in contexts related to 
picking up maintaining DejaGnu, so an effort at reform would explain the 
horror stories others have told that do not match my experience.


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.


The circumstances as I understand them of that removal were quite bad 
and reappointing RMS was probably a right thing to do.  That said, I am 
somewhat troubled by the apparent inability to find another leader 
because it bodes ill for the inevitable day when reappointing RMS will 
no longer be an option.



-- Jacob

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

Re: Weak encryption keys

[Jacob Bachmeyer via Gnupg-users]

jsmith9...@gmx.com wrote:

[...]


A private key protected by weak blowfish cipher is by no means more at risk
compared to an unencrypted key, which GnuPG has no problem with.
  


The difference is that you *know* an unencrypted key is lying around at 
risk of compromise, and you knowingly chose to take that risk when you 
chose to store the key unencrypted.



Also, from what I've read about blowfish weak keys (and I admit I didn't spend
too much time on it), the attacks are unrealistic in that even though they
reduce the complexity compared to brute forcing a 128-bit key, it's still
near-impossible to retrieve the plain-text or the key itself within reasonable
amount of time. And I also recall reading that it requires a large amounts of
known plain-text and corresponding cipher-text data. In this case, it's a
unique key that's only used to encrypt a few hundred bytes of data. So the risk
of an attacker being able to just "crack" your private key based on the weakness
of the cipher key seems to be quite an overstatement.
  


I am assuming that there is some more severe problem with OpenPGP 
Blowfish key wrapping, since the situation you describe would not 
warrant the measures GPG has taken.  (In other words, I am assuming that 
the GPG developers know something here that we do not, and I believe 
that to be a reasonable assumption.)



Besides, shouldn't the assessment of the security of the key be better left to
the user? It would be totally reasonable to warn the user about the potential
risks and even make a recommendation to revoke this key. But not allowing them
to decrypt something that was previously encrypted with this key doesn't seem
justifiable even if the risks were as high as you stated.
  


You are correct that the situation you describe does not reasonably 
support completely rejecting the key.  That is the reason I expect that 
there is a problem serious enough that the key should be considered 
compromised.



-- Jacob

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

Re: Weak encryption keys

[Jacob Bachmeyer via Gnupg-users]

jsmith9810--- via Gnupg-users wrote:

Hello all,

I have a private key protected by blowfish cipher that despite a random salt and several rounds of 
RIPEMD160 iterations is still considered "weak" by GnuPG and it refuses to do anything 
with it. When I try to import this key manually (--import), gpg throws a "weak encryption 
key" error and refuses to import it. ...which I find ironic, because it has no problem 
importing unprotected plain-text keys. Also, it's worth pointing out that GnuPG applies its default 
protection scheme to the private keys imported this way regardless of what encryption these keys 
used earlier - which means that the issue that it's complaining about will actually be resolved 
simply by importing this key.

I still managed to force this key into GnuPG's private key store through the 
secring.gpg migration route which preserves the key in its openpgp-native 
format, but now gpg refuses any operation involving this private key - sign, 
encrypt, etc. It won't even let me change the password - which would actually 
make this issue go away. I tested with GnuPG 1.4.23 as well and it does not 
have a problem either importing or using this key.

I am not looking for a solution as I can easily work around this problem by changing 
password using GnuPG 1.x prior to importing this key in GnuPG 2.x, but should this be 
logged as a product defect? This doesn't look like reasonable way to deal with these 
so-called "weak" encryption keys when importing these keys would actually 
address the issue at hand.

Thanks!


The problem is that a private key protected by a weak cipher is still 
potentially compromised if an attacker can get any copy of the key prior 
to migrating it to a stronger cipher.  In other words, if an attacker is 
able to obtain your current key blob, the attacker can still compromise 
your key by cracking that copy, even after you have migrated your copy 
to a stronger wrapping.


If an attacker was interested in you, your key is lost and the best path 
forwards is to revoke it and generate a new key.  You could sign the new 
key with the old one before revoking the old key.



-- Jacob


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

Re: [EXT] Re: gnupg and ssh interaction somehow broken (card reader with pinpad)

[Jacob Bachmeyer via Gnupg-users]

Andreas K. Huettel wrote:

Am Mittwoch, 17. März 2021, 21:07:16 CET schrieb Andreas K. Huettel:
  

I'm pretty sure they didnt have different versions, sorry.
(I rebooted the machine a few minutes earlier because of a kernel update.)
OK now it's getting very strange. 

On a second PC with the same reader hardware model, the same gpg version, and 
the same chipcard, things work perfectly fine.


Could this be a hardware defect (i.e., reader was too long in the sun)?
  


Can you swap the readers between the two computers and see if the 
problem follows the suspected-bad reader?



-- Jacob


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