[Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

J.B. Nicholson jbn at forestfield.org
Sun Mar 12 20:34:17 EDT 2017


Bhavishya Desai wrote:
> Now I would like to know(specifically) what are some other threats,which
> could effect this and any difficulties with implementation.

I imagine that the encryption and/or hash algorithms will change over time 
as encryption is broken and people figure out ways to create hash 
collisions. Therefore I'd imagine keys will change over time.

I'm guessing this carries some consequences:

- the list key will change over time, therefore:
    - old subscribers need to be alerted to the new list key.
    - MUAs need to be able to make use of the current list key (perhaps the 
list accepts posts under the old key for a limited time to give subscribers 
a chance to switch to using the new key).

- subscribers' keys will change over time, therefore:
    - there needs to be an easy way for a subscriber to get the list to 
accept posts under the subscriber's new key.

- list archives raise interesting questions:
    - if the goal is to never let a list post travel unencrypted, I guess 
the list archives will be encrypted too?
       - each archive post will be signed+encrypted with the current list 
key. Therefore each archive message will be decrypted and re-encrypted at 
each list key change?
         - yes: this implies a bigger and bigger decryption/re-encryption 
job at each list key change as a list archive grows. Presumably this task 
will become computationally intensive at some point, possibly beyond the 
scale of being done at all for very large mailing lists carrying large list 
posts.

         - no: each archive post will be untouched after sending. Therefore 
archives will feature a set of list posts signed+encrypted with whatever 
list key was current at the time that post was sent out.
           - thus old list public keys must be kept around and published 
forever so archive readers can decrypt/verify signatures of archived posts?
               - yes: this carries some questions about GPG policy (below).
               - no: how will this work?

- GPG policy issues: the above raises questions about GPG:
    - will GPG keep old encryption algorithms and hash algorithms around 
(perhaps warning not to use them for new keys, and only using them for 
decryption as needed)?
       - or users going to need to retain old versions of GPG to handle 
verifying archive list posts old encrypted & signed with list keys (I don't 
see this working out well)?

It's possible there is something fundamental about this entire process I do 
not understand and therefore I've completely missed something about this 
process which led me down a path I should not have gone down. If that's the 
case, please do let me know where I went wrong.

Thanks.


More information about the Mailman-Developers mailing list