logo

blog

My website can't be that messy, right? git clone https://hacktivis.me/git/blog.git
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:

Marticles/Pretty Bad Privacy.xhtml52++++++++++++++++++++++++++++++++++++++++++++++++----
Mfeed.atom2+-
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>