On 06/24/2014 01:50 AM, Stephen R Guglielmo wrote:
> On Tue, Jun 24, 2014 at 1:26 AM, frehberg <frehberg@xxxxxxxxx> wrote:
>> Hi,
>>
>> There are a number of TC-forks around, not all of them are compatible to
>> classical TC or to each other (eg VeraCrypt). In future the TC-forks
>> will come up with new features in UI or on device-level. Some may
>> introduce new container-formats etc. being non-interoperable with other
>> TC-forks
>>
>> I would like to suggest to start to document the classical TC-formats
>> (ciphers and container formats) as a starting point, so that projects
>> can claim being compliant/compatible to.
>>
>> This spec should be driven format over time, in cooperation with other
>> forks, so that the forks and their file-formats keep compatible to each
>> other.
>>
>> If there is no such document/spec around yet as starting point, I would
>> be willing to start such documentation effort, as I think that this is a
>> very important thing to do.
> Frank,
>
> I agree completely with this! We'll have to research *why* each format
> is incompatible (is it the header? the bulk data? The algorithm
> implementation?)
>
> I've made some changes to the wiki, turning it into more of a
> "technical wiki" than our main site. This sounds like a perfect
> article to put on there. I'm not sure if you have a write-account on
> the wiki yet (if not, contact Niklas). Either you can start a page on
> the container formatting, or I can start doing some research and begin
> writing a page.
>
> Good to hear from you!
>
While i was looking into the code to figure out a solution for audit
problem 1, i found documentation inside the code itself for the header
format and such, so it's probably all already documented, we just have
to find the comments. It already looks like fixing just problem 1 on the
audit might create a new container format because it has to change how
the header is laid out to somehow include the key derivation interval.
I suggest we make CipherShed test each of the container layouts and use
the appropriate code for each layout. If it fails to find 1 suitable
layout, then it should report to the user that either the password is
wrong or the volume isn't a TrueCrypt (or a variation of a TrueCrypt)
volume.
Since TrueCrypt itself is dead, i don't think we need to worry about
CipherShed keeping TrueCrypt's current format just as long as CipherShed
can *always* read from any version of TrueCrypt's containers and
possibly any version of another fork's format.
------------------------------------------------------------------------
At the time of sending this message, I have not been contacted by
any government official or worker regarding my participation in
CipherShed or any related project. I have not been asked to supply any
information to them that may be used to impersonate me nor have I been
asked to aid the government or it's officials or workers in modifying
part of CipherShed or any related project. I am not aware of any of my
property or anything regarding me being bugged, searched, or compromised
in any way. Anything that accepts PGP encryption or signing should have
been cryptographically secured with my PGP key.
Attachment:
signature.asc
Description: OpenPGP digital signature
