[Cryptography] End to end
mkington at webhanger.com
Wed Sep 18 04:23:34 EDT 2013
On 18 Sep 2013 07:44, "Christoph Gruber" <grisu at guru.at> wrote:
> On 2013-09-17 Max Kington <mkington at webhanger.com> wrote:
> > Hence, store in the clear, keep safe at rest using today's archival
mechanism and when that starts to get dated move onto the next one
en-masse, for all your media not just emails.
> I would tend to agree for environments with very high regulations, where
the need to comply with regulations is more important than the need to keep
> I would suggest to balance that for every organisation. The risk to
disclosure is much higher if data is stored unprotected. Any admin with
access to the file system is able to read it.
> Maybe this could be a cultural difference between US and Europe, the
regulative pressure in US is higher, in Europe the privacy is more
important or more protected.
> I agree that both ways may be the right implementation for an
organisation, but this has to be a management decision, balancing the needs.
I was referring to the UK :-)
I'm not saying it isn't important to consider how data is made available in
the cases where you have end to end security but a future standard wants to
be permissive of a solution even if it's out of scope for the RFC rather
than prohibitive by including it as mandatory, could/can vs should/must.
That said now there appears to be evidence that side channel attacks that
force lesser security where it's an option are being actively exploited.
Previously we'd have all assumed that the main benefit of those was in
interoperability but now not so much. So there is an argument to use 'must'
more in standards concerning security.
By making archival a separate concern you also reduce the complexity of
many deployments. As you say, for environments with very high regulation,
my personal mailbox, isn't, my work one, is.
> Best regards
> Christoph Gruber
> "If privacy is outlawed, only outlaws will have privacy." Phil Zimmermann
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography