Re: Big curiosity

[Michał Górny via Gnupg-users]

On Sun, 2021-06-13 at 14:06 +, knighttemplar5--- via Gnupg-users
wrote:
> I have been contemplating subscribing to an email forwarding service that 
> will encrypt all the forwarded mails to me with my public key.
> Lets imagine the country where the forwarding takes place can see all my 
> emails in plain text and at the same time the same emails PGP encrypted, can 
> enough of this data pose a threat to my private key?I mean in theory at list? 
> I just love learning about this stuff but I m not good enough in math to have 
> an informed opinion.
> 

Let me answer from a little different perspective.  Anyone can generate
some piece of text and encrypt it using your public key.  There is
nothing special about encrypting your mails vs encrypting arbitrary
data.  So if that were a problem, access to your mails would be entirely
irrelevant to it.

-- 
Best regards,
Michał Górny



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

Re: [Announce] GnuPG 2.2.22 released

[Michał Górny via Gnupg-users]

On Fri, 2020-08-28 at 21:39 +0200, mlnl via Gnupg-users wrote:
> Hi,
> 
> today, i have compiled 2.2.22 under Debian Buster. Decryption of
> files fail in terminal. Decryption of e-mails with Claws-Mail fail too.
> For Claws i had compiled and installed gpgme-1.12.1. I'm using a Yubikey
> for key storage & usage. Works flawless with GnuPG 2.2.21.
> 
> From my gpg-agent.log:
> 
> 2020-08-28 21:20:46 gpg-agent[23604] SIGUSR2 received - updating card event 
> counter
> 2020-08-28 21:20:46 gpg-agent[23604] DBG: chan_11 <- ERR 100663297 
> Allgemeiner Fehler  
> 2020-08-28 21:20:46 gpg-agent[23604] smartcard decryption failed: Allgemeiner 
> Fehler 
> 2020-08-28 21:20:46 gpg-agent[23604] command 'PKDECRYPT' failed: Allgemeiner 
> Fehler 
> 2020-08-28 21:20:46 gpg-agent[23604] DBG: chan_10 -> ERR 100663297 
> Allgemeiner Fehler 
> 
> 2020-08-28 21:21:05 gpg-agent[23604] smartcard decryption failed: Dateiende
> 2020-08-28 21:21:05 gpg-agent[23604] command 'PKDECRYPT' failed: Dateiende 
> 2020-08-28 21:21:05 gpg-agent[23604] DBG: chan_10 -> ERR 67125247 Dateiende 
> 
> 
> 2020-08-28 21:21:13 gpg-agent[23604] error accessing card: Datenübergabe 
> unterbrochen (broken pipe)
> 2020-08-28 21:21:13 gpg-agent[23604] smartcard decryption failed: 
> Datenübergabe unterbrochen (broken pipe)
> 2020-08-28 21:21:13 gpg-agent[23604] command 'PKDECRYPT' failed: 
> Datenübergabe unterbrochen (broken pipe)
> 2020-08-28 21:21:13 gpg-agent[23604] DBG: chan_10 -> ERR 67141741 
> Datenübergabe
> unterbrochen (broken pipe) 
> 
> I went back to 2.2.21.
> 

Maybe it's the same root cause as https://dev.gnupg.org/T5039

-- 
Best regards,
Michał Górny



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: [Announce] GnuPG 2.2.22 released

[Michał Górny via Gnupg-users]

On Fri, 2020-08-28 at 21:39 +0200, mlnl via Gnupg-users wrote:
> Hi,
> 
> today, i have compiled 2.2.22 under Debian Buster. Decryption of
> files fail in terminal. Decryption of e-mails with Claws-Mail fail too.
> For Claws i had compiled and installed gpgme-1.12.1. I'm using a Yubikey
> for key storage & usage. Works flawless with GnuPG 2.2.21.
> 

I suppose I'm hitting the same problem.  With 2.2.22, I need to manually
run 'gpg --card-status' after rebooting to get Nitrokey working.

