<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 30, 2018 at 5:18 AM, Christoph Anton Mitterer <span dir="ltr"><<a href="mailto:calestyo@scientia.net" target="_blank">calestyo@scientia.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey.<br>
<br>
Thanks for your replies so far,... but I think this goes in a<br>
completely wrong direction ;-)</blockquote><div> </div><div>Wrong direction opens another pile of bits.<br>There is both: store securely and also destroy securely. <br><br>For example if I had an encrypted archive of your data in escrow for you<br>and you want it deleted that could be done by scrubbing that specific key.<br>As long a there was no unmanaged copy of the key that scrubb would be<br>as effective as the original encryption.   The owner of the data can and <br>likely should do the encryption.  The storage service might elect to encrypt<br>the data one more time to secure their contract services with value add.<br>Valuable data should never be delivered to a storage service unencrypted be </div><div>it by wire or physical media. <br><br>Since long term storage is still the world of tape stored in a cave the </div><div>tape removal and physical destruction is a risk as it opens the gate for the other</div><div>tapes in the vault.   Thus expect media to be there for a long time unless <br>you are Amazon or Google and own the whole cave.  The risk of getting the<br>wrong tape cartridge is still real even if you own the cave. <br><br>Tape archives (tar) are nicely structured for some of this.<br>The archive file can be made with or without padding, encrypted,<br>transported electronically to the tape writer then committed to media.<br>Compression first but only once I suspect. <br><br>Things then boil down to key management for the life of the media.<br><br>Media life, ECC and rewriting an archive to a future media should be <br>part of the design.   In the rewrite process the data should not be in the clear.<br>ECC and checksum by tape and tape block should be part of the storage<br>service metadata.   A good 20 year old tape needs a compatible reader and<br>in my experience the tape reader is the weak link.<br><br>Filesystems with MAC or ownership meta data depend on the operating system to<br>enforce visibility, encrypted or not.   It is unlikely that data sets have a single owner </div><div>any more.  The tools that manage multiple owners needs to be part of the data<br>management and storage design.   i.e. on another turn your fragile key for our shared file and <br>my strong key would be a risk and results in data no safer than your fragile key. <br>The meta data is critical as well.  An oracle database will have users and </div><div>metadata that "the oracle system" manages and enforces outside the policy </div><div>of the OS.  Understanding policy layers, tools and what flows from what should </div><div>not be overlooked.<br><br>Interesting problem especially in light of quantum tools inside of 20 years (perhaps). <br><br>I like the notion of "<span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">easily just write the file as is </span><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(without any filesystem) into the dmcrypt </span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">block device" but that leaves backing up the resources to read the<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> dmcrypt block device in the </span></span></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">critical path for 20 years.   It also allows the block device to be raw block by block archived to<br></span></span>tape or a remote service for archiving. <br><br>I am looking at my <b style="color:rgb(106,106,106);font-family:Roboto,arial,sans-serif;font-size:small;text-align:left;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">YubiKey </b>and do not expect it to physically last five years. Key management!<br><a href="https://www.yubico.com/wp-content/uploads/2015/08/Yubico_WhitePaper_A_Question_Of_Key_Length.pdf">https://www.yubico.com/wp-content/uploads/2015/08/Yubico_WhitePaper_A_Question_Of_Key_Length.pdf</a></div><div><br><br><br><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>