mastodon.zunda.ninja is one of the many independent Mastodon servers you can use to participate in the fediverse.
Zundon is a single user instance as home of @zundan as well as a test bed for changes of the code.

Administered by:

Server stats:

1
active users

#soho

0 posts0 participants0 posts today
Theia Institute™<p><span class="h-card" translate="no"><a href="https://mstdn.social/@GnuPG" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>GnuPG</span></a></span> <span class="h-card" translate="no"><a href="https://infosec.exchange/@todd_a_jacobs" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>todd_a_jacobs</span></a></span> Using <a href="https://infosec.exchange/tags/LTFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LTFS</span></a> to store <a href="https://infosec.exchange/tags/encrypteddata" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>encrypteddata</span></a> outside of hyper scaler environments without the dedicated <a href="https://infosec.exchange/tags/KMS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>KMS</span></a> components expensive tape libraries use to enable <a href="https://infosec.exchange/tags/LTO9" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LTO9</span></a> drives' built-in, hardware <a href="https://infosec.exchange/tags/AES256GCM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AES256GCM</span></a> support is an area the institute is evaluating, and thinking about how <a href="https://infosec.exchange/tags/GPG" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GPG</span></a> might fit in has been a facet of our research process.</p><p>All recent generations of <a href="https://infosec.exchange/tags/LTO" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LTO</span></a> drives support strong, on-the-fly, hardware-accelerated encryption on the drives themselves. Sadly, it's essentially useless in the standalone drives sold to individuals, the <a href="https://infosec.exchange/tags/SOHO" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SOHO</span></a> market, or to other non-enterprise customers because of the high cost of the tape library hardware required to activate it.</p><p>In some ways, the situation is much like the early Intel 386 computers that shipped with missing or disabled math coprocessors even when it stopped being a cost issue. In part, that was a strategic market segmentation decision, and the institute currently believes the lack of accessible LTFS encryption for all encryption-capable drives is no different. </p><p>Even though <a href="https://infosec.exchange/tags/GnuPG" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GnuPG</span></a> is usually thought of as primarily an email tool, it's actually an important "Swiss Army knife" for a variety of <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>infosec</span></a> use cases. It's also on a tragically short list of <a href="https://infosec.exchange/tags/OpenPGP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenPGP</span></a> and telatrd <a href="https://infosec.exchange/tags/cryptography" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cryptography</span></a> tools that remains fully <a href="https://infosec.exchange/tags/opensource" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>opensource</span></a>.</p><p>We're putting this topic on our agenda for further exploration and discussion. Meanwhile, these community conversations and the viewpoints of respected tool developers is an invaluable resource to everyone.</p>
Dr. Todd A. Jacobs<p><a href="https://infosec.exchange/tags/TIL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TIL</span></a> that <span class="h-card" translate="no"><a href="https://mstdn.social/@GnuPG" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>GnuPG</span></a></span> appears to use the <a href="https://infosec.exchange/tags/ustar" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ustar</span></a> tar archive format, likely the version from POSIX.1-1988, for <a href="https://infosec.exchange/tags/gpgtar" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>gpgtar</span></a> rather than either the <a href="https://infosec.exchange/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> or Star formats from POSIX.1-2001. Since ustar has serious limitations on filename and pathname lengths, can't store certain file types or metadata, and has a 2GB file size limit, it seems unsuitable for most modern use cases.</p><p>If gpgtar is actually using star, pax, or the GNU tar POSIX mode, it's not in the <a href="https://infosec.exchange/tags/GnuPG" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GnuPG</span></a> user documentation which explicitly says it uses ustar. I have a lot of respect for the <a href="https://infosec.exchange/tags/GPG" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GPG</span></a> devs, so I hope this is either just a documentary oversight or something that they can easily fix by linking with newer libraries. In either case, ustar is totally unsuitable for writing large archives to tape, and doesn't even offer the options GNU tar does for creating a separate index file, encrypted or not.</p><p>The gnutar command line doesn't offer the option to write a separate index, and requires a separate pass to list out the index. For example if you wanted to encrypt a 20TiB archive with a separate, encrypted index to make finding files easier, you'd either have to pipe tar through gpg (which can cause shoe-shining or buffering issues on <a href="https://infosec.exchange/tags/LTFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LTFS</span></a>) and then encrypt GNU/BSD tar's index, or have <em>triple</em> the online HDD/SDD capacity of your archived data so you can tar up your files, run another pass with GnuPG to extract the index, and then encrypt both the tarball and index separately before writing them out to tape.</p><p>That seems...unreasonable. <a href="https://infosec.exchange/tags/OpenPGP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenPGP</span></a> doesn't support the AES-256-GCM mode built into current <a href="https://infosec.exchange/tags/LTO" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LTO</span></a> drives, so gpgtar needs to keep up with the massive growth of data storage capacity rather than remaining an afterthought utility. Especially for <a href="https://infosec.exchange/tags/SOHO" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SOHO</span></a> LTO drives, the ability to write encrypted gpgtar archives and indexes directly to LTFS could be a real game-changer!</p>