Discussion:
ANNOUNCE: FreeOTFE v4.50
(too old to reply)
Sarah Dean
2009-01-02 15:11:05 UTC
Permalink
Raw Message
FreeOTFE v4.30 has now been released, and includes the following changes:

*) Italian translation added
*) Added option to prevent message showing on successful mount
*) Added option to display large or small toolbar icons (Note: Large icons
with captions now shown by default. This may be changed back to show
small icons via the "Options" dialog)
*) Added option to save FreeOTFE settings to the Windows registry instead
of a configuration file
*) Added MRU list to system tray icon's menu. (Note: The MRU list is
disabled by default; enable via the "Options" dialog)
*) Added "/offset" command line option for mounting hidden volumes from the
command line
*) Message catalog system to simplify translation and reduce risk of errors
*) Change to prevent changing the CWD when browsing for files via the
standard open/save dialogs. This should stop FreeOTFE preventing USB
drive removal when keyfiles, etc are stored on USB drives.
*) Changed the broadcast message system informing other windows of drives
appearing/disappearing on mount/dismount
*) Corrected fault causing drive overwrite to fail under some circumstances
with volumes over 4GB
*) Refactored some parts of the codebase to eliminate duplicated code
*) Various cosmetic tweaks to improve display layout when translated into
different languages

v4.50 may be downloaded from the FreeOTFE WWW site at:

http://www.FreeOTFE.org/
nemo_outis
2009-01-02 16:39:17 UTC
Permalink
Raw Message
FreeOTFE v4.30 has now been released...
I'll check it out. Thanks for all your hard work.
Snowwhite
2009-01-09 14:18:33 UTC
Permalink
Raw Message
FreeOTFE v4.30 has now been released...
I'll check it out.  Thanks for all your hard work.
Hello,

I've checked it out too and I'm very pleased with it. Nevertheless I'm
a bit confused. I'm using TrueCrypt for about two years and I've never
had had any problems with it. Are there any good reasons for a change?
Are there any essentiell differences between these two programms?

Regards,
Snowwhite
nemo_outis
2009-01-09 16:37:14 UTC
Permalink
Raw Message
Post by Snowwhite
FreeOTFE v4.30 has now been released...
I'll check it out.  Thanks for all your hard work.
Hello,
I've checked it out too and I'm very pleased with it. Nevertheless I'm
a bit confused. I'm using TrueCrypt for about two years and I've never
had had any problems with it. Are there any good reasons for a change?
Are there any essentiell differences between these two programms?
Regards,
Snowwhite
Yes, there are some differences.

First of all, while it may not be a crucial issue for many, I think it's
imoportant that FreeOTFE is much more open than Truecrypt. While source
code is available for both, Truecrypt hides its developers' identities,
has gone to great lengths to 'purge' the internet of earlier versions of
source code, runs a forum that is arbitrary and very secretive about bug
submissions/resolutions, and has a licence which is NOT open (does not
conform to any OSI model). For encryption software, trust can be based
on code examination or the author's credentials and reputation: with
Sarah Dean (the developer of FreeOTFE) you get the best of both!

Truecrypt (since version 5.0) has one important feature that FreeOTFE
does not: full-disk encryption of the boot/system partition. In every
other respect I think FreeOTFE is better (and historically was first with
features such as XTS, Vista and Linux support, security tokens, etc.).
In short, a great track record of innovation and responsiveness to
requests.

In terms of functionality, FreeOTFE has a modular architecture which
makes it very expandable. For instance, it supports many crypto and hash
algorithms.

One additional advantage of FreeOTFE is that it doesn't have to be
installed and can be used in "portable mode" (although you still need
admin rights). Handy for things like USB sticks.

FreeOTFE also supports PDAs (interoperably with PCs) which is important
for many.

FreeOTFE supports 512-character password entry versus 64 for Truecrypt.
This may seem like a small point but it isn't - FreeOTFE is compatible
with use of *passphrases* rather than just passwords. (Memorable
passphrases like "A purple aardvark cavorts in a grotto of kumquat
rinds" can be just as strong as hard-to-remember passwords like 1F
$$werm67HgF.)

Lots of little things (like timestamp management for plausible
deniability, cascaded cyphers, password salts, etc.).

