logo

blog

My little blog can’t be this cute!

Pretty Bad Privacy.xhtml (10400B)


  1. <article lang="en">
  2. <a href="/articles/Pretty%20Bad%20Privacy"><h1>Pretty Bad Privacy</h1></a>
  3. <span class="warn">This article is in early drafting process, made public so I get comments and more people can be aware</span>
  4. <dl>
  5. <dt>OpenPGP</dt>
  6. <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>
  7. <dt>GnuPG / GPG</dt>
  8. <dd>Gnu Privacy Guard, main/only implementation of OpenPGP</dd>
  9. </dl>
  10. <h2>OpenPGP standard</h2>
  11. <h3>Compression</h3>
  12. <blockquote><pre>
  13. Furthermore, compression has the added side effect that some types of
  14. attacks can be thwarted by the fact that slightly altered, compressed
  15. data rarely uncompresses without severe errors. This is hardly
  16. rigorous, but it is operationally useful. These attacks can be
  17. rigorously prevented by implementing and using Modification Detection
  18. </pre></blockquote>
  19. <cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
  20. <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>
  21. <h3>Ciphers</h3>
  22. <p>The OpenPGP standard mandates that some ciphers must be present in the implementation, they are broken and well known to be.</p>
  23. <blockquote><pre>
  24. 9.1. Public-Key Algorithms
  25. ID Algorithm
  26. -- ---------
  27. 1 - RSA (Encrypt or Sign) [HAC]
  28. 2 - RSA Encrypt-Only [HAC]
  29. 3 - RSA Sign-Only [HAC]
  30. 16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
  31. 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
  32. 18 - Reserved for Elliptic Curve
  33. 19 - Reserved for ECDSA
  34. 20 - Reserved (formerly Elgamal Encrypt or Sign)
  35. 21 - Reserved for Diffie-Hellman (X9.42,
  36. as defined for IETF-S/MIME)
  37. 100 to 110 - Private/Experimental algorithm
  38. Implementations MUST implement DSA for signatures, and Elgamal for
  39. encryption. […]
  40. 9.2. Symmetric-Key Algorithms
  41. ID Algorithm
  42. -- ---------
  43. 0 - Plaintext or unencrypted data
  44. 1 - IDEA [IDEA]
  45. 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
  46. 168 bit key derived from 192)
  47. 3 - CAST5 (128 bit key, as per [RFC2144])
  48. 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
  49. 5 - Reserved
  50. 6 - Reserved
  51. 7 - AES with 128-bit key [AES]
  52. 8 - AES with 192-bit key
  53. 9 - AES with 256-bit key
  54. 10 - Twofish with 256-bit key [TWOFISH]
  55. 100 to 110 - Private/Experimental algorithm
  56. Implementations MUST implement TripleDES. […]
  57. 9.4. Hash Algorithms
  58. ID Algorithm Text Name
  59. -- --------- ---------
  60. 1 - MD5 [HAC] "MD5"
  61. 2 - SHA-1 [FIPS180] "SHA1"
  62. 3 - RIPE-MD/160 [HAC] "RIPEMD160"
  63. 4 - Reserved
  64. 5 - Reserved
  65. 6 - Reserved
  66. 7 - Reserved
  67. 8 - SHA256 [FIPS180] "SHA256"
  68. 9 - SHA384 [FIPS180] "SHA384"
  69. 10 - SHA512 [FIPS180] "SHA512"
  70. 11 - SHA224 [FIPS180] "SHA224"
  71. 100 to 110 - Private/Experimental algorithm
  72. Implementations MUST implement SHA-1. Implementations MAY implement
  73. other algorithms. MD5 is deprecated.</pre></blockquote>
  74. <cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
  75. <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 -->
  76. <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>
  77. <blockquote><pre>
  78. 13.4. Plaintext
  79. Algorithm 0, "plaintext", may only be used to denote secret keys that
  80. are stored in the clear. Implementations MUST NOT use plaintext in
  81. Symmetrically Encrypted Data packets; they must use Literal Data
  82. packets to encode unencrypted or literal data.
  83. </pre></blockquote>
  84. <cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
  85. <p>I guess this one is related to SigSpoof</p>
  86. <blockquote><pre>
  87. 14. Security Considerations
  88. * As with any technology involving cryptography, you should check the
  89. current literature to determine if any algorithms used here have
  90. been found to be vulnerable to attack.
  91. […]
  92. * There is a somewhat-related potential security problem in
  93. signatures. If an attacker can find a message that hashes to the
  94. same hash with a different algorithm, a bogus signature structure
  95. can be constructed that evaluates correctly.
  96. For example, suppose Alice DSA signs message M using hash algorithm
  97. H. Suppose that Mallet finds a message M' that has the same hash
  98. value as M with H'. Mallet can then construct a signature block
  99. that verifies as Alice's signature of M' with H'. However, this
  100. would also constitute a weakness in either H or H' or both. Should
  101. this ever occur, a revision will have to be made to this document
  102. </pre></blockquote>
  103. <cite><a href="https://tools.ietf.org/html/rfc4880">RFC4880</a>, November 2007</cite>
  104. <pre><code>
  105. $ gpg --version
  106. gpg (GnuPG) 2.2.10
  107. libgcrypt 1.8.3
  108. Copyright (C) 2018 Free Software Foundation, Inc.
  109. License GPLv3+: GNU GPL version 3 or later &lt;https://gnu.org/licenses/gpl.html&gt;
  110. This is free software: you are free to change and redistribute it.
  111. There is NO WARRANTY, to the extent permitted by law.
  112. Home: /home/haelwenn/.gnupg
  113. Supported algorithms:
  114. Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
  115. Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
  116. CAMELLIA128, CAMELLIA192, CAMELLIA256
  117. Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
  118. Compression: Uncompressed, ZIP, ZLIB, BZIP2
  119. </code></pre>
  120. <p>“LOL”</p>
  121. <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 -->
  122. <p>There is no deniability possible, there is quite a difference between no-authentication and deniability, to be elaborated on</p>
  123. <p>Your public key/identity <strong>will</strong> end up on the keyservers at some point, no exception.</p>
  124. <p>There is no forward secrecy</p><!-- FIXME: seems to be for online apps or similar, not email; to be verified -->
  125. <h2>OpenPGP in real life</h2>
  126. <p>Real Name policy and other stuff that should be optionnal in the Public Key Verification process (An ID card? Seriously?).</p>
  127. <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>
  128. <h2 id="keybase">Bonus: Keybase is a fuck</h2>
  129. <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>
  130. <ul>
  131. <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>
  132. <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>
  133. <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>
  134. </ul>
  135. <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>
  136. <h2>See also</h2>
  137. <ul>
  138. <li><a href="https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html">Pretty Bad {Protocol,People}</a></li>
  139. <li><a href="https://neopg.io/">NeoPG</a>, a fork of GnuPG, found SigSpoof probably more to come</li>
  140. <li><a href="http://www.netpgp.com/">NetPGP</a>, an implementation of OpenPGP by NetBSD, seems quite unmaintained to me</li>
  141. <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>
  142. <li><a href="https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html">[tor-talk] Why the Web of Trust Sucks</a></li>
  143. <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>
  144. </ul>
  145. <h2>References</h2>
  146. <ul>
  147. <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>
  148. </ul>
  149. <p><a href="https://queer.hacktivis.me/notice/9gVn61L9VGPosmXRQG">Fediverse post for comments</a></p>
  150. </article>