-- 
Best regards,
Michał Górny



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: In case you use OpenPGP on a smartphone ...

[Michał Górny via Gnupg-users]

On Mon, 2020-08-10 at 17:14 +0200, Stefan Claas wrote:
> ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users wrote:
>  
> > 10/08/20 09:07 ನಲ್ಲಿ, Stefan Claas  ಬರೆದರು:
> > > Matthias Apitz wrote:
> > > 
> > > > El día domingo, agosto 09, 2020 a las 10:06:13p. m. +0200, Stefan Claas 
> > > > escribió:
> > > > 
> > > > > > This article showed up today, when I did a Google search again:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Trustworthy source.
> > > > > 
> > > > > Mmmhhh, it is getting 'better and better' for smartphone users.
> > > > > 
> > > > > https://www.androidauthority.com/government-tracking-apps-1145989/
> > > > > 
> > > > 
> > > > One can use a Linux mobile phone running UBports.com (as I and all my 
> > > > family do)
> > > > or the upcoming Puri.sm L5 (as I pre-ordered in October 2017).
> > > 
> > > Yes, people gave me already (not from here of course) good advise for 
> > > other OSs
> > > which one can use. The question is how long will those OSs been 
> > > unaffected ...
> > > 
> > > > Stop whining, stand up and fight and protect yourself.
> > > 
> > > I am not whining ... I only wanted to let the people know. Also very
> > > interesting that only one person in this thread replied, besides you ...
> > 
> > I was wary of storing my private GPG keys on my phone (if only because of 
> > theft/loss/etc), so I set up my keys on a Yubikey
> > and use that to decrypt stuff on my phone. From what I understand, even if 
> > they were to obtain secrets decrypted by the
> > Yubikey or exfiltrate private files, they would not be able to actually 
> > decrypt them given that the key resides on the
> > Yubikey (if the private key were on the phone itself, they'd "just" have to 
> > crack the passphrase or whatever, which would
> > presumably be much easier...).
> > 
> > Just another way to mitigate the risk of stuff like this.
> 
> Well, I do have YubiKeys and a Nitrokey too, but I would say while they can't 
> obtain your private key they will for sure
> know the passphrase (PIN) used and the content you encrypted/decrypted on 
> your smartphone.
> 
> I came up yesterday with the idea to use an additional offline laptop[1] 
> connected to my smartphone via a USB OTG cable
> and an FTDI USB to USB cable, costs for both less then 20 USD. When both 
> devices are connected one uses on the laptop
> CoolTerm (cross-platform) and on the Android device serial usb terminal, 
> available on the PlayStore.
> 
> As of my understanding (please someone proofs me wrong) an attacker would 
> have a hard time to know the encrypted content
> created on the offline laptop.
> 

Why use PGP on your phone if you carry a whole laptop with you anyway?

-- 
Best regards,
Michał Górny



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: Accidentally deleted ~/.gnupg/pubring.gpg

[Michał Górny via Gnupg-users]

On Sun, 2020-07-05 at 14:30 +, renws via Gnupg-users wrote:
> Hi,
> 
> I've accidentally deleted ~/.gnupg/pubring.gpg and now I'm not able to see 
> any output from `gpg --list-keys' and `gpg --list-secret-keys'.
> 
> Is it possible to still use my private key to decrypt previously encrypted 
> .gpg files? Are private keys stored in ~/.gnupg/private-keys-v1.d ? If so how 
> can I make use of it?
> 

Reimport your public key and things should start working again.  You may
look if ~/.gnupg doesn't contain a backup copy, or fetch it from
keyservers, someone who used it, etc...


-- 
Best regards,
Michał Górny



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: Biometrics

[Michał Górny via Gnupg-users]