In short, if you want container-file/partition encryption (rather then
full disk) I think FreeOTFE is distinctly superior to Truecrypt.

Regards,
Snowwhite
2009-01-09 21:15:35 UTC
Permalink
Raw Message
Thanks a lot for your detailed explanations.

Regards,
Snowwhite
MyNym
2009-01-13 14:52:25 UTC
Permalink
Raw Message
Post by nemo_outis
Post by Snowwhite
FreeOTFE v4.30 has now been released...
I'll check it out.  Thanks for all your hard work.
Hello,
I've checked it out too and I'm very pleased with it. Nevertheless I'm
a bit confused. I'm using TrueCrypt for about two years and I've never
had had any problems with it. Are there any good reasons for a change?
Are there any essentiell differences between these two programms?
Regards,
Snowwhite
Yes, there are some differences.
First of all, while it may not be a crucial issue for many, I think it's
imoportant that FreeOTFE is much more open than Truecrypt. While source
code is available for both, Truecrypt hides its developers' identities,
has gone to great lengths to 'purge' the internet of earlier versions of
source code, runs a forum that is arbitrary and very secretive about bug
submissions/resolutions, and has a licence which is NOT open (does not
conform to any OSI model). For encryption software, trust can be based
on code examination or the author's credentials and reputation: with
Sarah Dean (the developer of FreeOTFE) you get the best of both!
Truecrypt (since version 5.0) has one important feature that FreeOTFE
does not: full-disk encryption of the boot/system partition. In every
other respect I think FreeOTFE is better (and historically was first with
features such as XTS, Vista and Linux support, security tokens, etc.).
In short, a great track record of innovation and responsiveness to
requests.
In terms of functionality, FreeOTFE has a modular architecture which
makes it very expandable. For instance, it supports many crypto and hash
algorithms.
One additional advantage of FreeOTFE is that it doesn't have to be
installed and can be used in "portable mode" (although you still need
admin rights). Handy for things like USB sticks.
FreeOTFE also supports PDAs (interoperably with PCs) which is important
for many.
FreeOTFE supports 512-character password entry versus 64 for Truecrypt.
This may seem like a small point but it isn't - FreeOTFE is compatible
with use of *passphrases* rather than just passwords. (Memorable
passphrases like "A purple aardvark cavorts in a grotto of kumquat
rinds" can be just as strong as hard-to-remember passwords like 1F
$$werm67HgF.)
Lots of little things (like timestamp management for plausible
deniability, cascaded cyphers, password salts, etc.).
In short, if you want container-file/partition encryption (rather then
full disk) I think FreeOTFE is distinctly superior to Truecrypt.
Regards,
I just wanted to add an additional note of thanks for your helpful
analysis of FreeOTFE and for the time you spent in doing that. I had
seen announcements re FreeOTFE previously, but hadn't been interested
because it seemed more complicated than TrueCrypt and I had no way of
telling whether either it's operation or security were reliable.

After reading your analysis, I've downloaded and will install the
software.

I have another question -- but before getting to that -- I've got to
also say THANK YOU (yes I'm shouting) to Sarah Dean.

My question is can you or someone provide some guidance on choosing a
hash/cypher algorithm -- my goal is to optimize speed and security.
From what I've read, most of the 256 bit cyphers should provide
adequate security -- and form my own experience I've found that 256
Blowfish is slow to create a disk/Volume, but reads it much more
quickly than AES. But what about the hashes? Do they make a difference
in speed? And how do my "mode" choices (CBC, LRW and XTS) impact speed
and security? I use 32 bit Windows XP btw.

Could you please give some comments and/or point me to a reading
resourse on the web?

Thanks.
nemo_outis
2009-01-13 18:20:42 UTC
Permalink
Raw Message
MyNym <***@myplace.com> wrote in news:***@4ax.com:

...
Post by MyNym
My question is can you or someone provide some guidance on choosing a
hash/cypher algorithm -- my goal is to optimize speed and security.
From what I've read, most of the 256 bit cyphers should provide
adequate security -- and form my own experience I've found that 256
Blowfish is slow to create a disk/Volume, but reads it much more
quickly than AES. But what about the hashes? Do they make a difference
in speed? And how do my "mode" choices (CBC, LRW and XTS) impact speed
and security? I use 32 bit Windows XP btw.
Could you please give some comments and/or point me to a reading
resourse on the web?
OK, but necessarily there's a lot of condensing and oversimplifying in
what follows (and a fair amount of my personal biases too):

1) Unless you have special reasons for eliminating it (e.g., rampant
paranoia about NSA's role) it's probably best to use AES as the cypher.
(Exceptions might include very old/underpowered computers where
Blowfish's speed might be preferred. But, generally speaking, you won't
notice the speed hit from any of the cyphers on any halfway modern
computer.) I'd choose AES because of the availability of excellent
*implementations* of the algorithm and the intensive scrutiny it has
received, even more than its theoretical properties (although they're
good too).

2) Of the cypher modes (CBC, LRW, and XTS) all protect very well from
most attacks that might be mounted against you. XTS protects the best
against some unlikely attacks (and LRW is almost as good). Go with XTS.
(The only reason not to is because XTS "approval" is not yet complete but
this is of concern mostly just for companies who demand formal standards,
etc. before adopting things for liability reasons like Sarbanes-Oxley,
etc.) For a recent overview of this and related crypto matters see:
https://siswg.net/index.php?option=com_docman&task=doc_download&gid=136
&Itemid=41

3) Hashes are an area of ferment and change these days. MD5 has
effectively reached "end of life" with some recent collision attacks
shown (including a CA authority one!). The NSA has recently invited
contestants for Round 1 of the Cryptographic Hash Algorithm Challenge -
selecting a new "official" hash algorithm using a process similar to that
used earlier to pick AES.

The SHA family is very strong in its longer lengths (e.g., 384, 512) but
suffers some "suspicion spillover" from MD5 since the internal
architecture of the algorithm is somewhat similar. Whirlpool, Tiger and
Ripemd (160) are good, but haven't had nearly the same scrutiny as the
SHA family. I'd go with SHA512 but you won't go far wrong with Whirlpool
or Ripemd either. Do NOT use MD2, MD4, or MD5 (they're there solely for
"legacy" compatibility.)

