[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Wednesday, 16 March 2022 21:14:18 GMT Rock Storm wrote: > On Wed, 2022-03-16 at 14:10 +0000, Simon Waters wrote: > > Email generally isn't the answer, although with strong encryption it > > could be although most implementations of email encryption are pretty > > ropey (e.g. S/MIME or PGP). > > I always thought PGP was good enough. Could you please elaborate on > this? I'd be happy to try any better alternatives. The encryption is as far as I know fine if you accept the modern defaults (and haven't hard coded weaker choices in the config file). The problem is integration into, or handling of encryption in the email clients themselves. The EFail talk at Blackhat highlighted a whole bunch of issues, most of those specific ones now solved. But that was only 2018. https://www.youtube.com/watch?v=uXfxkpgRz4w Before that talk I was asked to look at a feature using PGP to send encrypted emails in an attributable fashion from an automated service, so that recipients could be confident that the email was received from the service that they had uploaded their public key too and trusted the public key of, since those emails might contain actionable advice on computer security for sensitive systems. As soon as I started testing I discovered the email client I was already using for PGP (rarely) didn't distinguish encrypted for recipient, and encrypted for recipient and signed, in the visual interface. So both got the same green indicator that the email was good and from the system, but one of those emails anyone could have created (subject to the usual spam checks) and one required the sender's private key, oops. I also found when I started making obvious changes to the encrypted emails that warnings from the decryption process were being silently dropped (which is a pity as those warnings were security relevant). It was really advanced things like including unsigned parts before and after the signed part of the email. Obviously these issues are dependent on which email client someone is using, and the signing options (but the options are often attacker's choice), but when I started looking around at alternatives for my testing I didn't find any that passed all my tests. Also most email clients include their name and version in email headers by default, so you generally don't even need to guess what tool someone is using, unless they've explicitly hardened their email beyond the defaults. So in summary I stepped back and said "how would I defeat it", constructed some trivial test cases, and found all the common implementations failed to provide the security guarantees one would expect from using public key encryption in practice. And it is not like I was some uber hacker, or uber software tester, or especially knowledgeable about PGP, it was mostly dreamt up by reading PGP documentation, drawing up a matrix of possible combinations of encrypted, signed, mail client, and trying it out. It is of course possible all these issues are now fixed in every email client, but I doubt it. Not least a lot of the integrations between PGP and mail client were a bit kludgy, rather than being a first class feature of the email client (I recall Apple's Mail app in particular, the PGP plugin at the time was a 3rd party modules working around various limitation of the Mail app from Apple, Enigmail wasn't much better). -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: https://www.dcglug.org.uk/faq/