On Mon, 2020-05-25 at 10:01 +0200, Peter Lebbing wrote:
> On 25/05/2020 09:47, Michał Górny wrote:
> > ...and that's really a good thing they can do that instead of choosing
> > a more painful way of getting your fingerprints.
> 
> How is that an advantage compared to passphrases? As soon as someone
> threatens to go all XKCD 538 on you[1], just give them your passphrase.
> No need to lend them your finger, either with or without you still
> attached.
> 
> If this is your threat model, you need more than encryption or
> biometrics.
> 
> ... unless your whole comment was as serious as my comment about plastic
> surgery of course :-) ...

It was.

> More seriously, biometrics might be a nice deterrant to the casual
> opportunistic curious peeker. It's quick, a finger swipe takes less time
> and effort than a good passphrase. But it's not proper security in my
> book.
> 

I wholeheartedly agree with you.

-- 
Best regards,
Michał Górny



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: Backup of Keys

[Michał Górny via Gnupg-users]

On Mon, 2020-05-25 at 09:36 +0200, Peter Lebbing wrote:
> On 24/05/2020 21:39, Mark wrote:
> > I know there are other options maybe even some that use
> > biometrics to decrypt the database.
> 
> I am very wary of biometrics for authentication purposes. There are so
> many examples where the vendor assured us it was working really well,
> and researchers easily cracked the system by using a photo, or
> photocopied fingerprints they lifted off a glass or even more funny from
> the fingerprint reader itself.

...and that's really a good thing they can do that instead of choosing
a more painful way of getting your fingerprints.

-- 
Best regards,
Michał Górny



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: Best Keyserver

[Michał Górny via Gnupg-users]

On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
> I know this may be a subjective question but what is the best keyserver
> to use?  I use GPG4Win with the Enigmail plugin for Thunderbird.  The
> keyservers listed in Enigmail are:
> 
> vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net,
> hkps://pgp.mit.edu
> 
> The keyserver that is used in Kelopatra (GPG4Win) is:
> 
> hkp://keys.gnupg.net

$ host keys.gnupg.net
keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net.

-- 
Best regards,
Michał Górny



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: Updating of Keys

[Michał Górny via Gnupg-users]

W dniu pon, 11.05.2020 o godzinie 17∶22 -0700, użytkownik Mark napisał:
> Kinda of a stupid question here about updating your keys. I'm curious
> as
> to what changes would require you to re-upload it to a keyserver.   
> 
> I assume updating the passphrase would not because that is tied to
> the
> private key but does it change anything in the public key where that
> might be require it to be updated? 

No, this does not change anything about the public key.

> How about changing the expiration date of the primary and secondary
> keys? I assume that would be needed to be updated to the keyserver. 

Yes, that adds new signatures to the key that need to be uploaded for
new expiration dates to be seen by other people.

> Which then brings me to another question, what happens when you
> re-upload your key to a keyserver. Does it overwrite the older one or
> ??
> 

This depends on the keyserver implementation.  Generally, the new key
gets merged into the old one.  Sometimes the stale data is cleaned up,
sometimes it remains.  The same happens when you fetch updated key
from the keyserver.

-- 
Best regards,
Michał Górny



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: monkeysign removal from bullseye

[Michał Górny via Gnupg-users]

On Sat, 2020-03-21 at 23:39 +, Andrew Gallagher wrote:
> It would appear that the python2/3 migration dumpster fire has claimed
> yet another good package[1]:
> 
> ```
> > Hi,
> > Has there been further development? Otherwise I'd suggest to remove
> monkeysign
> > for now, it's blocking the removal of pygtk (and in turn a few other
> libraries)
> > and it can still be re-introduced by bullseye release if it gets ported.
> 
> i'm sorry to say there has been no progress and must now admit this is
> the only short term solution.
> ```
> 
> I cannot stress enough how awesome monkeysign is. I have a pet project
> that is only reasonably possible because of its existence, and which I
> will have to abandon if monkeysign becomes unmaintained.
> 
> How much work would be involved in getting it back into production? I'm
> not a python programmer (the python2/3 migration catastrophe has put me
> off ever wasting my brain cells on it) but I might be willing to suffer
> it for this one project.
> 