4) An area you didn't ask about but which is important is random-
number/key generation. Direct attacks on the cipher are more or less
"impossible" (even if you are one of Osama's henchmen), but a weak key is
a possible attack vector for very powerful TLA adversaries (NSA, MI5,
etc.). FreeOTFE gives you good flexibility here in choosing your
"randomness" source. All the choices are good (cryptolib is arguably the
best - no Microsoft taint - but requires some additional setup).

Now that I've gven you my thoughts, let me point out that these technical
considerations, fascinating as they may be, are the LEAST important
aspect of your security. Don't fall in love with the technology - it's
just a tool, one tool of many.

What will undo you is issues of the kind Shakespeare writes about: greed,
laziness, betrayal, pride, boastfulness, sloppiness - the full panoply of
human weaknesses and vices. Your efforts should primarily be addressed
to these. For instance, the best crypto package in the world will be
useless if you walk away from your machine and leave it running. Or if
you don't physically secure the environment. Or if you don't make
encrypted backups. Or if a jealous girlfriend also knows your password.
And on and on.

Even coming back to technical issues, you should really do at least an
informal risk, threat and consequence analysis. Crypto security is weak
protection if you don't have a reasonable degree of physical security,
for instance. And your security should have layers, so that there is no
single point of failure (e.g., good though it is,, you should not rely on
FreeOTFE alone unless your security needs are quite mild.)

Always remember that the fellow most likely to cause the failure of your
security is YOU!

Regards,
MyNym
2009-01-13 18:54:29 UTC
Permalink
Raw Message
Post by nemo_outis
...
Post by MyNym
My question is can you or someone provide some guidance on choosing a
hash/cypher algorithm -- my goal is to optimize speed and security.
From what I've read, most of the 256 bit cyphers should provide
adequate security -- and form my own experience I've found that 256
Blowfish is slow to create a disk/Volume, but reads it much more
quickly than AES. But what about the hashes? Do they make a difference
in speed? And how do my "mode" choices (CBC, LRW and XTS) impact speed
and security? I use 32 bit Windows XP btw.
Could you please give some comments and/or point me to a reading
resourse on the web?
OK, but necessarily there's a lot of condensing and oversimplifying in
1) Unless you have special reasons for eliminating it (e.g., rampant
paranoia about NSA's role) it's probably best to use AES as the cypher.
(Exceptions might include very old/underpowered computers where
Blowfish's speed might be preferred. But, generally speaking, you won't
notice the speed hit from any of the cyphers on any halfway modern
computer.) I'd choose AES because of the availability of excellent
*implementations* of the algorithm and the intensive scrutiny it has
received, even more than its theoretical properties (although they're
good too).
2) Of the cypher modes (CBC, LRW, and XTS) all protect very well from
most attacks that might be mounted against you. XTS protects the best
against some unlikely attacks (and LRW is almost as good). Go with XTS.
(The only reason not to is because XTS "approval" is not yet complete but
this is of concern mostly just for companies who demand formal standards,
etc. before adopting things for liability reasons like Sarbanes-Oxley,
https://siswg.net/index.php?option=com_docman&task=doc_download&gid=136
&Itemid=41
3) Hashes are an area of ferment and change these days. MD5 has
effectively reached "end of life" with some recent collision attacks
shown (including a CA authority one!). The NSA has recently invited
contestants for Round 1 of the Cryptographic Hash Algorithm Challenge -
selecting a new "official" hash algorithm using a process similar to that
used earlier to pick AES.
The SHA family is very strong in its longer lengths (e.g., 384, 512) but
suffers some "suspicion spillover" from MD5 since the internal
architecture of the algorithm is somewhat similar. Whirlpool, Tiger and
Ripemd (160) are good, but haven't had nearly the same scrutiny as the
SHA family. I'd go with SHA512 but you won't go far wrong with Whirlpool
or Ripemd either. Do NOT use MD2, MD4, or MD5 (they're there solely for
"legacy" compatibility.)
4) An area you didn't ask about but which is important is random-
number/key generation. Direct attacks on the cipher are more or less
"impossible" (even if you are one of Osama's henchmen), but a weak key is
a possible attack vector for very powerful TLA adversaries (NSA, MI5,
etc.). FreeOTFE gives you good flexibility here in choosing your
"randomness" source. All the choices are good (cryptolib is arguably the
best - no Microsoft taint - but requires some additional setup).
Now that I've gven you my thoughts, let me point out that these technical
considerations, fascinating as they may be, are the LEAST important
aspect of your security. Don't fall in love with the technology - it's
just a tool, one tool of many.
What will undo you is issues of the kind Shakespeare writes about: greed,
laziness, betrayal, pride, boastfulness, sloppiness - the full panoply of
human weaknesses and vices. Your efforts should primarily be addressed
to these. For instance, the best crypto package in the world will be
useless if you walk away from your machine and leave it running. Or if
you don't physically secure the environment. Or if you don't make
encrypted backups. Or if a jealous girlfriend also knows your password.
And on and on.
Even coming back to technical issues, you should really do at least an
informal risk, threat and consequence analysis. Crypto security is weak
protection if you don't have a reasonable degree of physical security,
for instance. And your security should have layers, so that there is no
single point of failure (e.g., good though it is,, you should not rely on
FreeOTFE alone unless your security needs are quite mild.)
Always remember that the fellow most likely to cause the failure of your
security is YOU!
Regards,
Many thanks! That was quite helpful.

Hey I have another question for you -- this probably isn't the right
place to ask; but I will anyway.

Couple years ago, there were published reports that commercial
photocopyiers microencoded a small amount of information in into every
photocopy they made -- was a big surprise at the time. So that
information churned in my head for a while and one day a question
popped into my head about disk encryption (I've used DriveCrypt for
many years but am finally giving up due to the complexity of upgrading
and cost involved). But here's my question; Could hardDrive
manufacturers and/or CPU manufacturers encode tiny amounts of
information into every data stream that is transferred to a harddrive,
(and not actually read the data when retrieving information from the
disk) in order to provide a universal back door for all encryption
systems -- I guess the theoretical qauestion I'm asking is if you know
the original of some of the info on the disk as it was prior to
encryption, and you know or have a pretty good idea of where it landed
on the disk in encrypted form, could you theoretically reverse
engineer the encryption algorithm??

Just a paranoid thought.

Thanks again for your input on my earlier queation, and if you have
any thoughts on my new question.

Regards.
nemo_outis
2009-01-13 20:28:11 UTC
Permalink
Raw Message
MyNym <***@myplace.com> wrote in news:***@4ax.com:
,,,
Post by MyNym
Couple years ago, there were published reports that commercial
photocopyiers microencoded a small amount of information in into every
photocopy they made -- was a big surprise at the time.
Not just copiers, printers too (including consumer models).
Post by MyNym
So that
information churned in my head for a while and one day a question
popped into my head about disk encryption (I've used DriveCrypt for
many years but am finally giving up due to the complexity of upgrading
and cost involved). But here's my question; Could hardDrive
manufacturers and/or CPU manufacturers encode tiny amounts of
information into every data stream that is transferred to a harddrive,
(and not actually read the data when retrieving information from the
disk) in order to provide a universal back door for all encryption
systems -- I guess the theoretical qauestion I'm asking is if you know
the original of some of the info on the disk as it was prior to
encryption, and you know or have a pretty good idea of where it landed
on the disk in encrypted form, could you theoretically reverse
engineer the encryption algorithm??
If the hardware has been backdoored, anything is possible.

With that said, the hard disk itself is not a big risk. It only records
what is sent to it, and, with OTFE, no plaintext should ever get near the
HD (unless some other program/process sends it there). Even more
strongly, neither would any key or password (at least from the OTFE
program).

However, the business of a HD is storing data and there's plenty of room
to write significant amounts of data, including hidey-holes like the
"manufacturer's area" which is inaccessible to ordinary users (it's
normally used for SMART info, hardware serial number, etc.). So, plenty
of room to write selected info, but insufficient room to also
surreptitiously write, say, the full plaintext for every encrypted
sector. (Conceivably also, the HD could contain a "virus/trojan" that
installs itself on your computer, but this would be tricky to implement,
and would be awkward to keep updated, etc.)

In short, the HD could be used to assist compromising your security, but
is very unlikely to be the source of the compromise.

There could, at least in principle, be some sort of compromise possible
at the CPU level, but it would be clumsy, unwieldy and inflexible to put
it there.

No, discounting hardware keyloggers, video cameras, and such, the
overwhelmingly most likely source of security compromise is "code,"
either as the OS & applications (including viruses/trojans/rootkits,
etc.) or conceivably, embedded in a BIOS (not just the motherboard BIOS -
it could be, for instance, the video BIOS). So, the real threat is
software or firmware, not hardware (and some firmware could be used for
storage of leaked info as well as for the code source for the
compromise).

If Windows (or an application, virus, etc. running under it) has been
backdoored it would be trivial for it to harvest the encryption
password/key from memory, and just as trivial for it to store it
somewhere (or transmit it, but that is more detectable). Windows, with
its ubiquity and frequent updates, would provide an ideal vector for
compromising encryption security. The updates provide great flexibility
to attack new or upgraded encryption programs as they evolve.

Full disk encryption is IMHO a necessity for adequate security. Yes,
partion/container OTFE programs may themselves be secure but Windows (and
many programs run under it) - even without deliberate backdooring - leak
information all over the place (swap files, temporary files, registry
entries, index.dat files, and on and on). Scrubbing is a very poor way
to address this leakage (it's slow, coverage is questionable, and only
the most disciplined will do it often enough). Full OTFE HD encryption
shuts down all accidental/incidental leakage paths. **It's not an
option, it's a must!** (I know this relegates FreeOTFE to a
subsidiary/auxiliary role, but I calls 'em the way I sees 'em.)

