[Cryptography] how to encrypt for the very long term?

[Tom Mitchell]

On Mon, Jul 30, 2018 at 5:18 AM, Christoph Anton Mitterer <
calestyo at scientia.net> wrote:

> Hey.
>
> Thanks for your replies so far,... but I think this goes in a
> completely wrong direction ;-)


Wrong direction opens another pile of bits.
There is both: store securely and also destroy securely.

For example if I had an encrypted archive of your data in escrow for you
and you want it deleted that could be done by scrubbing that specific key.
As long a there was no unmanaged copy of the key that scrubb would be
as effective as the original encryption.   The owner of the data can and
likely should do the encryption.  The storage service might elect to encrypt
the data one more time to secure their contract services with value add.
Valuable data should never be delivered to a storage service unencrypted be
it by wire or physical media.

Since long term storage is still the world of tape stored in a cave the
tape removal and physical destruction is a risk as it opens the gate for
the other
tapes in the vault.   Thus expect media to be there for a long time unless
you are Amazon or Google and own the whole cave.  The risk of getting the
wrong tape cartridge is still real even if you own the cave.

Tape archives (tar) are nicely structured for some of this.
The archive file can be made with or without padding, encrypted,
transported electronically to the tape writer then committed to media.
Compression first but only once I suspect.

Things then boil down to key management for the life of the media.

Media life, ECC and rewriting an archive to a future media should be
part of the design.   In the rewrite process the data should not be in the
clear.
ECC and checksum by tape and tape block should be part of the storage
service metadata.   A good 20 year old tape needs a compatible reader and
in my experience the tape reader is the weak link.

Filesystems with MAC or ownership meta data depend on the operating system
to
enforce visibility, encrypted or not.   It is unlikely that data sets have
a single owner
any more.  The tools that manage multiple owners needs to be part of the
data
management and storage design.   i.e. on another turn your fragile key for
our shared file and
my strong key would be a risk and results in data no safer than your
fragile key.
The meta data is critical as well.  An oracle database will have users and
metadata that "the oracle system" manages and enforces outside the policy
of the OS.  Understanding policy layers, tools and what flows from what
should
not be overlooked.

Interesting problem especially in light of quantum tools inside of 20 years
(perhaps).

I like the notion of "easily just write the file as is (without any
filesystem) into the dmcrypt
block device" but that leaves backing up the resources to read the dmcrypt
block device in the
critical path for 20 years.   It also allows the block device to be raw
block by block archived to
tape or a remote service for archiving.

I am looking at my *YubiKey *and do not expect it to physically last five
years. Key management!
https://www.yubico.com/wp-content/uploads/2015/08/Yubico_WhitePaper_A_Question_Of_Key_Length.pdf





-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180731/00b2573f/attachment.html>