commit: 4711000f0537b458e48e280f600ff17b3bed5238
parent 914d523e37ee2ba9dde495ba0a1900098c9c1889
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Thu, 7 Mar 2019 06:17:48 +0100
Add compression, ciphers, security considerations
Diffstat:
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/articles/Pretty Bad Privacy.xhtml b/articles/Pretty Bad Privacy.xhtml
@@ -8,7 +8,18 @@
<dd>Gnu Privacy Guard, main/only implementation of OpenPGP</dd>
</dl>
<h2>OpenPGP standard</h2>
-<p>The OpenPGP standard mandates that some ciphers must be present in the implementation, they are now broken and well known to be. (<abbr title="As Far As I Remember">AFAIR</abbr> it’s stuff like SHA1, 3DES, …).</p>
+<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
@@ -65,11 +76,44 @@ ID Algorithm Text Name
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>It leaks a pile of metadata (time, implementation name+version, …)</p>
+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. 3DES was broken by the EFF in 199x, 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 -->
+<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>
+<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>
+<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>Quite a lot of people are trusting <a href="https://keybase.io/">keybase.io</a> to kinda fix a part of the Web-of-Trust, I do not like this one, it seems to basically be a social-media keyserver where you give it a lot of information for “verification”, and of couse the software is proprietary and it’s centralised. 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>
diff --git a/feed.atom b/feed.atom
@@ -14,7 +14,7 @@
<link rel="alternate" type="text/html" href="/articles/Pretty%20Bad%20Privacy"/>
<id>https://hacktivis.me/articles/Pretty%20Bad%20Privacy</id>
<published>2019-03-07T01:00:04Z</published>
- <updated>2019-03-07T02:08:40Z</updated>
+ <updated>2019-03-07T05:17:48Z</updated>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<!--#include file="/articles/Pretty Bad Privacy.xhtml"-->
</div></content>