In short, full HD encryption is necessary. Necessary but, alas, not
sufficient. It can shut down all accidental/incidental leaking but not
deliberate leaking. If, say, Windows has been backdoored then it CAN
leak, say, the encryption key to even a fully encrypted HD - *without*
even needing to take advantage of any hidey-holes such as the
manufacturer's area. (I have posted in other forums how a malign program
could leak a harvested encryption key to a full-encrypted HD while still
fully conforming to the HD encryption algorithm!)

In short, if you run backdoored software (e.g, putatively, Windows) then,
even on a fully encrypted machine, your security can easily be defeated.
Ain't life a bitch?

Regards,

PS Paranoids will insist on Linux (real paranoids will insist on
OpenBSD :-) and only a bare minimum of other open-source apps for their
secure machine. This and *layered* encryption (e.g., container-file OTFE
encryption from one supplier nested within full-HD OTFE encryption from a
different supplier). Unfortunately, this route is too geeky and
inconvenient for many.

PPS The bad news is that it's very hard to protect oneself from, say, a
backdoored OS; the good news is that only the highest-echelon TLAs are
likely to use such methods (but woe to you if such TLAs are part of your
threat inventory).
MyNym
2009-01-13 22:09:04 UTC
Permalink
Raw Message
Post by nemo_outis
... Could hardDrive
manufacturers and/or CPU manufacturers encode tiny amounts of
information into every data stream that is transferred to a harddrive,
(and not actually read the data when retrieving information from the
disk) in order to provide a universal back door for all encryption
systems -- I guess the theoretical qauestion I'm asking is if you know
the original of some of the info on the disk as it was prior to
encryption, and you know or have a pretty good idea of where it landed
on the disk in encrypted form, could you theoretically reverse
engineer the encryption algorithm??
If the hardware has been backdoored, anything is possible.
With that said, the hard disk itself is not a big risk. It only records
what is sent to it, and, with OTFE, no plaintext should ever get near the
HD (unless some other program/process sends it there). Even more
strongly, neither would any key or password (at least from the OTFE
program).
However, the business of a HD is storing data and there's plenty of room
to write significant amounts of data, including hidey-holes like the
"manufacturer's area" which is inaccessible to ordinary users (it's
normally used for SMART info, hardware serial number, etc.). So, plenty
of room to write selected info, but insufficient room to also
surreptitiously write, say, the full plaintext for every encrypted
sector. (Conceivably also, the HD could contain a "virus/trojan" that
installs itself on your computer, but this would be tricky to implement,
and would be awkward to keep updated, etc.)
In short, the HD could be used to assist compromising your security, but
is very unlikely to be the source of the compromise.
There could, at least in principle, be some sort of compromise possible
at the CPU level, but it would be clumsy, unwieldy and inflexible to put
it there.
No, discounting hardware keyloggers, video cameras, and such, the
overwhelmingly most likely source of security compromise is "code,"
either as the OS & applications (including viruses/trojans/rootkits,
etc.) or conceivably, embedded in a BIOS (not just the motherboard BIOS -
it could be, for instance, the video BIOS). So, the real threat is
software or firmware, not hardware (and some firmware could be used for
storage of leaked info as well as for the code source for the
compromise).
If Windows (or an application, virus, etc. running under it) has been
backdoored it would be trivial for it to harvest the encryption
password/key from memory, and just as trivial for it to store it
somewhere (or transmit it, but that is more detectable). Windows, with
its ubiquity and frequent updates, would provide an ideal vector for
compromising encryption security. The updates provide great flexibility
to attack new or upgraded encryption programs as they evolve.
Full disk encryption is IMHO a necessity for adequate security. Yes,
partion/container OTFE programs may themselves be secure but Windows (and
many programs run under it) - even without deliberate backdooring - leak
information all over the place (swap files, temporary files, registry
entries, index.dat files, and on and on). Scrubbing is a very poor way
to address this leakage (it's slow, coverage is questionable, and only
the most disciplined will do it often enough). Full OTFE HD encryption
shuts down all accidental/incidental leakage paths. **It's not an
option, it's a must!** (I know this relegates FreeOTFE to a
subsidiary/auxiliary role, but I calls 'em the way I sees 'em.)
In short, full HD encryption is necessary. Necessary but, alas, not
sufficient. It can shut down all accidental/incidental leaking but not
deliberate leaking. If, say, Windows has been backdoored then it CAN
leak, say, the encryption key to even a fully encrypted HD - *without*
even needing to take advantage of any hidey-holes such as the
manufacturer's area. (I have posted in other forums how a malign program
could leak a harvested encryption key to a full-encrypted HD while still
fully conforming to the HD encryption algorithm!)
In short, if you run backdoored software (e.g, putatively, Windows) then,
even on a fully encrypted machine, your security can easily be defeated.
Ain't life a bitch?
Regards,
PS Paranoids will insist on Linux (real paranoids will insist on
OpenBSD :-) and only a bare minimum of other open-source apps for their
secure machine. This and *layered* encryption (e.g., container-file OTFE
encryption from one supplier nested within full-HD OTFE encryption from a
different supplier). Unfortunately, this route is too geeky and
inconvenient for many.
PPS The bad news is that it's very hard to protect oneself from, say, a
backdoored OS; the good news is that only the highest-echelon TLAs are
likely to use such methods (but woe to you if such TLAs are part of your
threat inventory).
Many thanks again. I agree that any hardware or major software
security mods would have to be used very sparingly... I don't think I
rate.

