Pretty Bad Privacy.xhtml - blog - My website can't be that messy, right?

Pretty Bad Privacy.xhtml (10487B)

<!--
Copyright © 2014 Haelwenn (lanodan) Monnier
SPDX-License-Identifier: LAL-1.3
-->
<article lang="en">
<a href="/articles/Pretty%20Bad%20Privacy"><h1>Pretty Bad Privacy</h1></a>
<span class="warn">This article is in early drafting process, made public so I get comments and more people can be aware</span>
<dl>
	<dt>OpenPGP</dt>
	<dd>Pretty Good Privacy standard, derives from the original PGP implementation. "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation. The term "OpenPGP" refers to the protocol described in this and related documents.</dd>
	<dt>GnuPG / GPG</dt>
	<dd>Gnu Privacy Guard, main/only implementation of OpenPGP</dd>
</dl>
<h2>OpenPGP standard</h2>
<h3>Compression</h3>
<blockquote><pre>
   Furthermore, compression has the added side effect that some types of
   attacks can be thwarted by the fact that slightly altered, compressed
   data rarely uncompresses without severe errors.  This is hardly
   rigorous, but it is operationally useful.  These attacks can be
   rigorously prevented by implementing and using Modification Detection
</pre></blockquote>
<cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
<p>Not sure about this one, I’ll go check but this cause few issues in SSH and TLS, so I wouldn’t be surprised that it was also the case for OpenPGP.</p>
<h3>Ciphers</h3>
<p>The OpenPGP standard mandates that some ciphers must be present in the implementation, they are broken and well known to be.</p>
<blockquote><pre>
9.1.  Public-Key Algorithms
ID           Algorithm
--           ---------
1          - RSA (Encrypt or Sign) [HAC]
2          - RSA Encrypt-Only [HAC]
3          - RSA Sign-Only [HAC]
16         - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17         - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18         - Reserved for Elliptic Curve
19         - Reserved for ECDSA
20         - Reserved (formerly Elgamal Encrypt or Sign)
21         - Reserved for Diffie-Hellman (X9.42,
             as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm
Implementations MUST implement DSA for signatures, and Elgamal for
encryption. […]
9.2.  Symmetric-Key Algorithms
ID           Algorithm
--           ---------
0          - Plaintext or unencrypted data
1          - IDEA [IDEA]
2          - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
             168 bit key derived from 192)
3          - CAST5 (128 bit key, as per [RFC2144])
4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5          - Reserved
6          - Reserved
7          - AES with 128-bit key [AES]
8          - AES with 192-bit key
9          - AES with 256-bit key
10         - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm
Implementations MUST implement TripleDES. […]
9.4.  Hash Algorithms
ID           Algorithm                             Text Name
--           ---------                             ---------
1          - MD5 [HAC]                             "MD5"
2          - SHA-1 [FIPS180]                       "SHA1"
3          - RIPE-MD/160 [HAC]                     "RIPEMD160"
4          - Reserved
5          - Reserved
6          - Reserved
7          - Reserved
8          - SHA256 [FIPS180]                      "SHA256"
9          - SHA384 [FIPS180]                      "SHA384"
10         - SHA512 [FIPS180]                      "SHA512"
11         - SHA224 [FIPS180]                      "SHA224"
100 to 110 - Private/Experimental algorithm
Implementations MUST implement SHA-1.  Implementations MAY implement
other algorithms.  MD5 is deprecated.</pre></blockquote>
<cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
<p>Some additionnal ciphers got added later on, but this basically mean that you cannot be sure that a OpenPGP message you sent wasn’t done in more-or-less plaintext. DES was broken by the EFF in 199x, 3DES is basically now on about the same size (NIST: 80 bits of security) but computing power got much better, SHA1 was probably still known as okay but could be better (as SHA2 was already a thing), DSA was probably not now enough as good to be hardcoded, no idea for Elgamal.</p><!-- FIXME -->
<p>I tried few years ago to build a GnuPG without support for theses broken ciphers, and I failed doing so. One can note that SSH requires 3DES-CBC, but it can be disabled or non-implemented (<a href="https://tinyssh.org/">tinyssh</a>).</p>
<blockquote><pre>
13.4.  Plaintext
   Algorithm 0, "plaintext", may only be used to denote secret keys that
   are stored in the clear.  Implementations MUST NOT use plaintext in
   Symmetrically Encrypted Data packets; they must use Literal Data
   packets to encode unencrypted or literal data.
</pre></blockquote>
<cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
<p>I guess this one is related to SigSpoof</p>
<blockquote><pre>
14.  Security Considerations
   * As with any technology involving cryptography, you should check the
     current literature to determine if any algorithms used here have
     been found to be vulnerable to attack.
