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

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: list accepts posts under the old key for a limited time to give subscribers

  • 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

  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: the list archives will be encrypted too?

  • if the goal is to never let a list post travel unencrypted, I guess

   - 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.