I guess one could say that just as the age of computers brought the
ability to generate undecryptable encryption, the same technology
brought with it means to defeat it (the complexity of generating
undecryptable encryption limits its use to computers but computers are
inherently leaky and suseptible to manipulation for the very same
considerations of comlexity -- computers generate and process massive
amounts of data thus increasing the difficulty of protecting all of
the data, and conduct a plethora of different tasks at any given time
thus increasing the difficulty of 'vetting' each and every task), but
the real bottom line on security risks, as you pointed out earlier, is
the human factor.

So it goes.

Thanks.
Carsten Krueger
2009-01-15 16:38:28 UTC
Permalink
Raw Message
Post by nemo_outis
Truecrypt (since version 5.0) has one important feature that FreeOTFE
does not: full-disk encryption of the boot/system partition.
http://DiskCryptor.net/ is an alternative to TC system encryption.
+GPL
+removed truecrypt legacy options
+open forum
+very fast
-developer hidden as TC devlopers
-no good manual

greetings
Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
nemo_outis
2009-01-15 17:18:59 UTC
Permalink
Raw Message
Post by Carsten Krueger
Post by nemo_outis
Truecrypt (since version 5.0) has one important feature that FreeOTFE
does not: full-disk encryption of the boot/system partition.
http://DiskCryptor.net/ is an alternative to TC system encryption.
+GPL
+removed truecrypt legacy options
+open forum
+very fast
-developer hidden as TC devlopers
-no good manual
greetings
Carsten
It looks very promising, even though its development is not quite as far
along as Truecrypt.