[…]
   * There is a somewhat-related potential security problem in
     signatures.  If an attacker can find a message that hashes to the
     same hash with a different algorithm, a bogus signature structure
     can be constructed that evaluates correctly.
     For example, suppose Alice DSA signs message M using hash algorithm
     H.  Suppose that Mallet finds a message M' that has the same hash
     value as M with H'.  Mallet can then construct a signature block
     that verifies as Alice's signature of M' with H'.  However, this
     would also constitute a weakness in either H or H' or both.  Should
     this ever occur, a revision will have to be made to this document
</pre></blockquote>
<cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
<pre><code>
$ gpg --version
gpg (GnuPG) 2.2.10
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later &lt;https://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/haelwenn/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
</code></pre>
<p>“LOL”</p>
<p>It leaks a pile of metadata (time, implementation name+version, …)</p><!-- FIXME: details of data present into my public key and key-change message signature -->
<p>There is no deniability possible, there is quite a difference between no-authentication and deniability, to be elaborated on</p>
<p>Your public key/identity <strong>will</strong> end up on the keyservers at some point, no exception.</p>
<p>There is no forward secrecy</p><!-- FIXME: seems to be for online apps or similar, not email; to be verified -->
<h2>OpenPGP in real life</h2>
<p>Real Name policy and other stuff that should be optionnal in the Public Key Verification process (An ID card? Seriously?).</p>
<p>The keyservers/Web-of-Trust is architecturaly vunerable to a DoS by spam. <a class="ref" href="#ref-keyservers.md">keyservers.md</a></p>
<h2 id="keybase">Bonus: Keybase is a fuck</h2>
<p>Keybase is what you get when you want crypto (just the math), but you do not care about security (they are called secrets for a reason) or privacy (social-media with a cryptographically verified graph that lives forever…).</p>
<ul>
	<li>It got bought by Zoom, which is known-bad/evil for privacy. (<a href="https://en.wikipedia.org/wiki/Zoom_Video_Communications#Criticism">Zoom Video Communications - Wikipedia</a>)</li>
	<li>You are encouraged to upload your private keys to them, with <a href="https://keybase.io/triplesec">their own algorithm</a>) and it is hard to revoke (Please revoke your key and create another): <a href="https://github.com/keybase/keybase-issues/issues/160">Uploading private keys puts users at risk, keybase/keybase-issues#160</a>, <a href="https://github.com/keybase/keybase-issues/issues/731">Can't revoke the proof from web, keybase/keybase-issues#731</a> (note: even after revocation it could still be verified, revocation being advisory), <a href="https://github.com/keybase/keybase-issues/issues/1946">GPG smartcard security bypassed by delegated private key, keybase/keybase-issues#1946</a>, <a href="https://github.com/keybase/keybase-issues/issues/1912">How to export private key from keybase with API or kbpgp.js?, keybase/keybase-issues#1912</a></li>
	<li>It is centralised (and so proprietary) and harms decentralisation. For example: pleroma basically can’t have keybase integration because the instances are too small, lol, mastodon instances are way too big.</li>
</ul>
<p>As an alternative (and if you still want OpenPGP), I think putting your fingerprint everywhere you can and putting you minimal public key on your blog is a much better way, and it can be automatised a bit (OPENPGPKEY DNS record, IndieWeb <code>rel="openpgp"</code>, …).</p>
<h2>See also</h2>
<ul>
	<li><a href="https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html">Pretty Bad {Protocol,People}</a></li>
	<li><a href="https://neopg.io/">NeoPG</a>, a fork of GnuPG, found SigSpoof probably more to come</li>
	<li><a href="http://www.netpgp.com/">NetPGP</a>, an implementation of OpenPGP by NetBSD, seems quite unmaintained to me</li>
	<li><a href="https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/">What’s the matter with PGP? - A Few Thoughts on Cryptographic Engineering</a></li>
	<li><a href="https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html">[tor-talk] Why the Web of Trust Sucks</a></li>
	<li><a href="https://sweet32.info">Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN</a>, which Triple-DES and Blowfish are vulnerable to</li>
</ul>
<h2>References</h2>
<ul>
	<li><a name="ref-keyservers.md" href="https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f">SKS Keyserver Network Under Attack</a> by <a href="https://gist.github.com/rjhansen">Robert J. Hansen</a></li>
</ul>
<p><a href="https://queer.hacktivis.me/notice/9gVn61L9VGPosmXRQG">Fediverse post for comments</a></p>
</article>