Gentoo has removed it back in 2018.  It says:

| Please use caff from app-crypt/signing-party instead.

Maybe that's an option for you as well.

-- 
Best regards,
Michał Górny



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: Proposal - variable line width for ASCII armor output

[Michał Górny via Gnupg-users]

On Wed, 2020-02-26 at 13:34 -0500, vedaal via Gnupg-users wrote:
> 
> On 2/26/2020 at 11:27 AM, "Stefan Claas via Gnupg-users" 
>  wrote:
> 
> > I like to make a proposal for future versions of GnuPG,
> > where a user can change the line witdh of ASCII armor
> > output.
> 
> =
> 
> It would not be compatible with older versions.
> 
> The simplest thing for you, (or any users who prefer the aesthetics of a 
> particular custom line width),
> would be to first make the GnuPG ascii armored message, then change it as you 
> want to and copy, paste, and post,
> with a little note of how to change it back for verification.
> 

Why 'change it back'?  Unless I'm mistaken, GPG shouldn't have any real
problem with a different base64 width, as long as the overall layout is
preserved.  I've just did a quick test and GPG is entirely happy with
the result after rewrapping at 50 chars, as well as after cheap
rewrapping with uneven lines.

-- 
Best regards,
Michał Górny



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

Is replacing a revoked signature valid?

[Michał Górny via Gnupg-users]

Hi,

Gentoo recently started signing UIDs on the keys of our developers.
As part of the system, we revoke signatures of developers who resign. 
However, some eventually return and if they return with the same key,
we have a problem.

When I try to sign the key (again), I get the following error:

"[redacted] " was already signed by key 
Nothing to sign with key XXX
gpg: Key not changed so no update needed.


However, the original signature was revoked, so it's obviously no longer
valid.  Now, I am able to work around this by deleting the old
signatures from local copy of the key, and signing it afterwards.  After
refreshing to get the old signature back along with its revocation, GPG
seems to still consider the key valid (wrt new signature).

My question: is the end result correct?  That is, is it portable to have
two signatures made using the same key, with one of them revoked
and the other not?  Is GnuPG refusing to make a new signature when
the old one is revoked a bug?

-- 
Best regards,
Michał Górny



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

Using WKD via http_proxy without DNS server available

[Michał Górny via Gnupg-users]

Hello,

We received a report from one of our users who was unable to get GnuPG
to fetch keys from behind a HTTP proxy [1].  From our investigation, it
seems that GnuPG does not even try to use the proxy if the system does
not have a DNS server configured.  In particular, the log posted at [2]
states:

  2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 <- WKD_GET -- 
infrastruct...@gentoo.org
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: libdns initialized
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: 
resolve_dns_name(openpgpkey.gentoo.org): Server indicated a failure
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: dns: 
getsrv(_openpgpkey._tcp.gentoo.org): Server indicated a failure
  2019-10-17 16:28:05 dirmngr[17549.6] command 'WKD_GET' failed: Server 
indicated a failure 
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 -> ERR 219 Server indicated 
a failure 
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 <- BYE
  2019-10-17 16:28:05 dirmngr[17549.6] DBG: chan_6 -> OK closing connection
  2019-10-17 16:28:05 dirmngr[17549.6] handler for fd 6 terminated

FWICS the problem is that dirmngr aborts immediately upon getting DNS
error.  Could it be changed to proceed as if no DNS records were
received, and attempt to perform the request via proxy?  TIA.


[1] https://bugs.gentoo.org/661376
[2] https://bugs.gentoo.org/661376#c31

-- 
Best regards,
Michał Górny



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: FAQ: seeking consensus

[Michał Górny via Gnupg-users]

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

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

-- 
Best regards,
Michał Górny



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: FAQ: seeking consensus

[Michał Górny via Gnupg-users]

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

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

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

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

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

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

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

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

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

