<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 8 dec. 2016 2:10 em skrev "Phillip Hallam-Baker" <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>>:<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default">All documents should be signed but only confidential documents need to be or should be encrypted.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There's another problem too. Not all signatures should be permanent, nor public. </div><div dir="auto"><br></div><div dir="auto">Sometimes integrity and authentication needs to be ephemeral. Most people have already acknowledged that for IM (Signal), but seems to forget it (or at least doesn't mention it) as soon as the context is changed. </div><div dir="auto"><br></div><div dir="auto">I want to know my drafts aren't tampered with as I work on them over time, but I do not want anybody to be able to tie them to me after the fact. I want to chose when to make something publicly / irrevocably tied to me. No more information should be revealed (provable) than necessary. </div><div dir="auto"><br></div><div dir="auto">We could already just design a Signal protocol style 1-n party single-message authentication scheme, by essentially defining some specific way of sending a hash of the message to the intended recipients in the same way Signal initiates conversations. </div><div dir="auto"><br></div><div dir="auto">Mixed with time limited master keys and purpose-specific keys, it would drastically reduce the impact of data breaches. </div><div dir="auto"><br></div><div dir="auto">A bank which which gets their data leaked can protect their customers better if they can significantly reduce the certainty that the leaked data is correct. Internal data should only be verifiable internally. </div><div class="gmail_extra" dir="auto"></div></div>