1) The truly open GPLv3 licence is an enormous plus compared to
Truecrypt! They should brag about it a lot!

2) I congratulate them on having an open problem reporting and bug list.
Seeing open reporting and free discussion of bugs greatly increases my
confidence in a piece of software (instead of trying to hide the bug-
reporting and correcting process like Truecrypt)!

Regards,

PS Besides the more recent versions (.5 & .6) I also downloaded version
0.4. Why? Because I intend to use it as a a validator/verifier for
Truecrypt partitions.
Carsten Krueger
2009-01-15 17:44:13 UTC
Permalink
Raw Message
Post by nemo_outis
It looks very promising, even though its development is not quite as far
along as Truecrypt.
DC is not as userfriendly as TC but is more developed than TC
-shrinking of filesystem[1]
-chaining/cascading of algorithms for boot volume
-use of keyfiles
-booting from usb/pxe

greetings
Carsten

[1]
25C3: FullDiskEncryption - CrashCourse - Everything to hide - Jürgen Pabel
http://events.ccc.de/congress/2008/Fahrplan/attachments/1190_Full-Disk-Encryption_Crash-Course_Paper.pdf
DC is not compatible anymore since 0.5
| TrueCrypt and DiskCryptor are entirely independent, but compatible, implementations: DiskCryptor adheres
| to the the TrueCrypt volume specifications. The TrueCrypt volume specifications requires a 512 byte volume
| header to be located before the encrypted volume. The header contains data required for mounting the
| encrypted volume (this applies to disks, partitions and fileback containers alike). Filebacked
| containers| contain this header at offset 0, while the header is stored in the sector located just before the lower partition
| boundary for partitionback containers. However, this only works reliably for the first partition as the first
| partition always starts on (at least) sector 63, leaving sector 62 (and others) unused and available for the
| volume header. This workaround has a negative impact on TrueCrypt's FullDiskEncryption
| capabilities: only the first partition may be encrypted inplace as other partitions are unlikely to have a spare sector at
| their lower partition boundary. DiskCryptor on the other hand stores the volume header inside the first sector
| of the partition and therefore allows for any partition to be encrypted in place. However, this approach
| introduces two issues:
| ➢ it reduces the available partition size for the filesystem by one sector1 and
| ➢ it requires relocating every sector in the partition.
| DiskCryptor implements a custom filesystem shrinkage function for NTFS/FAT12/FAT16/FAT32 filesystems
| in order to shrink the filesystem on Microsoft Windows XP and 2003 as necessary. DiskCryptor running on
| newer versions of Microsoft Windows employs native filesystem shrinkage support, if available. The sector
| relocations are conducted during the initial encryption process, which reads data from an unencrypted sector
| and writes the encrypted data to the target sector. The sector shifting logic is implemented in DiskCryptor's
| lowerlevel filter driver and therefore hides all aspects about the sector shifting to upper layers. For example:
| if the filesystem driver initiates a read operation for sector X then DiskCryptor intercepts the
| the request in the lowerlevel filter driver, loads sector X+1 from disk and returns the decrypted data as sector X.
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
nemo_outis
2009-01-16 01:39:55 UTC
Permalink
Raw Message
Post by Carsten Krueger
Post by nemo_outis
It looks very promising, even though its development is not quite as
far along as Truecrypt.
DC is not as userfriendly as TC but is more developed than TC
-shrinking of filesystem[1]
-chaining/cascading of algorithms for boot volume
-use of keyfiles
-booting from usb/pxe
Ok, I'll emend my statement: Truecrypt and DiskCryptor have some
different features. But in terms of development I don't think it's
accidental that DC's version number is 0.6!

