Den 23 jan 2015 15:44 skrev "carlo von lynX" <<a href="mailto:lynX@i.know.you.are.psyced.org">lynX@i.know.you.are.psyced.org</a>>: > > On Thu, Jan 15, 2015 at 10:06:15AM +0100, Natanael wrote: > > Den 15 jan 2015 03:47 skrev <<a href="mailto:steve@actor.im">steve@actor.im</a>>: > > > > > > Hi everyone, > > > > > > Are there some best practices for keeping all encrypted message history > > securely on server or on client for accessing them later with single > > hardware or software key like ubikey? > > > > To preserve PFS, let the client re-encrypt and upload. The client cloud > > sign or MAC the ciphertext to prevent modification. > > A more advanced way to store messages is to have them encrypted > with an incremental ratchet at creation time, so the stored > messages are interesting for only as long as the recipient has > the necessary ratchet state. The moment the recipient chooses > to no longer care to be able to access that part of the online > archives, she just forgets about past ratchet state and sticks > to a more recent one. From that point on, forward secrecy is kept. > > This idea of re-encrypting and re-uploading stuff sounds > completely bogus to me. Only makes sense if you are > desperately clinging to 80's technology. > > This entire thread sounds like you are talking about PGP messages. > If that is the case please state so - ideally in the subject, so I > know it is irrelevant for me. > > Let me know if I got something wrong or, vice versa, if this > point of view from somebody who prefers 2010 technology is > useful. > > Also, if you want more people to participate, some of the > contributors would have to turn on plain text emailing. HTML-only > mails are not going to get attention by all mailing list members. Another point is that if you don't fully trust the storage host, storing unmodified ciphertext the way it came in on the wire reveals a bit more metadata about usage than uploading blobs of multiple re-encrypted ciphertexts. Asking for specific ciphertexts to be deleted also reveals more than re-uploading a smaller ciphertext blob to replace a previous one.