-- 
Best regards,
Michał Górny



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: Android

[Michał Górny via Gnupg-users]

On Wed, 2019-10-16 at 13:02 +0200, Daniel Bossert wrote:
> Hi
> 
> Is anybody using pgp on Android? I did some years ago, would like to, but am 
> afraid of security reason.
> 
> I have safed my keys on my laptop only.
> 
> How are you handling it in ages of mobiles?
> 

Get yourself a hardware key, and use that.  I've been successfully using
USB NitroKey with OpenKeychain (for mail) and TermBot, though I admit
it's not the most convenient solution.  FWIH, NFC keys are more
convenient; that is, if someone considers it safe to keep NFC enabled
with Google Pay installed.

-- 
Best regards,
Michał Górny



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: robots.txt and archiveteam.org...

[Michał Górny via Gnupg-users]

On Sun, 2019-07-07 at 07:22 +0700, Konstantin Boyandin via Gnupg-users
wrote:
> I believe this subject is way off the mailing list, but just my 5 cents.
> 
> 1. GDPR, as any other bloated, convoluted, written in inhuman juridical 
> language law, mostly benefits two kinds of people: lawyers and 
> government-related officials. It incurs a lot of ado and expenses, gives 
> vast grounds for power abuse and so on and so forth.

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

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

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

> As many such laws (the closest example of similarly inadequate law is 
> Russian Federal Law #152, "On personal data") are introduced worldwide, 
> they will strike a lethal blow to majority of small and medium 
> businesses, and cripple the base of normal human communication.
> 

Exactly.  Some companies just close, some live hoping their non-
compliance won't be caught.  And by 'non-compliance', I'm not talking
about personal data abuse, just not meeting the nonsense.

--  
Best regards,
Michał Górny



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: SKS and GnuPG related issues and possible workarounds

[Michał Górny via Gnupg-users]

On Wed, 2019-07-03 at 03:01 -0700, Mirimir via Gnupg-users wrote:
> On 07/02/2019 11:42 PM, Michał Górny wrote:
> > Then, they may decide to start mass poisoning other keys just to 
> > prove this is not the right solution.
> 
> If what I propose is workable, attackers can poison as many keys as they
> like. Until SKS keyservers go down, anyway. Until then, if the system
> catches them quickly enough, they won't do widespread damage. They'll
> inconvenience some people, of course, but that seems unavoidable. And as
> an extra benefit, this would nuke file systems that store data in
> signatures.
> 

I'm afraid you are underestimating those people.  The way I see it,
the number of poisoned OpenPGP keys will grow quick enough to remove all
valid keys from SKS keyservers, and render them practically useless.


-- 
Best regards,
Michał Górny



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: SKS and GnuPG related issues and possible workarounds

[Michał Górny via Gnupg-users]

Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users 
 napisał(a):
>On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote:
>> Hello All,
>> 
>> After having read the recent multitude of messages related to SKS
>> keyservers related issue, I figured out that
>> 
>> a. The entire SKS keyservers design and interaction has a fundamental
>> design flaw named "unlimited resources assumption". I.e., it is
>assumed
>> every server, every client has unlimited resources (to store
>signatures;
>> to retrieve and process them - unlimited RAM/storage, unlimited
>network
>> speed).
>
>Either that, or it's the assumption that people won't do bad things.
>That was apparently a common assumption, back in the day.
>
>> b. It is only a matter of time when other certificates are under
>attack.
>> When the ones used by, say, Linux distributions to sign packages are
>> affected, that will cause another wave of chaos. So the only valid
>> option is to stop using current (the one written in OCaml) keyserver
>> implementation and return to stone-age practice of manually sending
>them.
>
>Yes. I gather that people working on really key stuff have likely been
>very aware of this issue, perhaps for years, and are protected. But
>there are probably many who were/are unaware, and are vulnerable.
>
>I don't think that it's necessary to stop using SKS keyservers. And I
>suspect that doing so would be nontrivial. Given that requests to them
>are likely hard-coded, or buried in obscure options and preferences.
>Stuff that nobody has touched for years.
>
>I believe that the most practical approach is 1) efficiently finding
>toxic keys, and 2) reconfiguring keyservers not to serve them. I get
>that many find this distasteful, doing the attackers' work for them,
>etc, etc, etc. But it would limit damage, to the extent that toxic keys
>can be identified soon enough. And there are other ways to share good
>copies of those keys. Via Keybase, for example. Or as you say,
>manually.