I rated Drivecryptor as less developed because of, inter alia, the
following deficiency which I consider serious that is noted on the
Diskcryptor site: risk of losing data during encryption/decryption if
system is rebooted.

http://diskcryptor.net/index.php/DiskCryptor_en#Limitations_in_the_curren
t_version

Moreover, even Drivecryptor fans must admit that its documentation is not
as well developed as Truecrypt's.

In summary, DC does seem an excellent program overall - but there's still
work to be done.

Regards,
Carsten Krueger
2009-01-16 18:00:55 UTC
Permalink
Raw Message
Post by nemo_outis
Ok, I'll emend my statement: Truecrypt and DiskCryptor have some
different features. But in terms of development I don't think it's
accidental that DC's version number is 0.6!
The main problem was that the header layout was not stable.
Next version is likely 1.0.
Post by nemo_outis
I rated Drivecryptor as less developed because of, inter alia, the
following deficiency which I consider serious that is noted on the
Diskcryptor site: risk of losing data during encryption/decryption if
system is rebooted.
http://diskcryptor.net/index.php/DiskCryptor_en#Limitations_in_the_curren
t_version
That's not true anymore. I think it's fixed in 0.4 or 0.5.
Even hibernate works while encrypting/decrypting.
Post by nemo_outis
Moreover, even Drivecryptor fans must admit that its documentation is not
as well developed as Truecrypt's.
Yes.

greetings
Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
nemo_outis
2009-01-16 19:11:19 UTC
Permalink
Raw Message
Carsten Krueger <***@invalid.invalid> wrote in news:***@cakruege.my-fqdn.de:

...

Thanks for the clarifications.

Carsten Krueger
2009-01-16 18:09:00 UTC
Permalink
Raw Message
Post by nemo_outis
Ok, I'll emend my statement: Truecrypt and DiskCryptor have some
different features. But in terms of development I don't think it's
accidental that DC's version number is 0.6!
The main problem was that the header layout was not stable.
Next version is likely 1.0.
Post by nemo_outis
I rated Drivecryptor as less developed because of, inter alia, the
following deficiency which I consider serious that is noted on the
Diskcryptor site: risk of losing data during encryption/decryption if
system is rebooted.
http://diskcryptor.net/index.php/DiskCryptor_en#Limitations_in_the_curren
t_version
That's not true anymore. This was fixed in 0.3.
Even hibernate works while encrypting/decrypting.
Post by nemo_outis
Moreover, even Drivecryptor fans must admit that its documentation is not
as well developed as Truecrypt's.
Yes.

greetings
Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Loading...