I don't think this is going to work long term. Even if you manage to somehow 
synchronously control all servers in SKS rotation, there's no way to prevent 
attackers from poisoning them over and over again.

Then, they may decide to start mass poisoning other keys just to prove this is 
not the right solution.

>
>> c. More or less valid approach would be to
>> - when exchanging with keyserver, only load/transmit signatures for
>> certificates in the user's keyring. To withstand traffic and other
>> resources waste, client should pass known certificates footprints
>first,
>> to only get from a keyserver the relevant signature
>> - implement local black/white lists feature - to able to filter out
>the
>> signatures while processing them
>
>I doubt that solutions depending on client behavior could ever work.
>
>> d. The above, or any other approach is hard to implement in
>foreseeable
>> future, even harder to make a de facto standard.
>
>It doesn't need to be a new standard. People have been working or that
>for years, and there's been much progress. But apparently there's
>nothing yet that satisfies all use cases.
>
>> Personally, I am mostly concerned with b. at the moment. And if
>approach
>> "data came, data stay" remains in effect for keyservers, they will
>> merrily be flooded with junk certificates/signatures. I can see no
>easy
>> means to prevent that, without wasting resources of human users.
>
>Same here about b. But from what little I know about SKS keyservers,
>"data came, data stay" ain't gonna change. So they'll just need to
>handle the junk. But it's arguably good enough if they can not serve
>junk to client apps that can't handle it.
>
>> Am I wrong - perhaps there are brighter alternatives?
>> 
>> Thanks.
>> 
>> Sincerely,
>> Konstantin Boyandin
>> 
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
>
>___
>Gnupg-users mailing list
>Gnupg-users@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-users

(I'm replying from phone, sorry about lack of line wrapping and uncut quote)
--
Best regards, 
Michał Górny

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

Re: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Fri, 2019-06-14 at 10:12 +0200, Oscar Carlsson via Gnupg-users wrote:
> I'm generally curious on your opinions on the latest new keyserver, this 
> time running a new software than the normal keyservers.
> 
> They seem to have a different model which minimize the amount of 
> information available, to be compliant with GDPR and friends. Do you 
> think there are any downsides to this?
> 

Others have already somewhat pointed this out but I believe it hasn't
been emphasized enough: in my opinion, stripping third-party signatures
entirely is a no-go.  I'd go ever as far as to say this key server is
harmful to OpenPGP users, and defeats the purpose of using OpenPGP.

I agree that WoT is nowhere near perfect, and that it is confusing to
a lot of simple users.  However, it's the best solution for validating
keys that we have right now.  With keys.openpgp.org implicitly stripping
third-party signatures on one hand, and explicitly requiring e-mail
verification on the other, it effectively shifts the security model into
trusting e-mail verification done by the server software.

I'm not saying that people running the server encourage that in any way.
I'm saying that it's going to happen to a larger degree than before
because users will be making the wrong assumptions.  In other words, if
users see that the particular key will be associated with the e-mail
address only once that address is verified, some of them will also
assume that if the e-mail address is present, then it is reliably
confirmed.

-- 
Best regards,
Michał Górny



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: New keyserver at keys.openpgp.org - what's your take?

[Michał Górny via Gnupg-users]

On Tue, 2019-06-25 at 16:30 +0200, Vincent Breitmoser via Gnupg-users
wrote:
> > Hi @ll.
> 
> Hi Dirk,
> 
> thanks for your thoughts!
> 
> > I don't think it's such a good idea to drop Signatures on keys.
> 
> As mentioned in our FAQ, the reason we don't support those is that with the 
> SKS
> model, anyone can attach arbitrary data to others' keys.  It's hard to 
> overstate
> how problematic that is. I can just add a megabyte or fifty of data to your 
> key.
> 
> There are solutions that still allow for some of the TPS-based use cases, but
> until there is at least some agreement on how to proceed, we decided against
> supporting them.
> 
> Free distribution of arbitrary TPSes is quite simply not a viable model for 
> any
> keyserver. The discussion shouldn't be about liking or disliking them, it 
> should
> be about what alternatives could be.
> 
> I see from your signing policy that you do a caff-style workflow. Have you
> considered the option to have keys cross-sign third party signatures for
> publication? It's a very slight switch in tooling if we assume a caff 
> workflow,
> but that way each key remains in control of the public version of itself.
> 

I honestly neither like the idea of requiring the 'first party' to
explicitly confirm all signatures, nor losing compatibility with
existing software in order to implement that.  The latter should be
quite obvious so I'll focus on the former.

In Gentoo we're using a CA-like model with a central service signing
UIDs of all developers.  It is *convenient* for it to be able to inject
those signatures into keys of the developers, and distribute them along
with them.  If we required developers to explicitly import
the signature, certify it and upload the key I'm pretty sure our
coverage would go down because people simply won't care.  The problem is
that this bites not developers who don't care much but users who lose
the ability to verify the key easily.

As an alternative: since keys.openpgp.org makes keys without verified e-
mail addresses practically useless, why not permit only those signatures
that were made using a key that's on keys.o.o and has at least single
verified e-mail address?  If you combine that with accepting only one
signature per certifying key (i.e. pruning old signatures), it should be
'good enough'.  That is, as long as attackers won't decide to create
and verify humongous number of e-mail addresses.

This could work fine alongside 'first-party attested blah blah' model,
or at least work as an interim solution until the latter is widely
deployed.

-- 
Best regards,
Michał Górny



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: Your Thoughts

[Michał Górny via Gnupg-users]

On Mon, 2019-07-01 at 15:38 +0100, Andrew Gallagher wrote:
> On 2019/07/01 15:13, Stefan Claas via Gnupg-users wrote:
> > I agree with Professor Green. Maybe he and his students can
> > program a POC something more simple, preferably in Golang and
> > while using the NaCl* library.
> 
> Golang? Not Rust? :-P
> 
> I do find it odd how many projects make such a big deal of what language
> they're written in. It shouldn't matter what language you use so long as
> it works (and is memory safe).

I do find it odd how many projects choose exotic languages and then
become defunct because few years later nobody wants to touch them. 
Presuming you're still able to build them.  It's ironic people still
don't see that even though SKS has just proven an example of that.

-- 
Best regards,
Michał Górny



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: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Michał Górny via Gnupg-users]

On Mon, 2019-07-01 at 12:18 +0200, Bernhard Reiter wrote:
> Am Montag 01 Juli 2019 01:36:41 schrieb Robert J. Hansen:
> > Now we've got Autocrypt, WKD, and Hagrid: of these Autocrypt is probably the
> > most mature and the easiest for email users.
> 
> The problem with autocrypt are the cases where its security measures are 
> tested. There is not good way to interact with the users in those cases.
> I know this is not parts of its design goals, but it works against a better
> user experience.
> 
> The progrem with hagrid (from what I've heard) is that it is again an attempt 
> of a validating keyserver, which means it has to centralize the trust 
> function or there is no point in the validation.
> 
> This makes WKD most mature and easiest for users in my eyes. (I was involved 
> in its design.).
> 

I agree.  This is precisely why we've decided it for syncing
distribution keys in Gentoo.  However, the main problem with WKD right
now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD
-- we had to employ a large hack to do it.

-- 
Best regards,
Michał Górny



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