Truecrypt issue, input needed, Carsten, Shaun...?

[thang ornithorhynchus]

Shaun, what you brought to my attention about "hiddendevs" etc, and
then Wilders and Schneier comments (fora, not personally) regarding
same, leads me to consider the use of encrypted containers on TC
hidden volumes - but one proviso, use of another proprietary container
method so that if, and its a big if, TC *has* been compromised
(perhaps from the ground up, who knows?), then at base level there
will be a *non-TC* container with industrial secrets or whatever in it
which will resist cracking.

I have therefore tried DC but it mounts as a disk, and as you know,
using hidden OS option under TC 6.2a, all non-encrypted devices or
partitions are read only. DC constructed the disk and mounted it, but
it could not format it because once it was mounted, it became a
write-protected non-encrypted device and therefore useless for the
above purpose. It could not even be formatted, let alone written to
by data.

I need to know, as an amateur cryptologist, whether there are any
non-TC encrytped containers on the market which do *not* mount as a
device or partition? Any ideas? I could Google but this seems an
interesting topic which could even be of use to you (Shaun) in the
development of the next species of DC and DCPP - use *with* TC as an
alternative in case the original (TC) is compromised - mix and match.
Heck, I'll even script the blurb for your web page if you like :)

Shaun, following on your footsteps, if I was paranoid, which I am not
really, then I would think that the construction of TC is targeted
towards ensuring that TC, and **ONLY** TC can be used to write to when
the hidden volume (OS) option is used :) No-one seems to have picked
up on this...

Comments please...

regards

thang

[John Smith]

thang ornithorhynchus wrote:
> Shaun, what you brought to my attention about "hiddendevs" etc, and
> then Wilders and Schneier comments (fora, not personally) regarding
> same, leads me to consider the use of encrypted containers on TC
> hidden volumes - but one proviso, use of another proprietary container
> method so that if, and its a big if, TC *has* been compromised
> (perhaps from the ground up, who knows?), then at base level there
> will be a *non-TC* container with industrial secrets or whatever in it
> which will resist cracking.
>
> I have therefore tried DC but it mounts as a disk, and as you know,
> using hidden OS option under TC 6.2a, all non-encrypted devices or
> partitions are read only. DC constructed the disk and mounted it, but
> it could not format it because once it was mounted, it became a
> write-protected non-encrypted device and therefore useless for the
> above purpose. It could not even be formatted, let alone written to
> by data.
>
> I need to know, as an amateur cryptologist, whether there are any
> non-TC encrytped containers on the market which do *not* mount as a
> device or partition? Any ideas? I could Google but this seems an
> interesting topic which could even be of use to you (Shaun) in the
> development of the next species of DC and DCPP - use *with* TC as an
> alternative in case the original (TC) is compromised - mix and match.
> Heck, I'll even script the blurb for your web page if you like :)
>
> Shaun, following on your footsteps, if I was paranoid, which I am not
> really, then I would think that the construction of TC is targeted
> towards ensuring that TC, and **ONLY** TC can be used to write to when
> the hidden volume (OS) option is used :) No-one seems to have picked
> up on this...
>
> Comments please...
>
> regards
>
> thang

Troll

[Buzz Murdoch]

On Fri, 28 Aug 2009 09:45:37 +0800, thang ornithorhynchus
<***@spitzola.com.org.net> wrote:

> if I was paranoid, which I am not really [...]

Heh.

[thang ornithorhynchus]

On Fri, 28 Aug 2009 20:11:47 -0400, Buzz Murdoch
<***@route66.hwy> wrote:

>On Fri, 28 Aug 2009 09:45:37 +0800, thang ornithorhynchus
><***@spitzola.com.org.net> wrote:
>
>> if I was paranoid, which I am not really [...]
>
>Heh.

Ha. I've said too much :)

thang

[Shaun]

>On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:

Hi Thang,

>Shaun, what you brought to my attention about "hiddendevs" etc, and
>then Wilders and Schneier comments (fora, not personally) regarding
>same, leads me to consider the use of encrypted containers on TC
>hidden volumes - but one proviso, use of another proprietary container
>method so that if, and its a big if, TC *has* been compromised
>(perhaps from the ground up, who knows?), then at base level there
>will be a *non-TC* container with industrial secrets or whatever in it
>which will resist cracking.
>
>I have therefore tried DC but it mounts as a disk, and as you know,
>using hidden OS option under TC 6.2a, all non-encrypted devices or
>partitions are read only. DC constructed the disk and mounted it, but
>it could not format it because once it was mounted, it became a
>write-protected non-encrypted device and therefore useless for the
>above purpose. It could not even be formatted, let alone written to
>by data.

I see. TC driver must be monitoring all the mounts or drive letters,
and putting hooks into any drives it sees appearing.

Personally I think that preventing write access to different mounted
disk devices is a bit of overkill really. There really should be an
option to turn this off when their hidden os is in use.

Perhaps a mod to their driver might be a good idea...

>
>I need to know, as an amateur cryptologist, whether there are any
>non-TC encrytped containers on the market which do *not* mount as a
>device or partition? Any ideas?

The problem with that is that you would be very limited what you could
do with the data. Yould have to copy it somehwhere. I guess it is
possible to make a reader or even read-write scheme to allow the
container to be opened in the form of a window showing the files.
However as soon as the files are moved out of the window, then they
are vulnerable as they would not be copy protected. We don't
unfortunately have such a program however.

I do have another idea I've thought about for a long time, but I can't
disclose it here, at least not yet.

> I could Google but this seems an
>interesting topic which could even be of use to you (Shaun) in the
>development of the next species of DC and DCPP - use *with* TC as an
>alternative in case the original (TC) is compromised - mix and match.
>Heck, I'll even script the blurb for your web page if you like :)
>

>Shaun, following on your footsteps, if I was paranoid, which I am not
>really, then I would think that the construction of TC is targeted
>towards ensuring that TC, and **ONLY** TC can be used to write to when
>the hidden volume (OS) option is used :) No-one seems to have picked
>up on this...

What happes if you have more than one parition on your disk and the
other is not encrypted ? Is that read only as well ?

I really need to find time to explore the newer versions of TC more
fully.

What happens if you access a UNC read-write share on a different
computer and write to a file ? IE "\\MachineB\MyFolder\test.dcv"
Not that this would solve your issue but I am curious

Regards,
Shaun.

>
>Comments please...
>
>regards
>
>thang

[thang ornithorhynchus]

On Wed, 02 Sep 2009 19:21:51 +0100, Shaun <***@sedc3wciwhciecw.com>
wrote:

>>On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:
>
>Hi Thang,
>
>>Shaun, what you brought to my attention about "hiddendevs" etc, and
>>then Wilders and Schneier comments (fora, not personally) regarding
>>same, leads me to consider the use of encrypted containers on TC
>>hidden volumes - but one proviso, use of another proprietary container
>>method so that if, and its a big if, TC *has* been compromised
>>(perhaps from the ground up, who knows?), then at base level there
>>will be a *non-TC* container with industrial secrets or whatever in it
>>which will resist cracking.
>>
>>I have therefore tried DC but it mounts as a disk, and as you know,
>>using hidden OS option under TC 6.2a, all non-encrypted devices or
>>partitions are read only. DC constructed the disk and mounted it, but
>>it could not format it because once it was mounted, it became a
>>write-protected non-encrypted device and therefore useless for the
>>above purpose. It could not even be formatted, let alone written to
>>by data.
>
>I see. TC driver must be monitoring all the mounts or drive letters,
>and putting hooks into any drives it sees appearing.
>
>Personally I think that preventing write access to different mounted
>disk devices is a bit of overkill really. There really should be an
>option to turn this off when their hidden os is in use.
>
> Perhaps a mod to their driver might be a good idea...

I agree with the toggle but careful now...it does mandate total
secrecy so it does what it is intended to. Anything written must be
to hidden volumes on fully encrytped devices which outside of
electronic leakage is foolproof.
>
>>
>>I need to know, as an amateur cryptologist, whether there are any
>>non-TC encrytped containers on the market which do *not* mount as a
>>device or partition? Any ideas?
>
>The problem with that is that you would be very limited what you could
>do with the data. Yould have to copy it somehwhere. I guess it is
>possible to make a reader or even read-write scheme to allow the
>container to be opened in the form of a window showing the files.
>However as soon as the files are moved out of the window, then they
>are vulnerable as they would not be copy protected. We don't
>unfortunately have such a program however.
>
>I do have another idea I've thought about for a long time, but I can't
>disclose it here, at least not yet.

I came across only one in Sarah Deans comparison which foots the bill,
Cryptogram Directories which is OTFE folders with some excellent
attributes. That is, not mounted as far as I can see. So I might
try this on an encrypted hidden volume and see what happens.
>
>> I could Google but this seems an
>>interesting topic which could even be of use to you (Shaun) in the
>>development of the next species of DC and DCPP - use *with* TC as an
>>alternative in case the original (TC) is compromised - mix and match.
>>Heck, I'll even script the blurb for your web page if you like :)
>>
>
>>Shaun, following on your footsteps, if I was paranoid, which I am not
>>really, then I would think that the construction of TC is targeted
>>towards ensuring that TC, and **ONLY** TC can be used to write to when
>>the hidden volume (OS) option is used :) No-one seems to have picked
>>up on this...
>
>What happes if you have more than one parition on your disk and the
>other is not encrypted ? Is that read only as well ?

Yes if you are operating from your hidden OS. Otherwise, no.
>
>I really need to find time to explore the newer versions of TC more
>fully.

For you it won't take long. I will be interested in your
non-proprietary opinions.
>
>What happens if you access a UNC read-write share on a different
>computer and write to a file ? IE "\\MachineB\MyFolder\test.dcv"
>Not that this would solve your issue but I am curious

No idea. But its mounted just on LAN rather than the local machine
then you have intermachines issues (leakage) and complexity which
probably isn't relevant to the majority.
>
>Regards,
>Shaun.
>
>>
>cheers

thang

[thang ornithorhynchus]

On Thu, 03 Sep 2009 19:16:00 +0800, thang ornithorhynchus
<***@spitzola.com.org.net> wrote:

>On Wed, 02 Sep 2009 19:21:51 +0100, Shaun <***@sedc3wciwhciecw.com>
>wrote:
>
>>>On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:
>>
>>Hi Thang,
>>
>>>Shaun, what you brought to my attention about "hiddendevs" etc, and
>>>then Wilders and Schneier comments (fora, not personally) regarding
>>>same, leads me to consider the use of encrypted containers on TC
>>>hidden volumes - but one proviso, use of another proprietary container
>>>method so that if, and its a big if, TC *has* been compromised
>>>(perhaps from the ground up, who knows?), then at base level there
>>>will be a *non-TC* container with industrial secrets or whatever in it
>>>which will resist cracking.
>>>
>>>I have therefore tried DC but it mounts as a disk, and as you know,
>>>using hidden OS option under TC 6.2a, all non-encrypted devices or
>>>partitions are read only. DC constructed the disk and mounted it, but
>>>it could not format it because once it was mounted, it became a
>>>write-protected non-encrypted device and therefore useless for the
>>>above purpose. It could not even be formatted, let alone written to
>>>by data.
>>
>>I see. TC driver must be monitoring all the mounts or drive letters,
>>and putting hooks into any drives it sees appearing.
>>
>>Personally I think that preventing write access to different mounted
>>disk devices is a bit of overkill really. There really should be an
>>option to turn this off when their hidden os is in use.
>>
>> Perhaps a mod to their driver might be a good idea...
>
>I agree with the toggle but careful now...it does mandate total
>secrecy so it does what it is intended to. Anything written must be
>to hidden volumes on fully encrytped devices which outside of
>electronic leakage is foolproof.
>>
>>>
>>>I need to know, as an amateur cryptologist, whether there are any
>>>non-TC encrytped containers on the market which do *not* mount as a
>>>device or partition? Any ideas?
>>
>>The problem with that is that you would be very limited what you could
>>do with the data. Yould have to copy it somehwhere. I guess it is
>>possible to make a reader or even read-write scheme to allow the
>>container to be opened in the form of a window showing the files.
>>However as soon as the files are moved out of the window, then they
>>are vulnerable as they would not be copy protected. We don't
>>unfortunately have such a program however.
>>
>>I do have another idea I've thought about for a long time, but I can't
>>disclose it here, at least not yet.
>
>I came across only one in Sarah Deans comparison which foots the bill,
>Cryptogram Directories which is OTFE folders with some excellent
>attributes. That is, not mounted as far as I can see. So I might
>try this on an encrypted hidden volume and see what happens.
>>
Belay that. It provides a master key which can be used to unlock any
other user data which I find ridiculous and insecure.

I have found one which works and am testing it from my TC-encrypted W7
7600 OS on a TC- hidden volume in a TC-encrypted drive. It is called
FlyCryptor and it works perfectly. However I don't know if it uses
256 key etc so I am emailing them. It does not appear on Sarah Dean's
comparison. I will post when/if I get a response from them.

[thang ornithorhynchus]

On Sat, 05 Sep 2009 07:52:44 +0800, thang ornithorhynchus
<***@spitzola.com.org.net> wrote:

>On Thu, 03 Sep 2009 19:16:00 +0800, thang ornithorhynchus
><***@spitzola.com.org.net> wrote:
>
>>On Wed, 02 Sep 2009 19:21:51 +0100, Shaun <***@sedc3wciwhciecw.com>
>>wrote:
>>
>>>>On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:
>>>
>>>Hi Thang,
>>>
>>>>Shaun, what you brought to my attention about "hiddendevs" etc, and
>>>>then Wilders and Schneier comments (fora, not personally) regarding
>>>>same, leads me to consider the use of encrypted containers on TC
>>>>hidden volumes - but one proviso, use of another proprietary container
>>>>method so that if, and its a big if, TC *has* been compromised
>>>>(perhaps from the ground up, who knows?), then at base level there
>>>>will be a *non-TC* container with industrial secrets or whatever in it
>>>>which will resist cracking.
>>>>
>>>>I have therefore tried DC but it mounts as a disk, and as you know,
>>>>using hidden OS option under TC 6.2a, all non-encrypted devices or
>>>>partitions are read only. DC constructed the disk and mounted it, but
>>>>it could not format it because once it was mounted, it became a
>>>>write-protected non-encrypted device and therefore useless for the
>>>>above purpose. It could not even be formatted, let alone written to
>>>>by data.
>>>
>>>I see. TC driver must be monitoring all the mounts or drive letters,
>>>and putting hooks into any drives it sees appearing.
>>>
>>>Personally I think that preventing write access to different mounted
>>>disk devices is a bit of overkill really. There really should be an
>>>option to turn this off when their hidden os is in use.
>>>
>>> Perhaps a mod to their driver might be a good idea...
>>
>>I agree with the toggle but careful now...it does mandate total
>>secrecy so it does what it is intended to. Anything written must be
>>to hidden volumes on fully encrytped devices which outside of
>>electronic leakage is foolproof.
>>>
>>>>
>>>>I need to know, as an amateur cryptologist, whether there are any
>>>>non-TC encrytped containers on the market which do *not* mount as a
>>>>device or partition? Any ideas?
>>>
>>>The problem with that is that you would be very limited what you could
>>>do with the data. Yould have to copy it somehwhere. I guess it is
>>>possible to make a reader or even read-write scheme to allow the
>>>container to be opened in the form of a window showing the files.
>>>However as soon as the files are moved out of the window, then they
>>>are vulnerable as they would not be copy protected. We don't
>>>unfortunately have such a program however.
>>>
>>>I do have another idea I've thought about for a long time, but I can't
>>>disclose it here, at least not yet.
>>
>>I came across only one in Sarah Deans comparison which foots the bill,
>>Cryptogram Directories which is OTFE folders with some excellent
>>attributes. That is, not mounted as far as I can see. So I might
>>try this on an encrypted hidden volume and see what happens.
>>>
>Belay that. It provides a master key which can be used to unlock any
>other user data which I find ridiculous and insecure.
>
>I have found one which works and am testing it from my TC-encrypted W7
>7600 OS on a TC- hidden volume in a TC-encrypted drive. It is called
>FlyCryptor and it works perfectly. However I don't know if it uses
>256 key etc so I am emailing them. It does not appear on Sarah Dean's
>comparison. I will post when/if I get a response from them.

Well I got a response from them regarding FlyCryptor. It seems a
satisfactory OTF directory/folder encryptor for use in conjunction
with TC, for those (such as I) who do not entirely want to put *all*
of my trust in one vendor (even though it is open source and free).

Here is there response to my query regarding the type of key etc.

Re: General question?
From: Everstrike Information (***@everstrike.com)
Sent: ***************
To: S***** H*** (********@hotmail.com)


Thank you for your message.

We use a stream cipher encryption algorithm RC4 (Key length = 256 bit)
that recommended by RSA Security's Official Guide to Cryptography.
This algorithm is strong enough. It is used in popular protocols such
as Secure Sockets Layer (SSL) and WEP (to secure wireless networks).

Feel free to contact us if you have any questions.

Regards,
Everstrike Software

I am happy with this, for use with TC. It works well on Windows 7 as
well.

thang

[thang ornithorhynchus]

On Wed, 30 Sep 2009 19:57:40 +0800, thang ornithorhynchus
<***@spitzola.com.org.net> wrote:

>On Sat, 05 Sep 2009 07:52:44 +0800, thang ornithorhynchus
><***@spitzola.com.org.net> wrote:
>
>>On Thu, 03 Sep 2009 19:16:00 +0800, thang ornithorhynchus
>><***@spitzola.com.org.net> wrote:
>>
>>>On Wed, 02 Sep 2009 19:21:51 +0100, Shaun <***@sedc3wciwhciecw.com>
>>>wrote:
>>>
>>>>>On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:
>>>>
>>>>Hi Thang,
>>>>
>>>>>Shaun, what you brought to my attention about "hiddendevs" etc, and
>>>>>then Wilders and Schneier comments (fora, not personally) regarding
>>>>>same, leads me to consider the use of encrypted containers on TC
>>>>>hidden volumes - but one proviso, use of another proprietary container
>>>>>method so that if, and its a big if, TC *has* been compromised
>>>>>(perhaps from the ground up, who knows?), then at base level there
>>>>>will be a *non-TC* container with industrial secrets or whatever in it
>>>>>which will resist cracking.
>>>>>
>>>>>I have therefore tried DC but it mounts as a disk, and as you know,
>>>>>using hidden OS option under TC 6.2a, all non-encrypted devices or
>>>>>partitions are read only. DC constructed the disk and mounted it, but
>>>>>it could not format it because once it was mounted, it became a
>>>>>write-protected non-encrypted device and therefore useless for the
>>>>>above purpose. It could not even be formatted, let alone written to
>>>>>by data.
>>>>
>>>>I see. TC driver must be monitoring all the mounts or drive letters,
>>>>and putting hooks into any drives it sees appearing.
>>>>
>>>>Personally I think that preventing write access to different mounted
>>>>disk devices is a bit of overkill really. There really should be an
>>>>option to turn this off when their hidden os is in use.
>>>>
>>>> Perhaps a mod to their driver might be a good idea...
>>>
>>>I agree with the toggle but careful now...it does mandate total
>>>secrecy so it does what it is intended to. Anything written must be
>>>to hidden volumes on fully encrytped devices which outside of
>>>electronic leakage is foolproof.
>>>>
>>>>>
>>>>>I need to know, as an amateur cryptologist, whether there are any
>>>>>non-TC encrytped containers on the market which do *not* mount as a
>>>>>device or partition? Any ideas?
>>>>
>>>>The problem with that is that you would be very limited what you could
>>>>do with the data. Yould have to copy it somehwhere. I guess it is
>>>>possible to make a reader or even read-write scheme to allow the
>>>>container to be opened in the form of a window showing the files.
>>>>However as soon as the files are moved out of the window, then they
>>>>are vulnerable as they would not be copy protected. We don't
>>>>unfortunately have such a program however.
>>>>
>>>>I do have another idea I've thought about for a long time, but I can't
>>>>disclose it here, at least not yet.
>>>
>>>I came across only one in Sarah Deans comparison which foots the bill,
>>>Cryptogram Directories which is OTFE folders with some excellent
>>>attributes. That is, not mounted as far as I can see. So I might
>>>try this on an encrypted hidden volume and see what happens.
>>>>
>>Belay that. It provides a master key which can be used to unlock any
>>other user data which I find ridiculous and insecure.
>>
>>I have found one which works and am testing it from my TC-encrypted W7
>>7600 OS on a TC- hidden volume in a TC-encrypted drive. It is called
>>FlyCryptor and it works perfectly. However I don't know if it uses
>>256 key etc so I am emailing them. It does not appear on Sarah Dean's
>>comparison. I will post when/if I get a response from them.
>
>Well I got a response from them regarding FlyCryptor. It seems a
>satisfactory OTF directory/folder encryptor for use in conjunction
>with TC, for those (such as I) who do not entirely want to put *all*
>of my trust in one vendor (even though it is open source and free).
>
>Here is there response to my query regarding the type of key etc.

My God, I spelt "their" as "there". Head hangs in shame, obviously
premature senility. Apologies.

thang
>
>Re: General question?
>From: Everstrike Information (***@everstrike.com)
>Sent: ***************
>To: S***** H*** (********@hotmail.com)
>
>
>Thank you for your message.
>
>We use a stream cipher encryption algorithm RC4 (Key length = 256 bit)
>that recommended by RSA Security's Official Guide to Cryptography.
>This algorithm is strong enough. It is used in popular protocols such
>as Secure Sockets Layer (SSL) and WEP (to secure wireless networks).
>
>Feel free to contact us if you have any questions.
>
>Regards,
>Everstrike Software
>
>I am happy with this, for use with TC. It works well on Windows 7 as
>well.
>
>thang

[John Smith]

thang ornithorhynchus wrote:
> On Wed, 30 Sep 2009 19:57:40 +0800, thang ornithorhynchus
> <***@spitzola.com.org.net> wrote:
>
>> On Sat, 05 Sep 2009 07:52:44 +0800, thang ornithorhynchus
>> <***@spitzola.com.org.net> wrote:
>>
>>> On Thu, 03 Sep 2009 19:16:00 +0800, thang ornithorhynchus
>>> <***@spitzola.com.org.net> wrote:
>>>
>>>> On Wed, 02 Sep 2009 19:21:51 +0100, Shaun <***@sedc3wciwhciecw.com>
>>>> wrote:
>>>>
>>>>>> On Fri, 28 Aug 2009 09:45:37 +0800, in alt.security.scramdisk you wrote:
>>>>> Hi Thang,
>>>>>
>>>>>> Shaun, what you brought to my attention about "hiddendevs" etc, and
>>>>>> then Wilders and Schneier comments (fora, not personally) regarding
>>>>>> same, leads me to consider the use of encrypted containers on TC
>>>>>> hidden volumes - but one proviso, use of another proprietary container
>>>>>> method so that if, and its a big if, TC *has* been compromised
>>>>>> (perhaps from the ground up, who knows?), then at base level there
>>>>>> will be a *non-TC* container with industrial secrets or whatever in it
>>>>>> which will resist cracking.
>>>>>>
>>>>>> I have therefore tried DC but it mounts as a disk, and as you know,
>>>>>> using hidden OS option under TC 6.2a, all non-encrypted devices or
>>>>>> partitions are read only. DC constructed the disk and mounted it, but
>>>>>> it could not format it because once it was mounted, it became a
>>>>>> write-protected non-encrypted device and therefore useless for the
>>>>>> above purpose. It could not even be formatted, let alone written to
>>>>>> by data.
>>>>> I see. TC driver must be monitoring all the mounts or drive letters,
>>>>> and putting hooks into any drives it sees appearing.
>>>>>
>>>>> Personally I think that preventing write access to different mounted
>>>>> disk devices is a bit of overkill really. There really should be an
>>>>> option to turn this off when their hidden os is in use.
>>>>>
>>>>> Perhaps a mod to their driver might be a good idea...
>>>> I agree with the toggle but careful now...it does mandate total
>>>> secrecy so it does what it is intended to. Anything written must be
>>>> to hidden volumes on fully encrytped devices which outside of
>>>> electronic leakage is foolproof.
>>>>>> I need to know, as an amateur cryptologist, whether there are any
>>>>>> non-TC encrytped containers on the market which do *not* mount as a
>>>>>> device or partition? Any ideas?
>>>>> The problem with that is that you would be very limited what you could
>>>>> do with the data. Yould have to copy it somehwhere. I guess it is
>>>>> possible to make a reader or even read-write scheme to allow the
>>>>> container to be opened in the form of a window showing the files.
>>>>> However as soon as the files are moved out of the window, then they
>>>>> are vulnerable as they would not be copy protected. We don't
>>>>> unfortunately have such a program however.
>>>>>
>>>>> I do have another idea I've thought about for a long time, but I can't
>>>>> disclose it here, at least not yet.
>>>> I came across only one in Sarah Deans comparison which foots the bill,
>>>> Cryptogram Directories which is OTFE folders with some excellent
>>>> attributes. That is, not mounted as far as I can see. So I might
>>>> try this on an encrypted hidden volume and see what happens.
>>> Belay that. It provides a master key which can be used to unlock any
>>> other user data which I find ridiculous and insecure.
>>>
>>> I have found one which works and am testing it from my TC-encrypted W7
>>> 7600 OS on a TC- hidden volume in a TC-encrypted drive. It is called
>>> FlyCryptor and it works perfectly. However I don't know if it uses
>>> 256 key etc so I am emailing them. It does not appear on Sarah Dean's
>>> comparison. I will post when/if I get a response from them.
>> Well I got a response from them regarding FlyCryptor. It seems a
>> satisfactory OTF directory/folder encryptor for use in conjunction
>> with TC, for those (such as I) who do not entirely want to put *all*
>> of my trust in one vendor (even though it is open source and free).
>>
>> Here is there response to my query regarding the type of key etc.
>
> My God, I spelt "their" as "there". Head hangs in shame, obviously
> premature senility. Apologies.
>
> thang
>> Re: General question?
>> From: Everstrike Information (***@everstrike.com)
>> Sent: ***************
>> To: S***** H*** (********@hotmail.com)
>>
>>
>> Thank you for your message.
>>
>> We use a stream cipher encryption algorithm RC4 (Key length = 256 bit)
>> that recommended by RSA Security's Official Guide to Cryptography.
>> This algorithm is strong enough. It is used in popular protocols such
>> as Secure Sockets Layer (SSL) and WEP (to secure wireless networks).
>>
>> Feel free to contact us if you have any questions.
>>
>> Regards,
>> Everstrike Software
>>
>> I am happy with this, for use with TC. It works well on Windows 7 as
>> well.
>>
>> thang
>
>

If you want to talk about true crypt, a software solution that got
hacked and busted by an 18 yr old, you're in the wrong group,

[Kulin Remailer]

On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
snipped
>
>If you want to talk about true crypt, a software solution that got
>hacked and busted by an 18 yr old, you're in the wrong group,

Are you really that ignorant?

I suggest you go to alt.binaries.pictures.comics. You'll like it a lot
better there.

[thang ornithorhynchus]

On 28 Dec 2009 04:02:49 -0000, Kulin Remailer <***@reece.net.au>
wrote:

>On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
>snipped
>>
>>If you want to talk about true crypt, a software solution that got
>>hacked and busted by an 18 yr old, you're in the wrong group,
>
>Are you really that ignorant?
>
>I suggest you go to alt.binaries.pictures.comics. You'll like it a lot
>better there.

Its a troll. Don't feed.

thang
>

[John Smith]

thang ornithorhynchus wrote:
> On 28 Dec 2009 04:02:49 -0000, Kulin Remailer <***@reece.net.au>
> wrote:
>
>> On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
>> snipped
>>> If you want to talk about true crypt, a software solution that got
>>> hacked and busted by an 18 yr old, you're in the wrong group,
>> Are you really that ignorant?
>>
>> I suggest you go to alt.binaries.pictures.comics. You'll like it a lot
>> better there.
>
> Its a troll. Don't feed.
>
> thang

[George Orwell]

On Tue, 29 Dec 2009 17:01:11 +0800, thang ornithorhynchus
<***@spitzola.com.org.net> wrote:

>On 28 Dec 2009 04:02:49 -0000, Kulin Remailer <***@reece.net.au>
>wrote:
>
>>On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
>>snipped
>>>
>>>If you want to talk about true crypt, a software solution that got
>>>hacked and busted by an 18 yr old, you're in the wrong group,
>>
>>Are you really that ignorant?
>>
>>I suggest you go to alt.binaries.pictures.comics. You'll like it a >>lot
>>better there.
>
>Its a troll. Don't feed.
>
>thang
>>

"This man is miserable and needs help. 02 August 2009 09:46

Peter seems to seek fame. On his own page and blog he deletes all
posts which reveals the truth behind his "achievement".

He took MBR rootkit idea known FOR YEARS and started screaming about
something he doesn't understand on his own.

Thinking Peter's way we can say: RSA can be bypassed. RSA needs to
fix the issue because a keylogger can capture the password and
decrypt data protected with 4096bit key? Steganos need a fix too?
Peter? ;)

He offends others by saying "TrueCrypt is lame" because "they do not
want to fix the issue". At the time this young man grows up he will
understand what is the difference between issue and compromised
system with usual rootkit."

More here:
http://preview.tinyurl.com/yb6owjd
=====
" The idea is lame and old 31 July 2009 10:21

This is very old story. More advanced MBR viruses are available for
years.

You can't install anything on your operating system because antivirus
software detects MBR modification. Maybe he doesn't know it because
"he is 18".

This rusty idea has also nothing common with Truecrypt. Truecrypt
purpose is to encrypt your data and the kid is talking about a virus.
Many MBR viruses are available for years.

There's nothing fancy in this article except the scream of wanna be
young man. Poor man."

More here:
http://preview.tinyurl.com/y8mdy2r
=====
No, I'm not a troll, but you are an uninformed loudmouth who doesn't
belong in this group. Again, I suggest alt.binaries.pictures.comics as
the group for you.


Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it

[thang ornithorhynchus]

On Wed, 30 Dec 2009 04:45:15 +0100 (CET), George Orwell
<***@mixmaster.it> wrote:

>On Tue, 29 Dec 2009 17:01:11 +0800, thang ornithorhynchus
><***@spitzola.com.org.net> wrote:
>
>>On 28 Dec 2009 04:02:49 -0000, Kulin Remailer <***@reece.net.au>
>>wrote:
>>
>>>On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
>>>snipped
>>>>
>>>>If you want to talk about true crypt, a software solution that got
>>>>hacked and busted by an 18 yr old, you're in the wrong group,
>>>
>>>Are you really that ignorant?
>>>
>>>I suggest you go to alt.binaries.pictures.comics. You'll like it a >>lot
>>>better there.
>>
>>Its a troll. Don't feed.
>>
>>thang
>>>
>
>"This man is miserable and needs help. 02 August 2009 09:46
>
>Peter seems to seek fame. On his own page and blog he deletes all
>posts which reveals the truth behind his "achievement".
>
>He took MBR rootkit idea known FOR YEARS and started screaming about
>something he doesn't understand on his own.
>
>Thinking Peter's way we can say: RSA can be bypassed. RSA needs to
>fix the issue because a keylogger can capture the password and
>decrypt data protected with 4096bit key? Steganos need a fix too?
>Peter? ;)
>
>He offends others by saying "TrueCrypt is lame" because "they do not
>want to fix the issue". At the time this young man grows up he will
>understand what is the difference between issue and compromised
>system with usual rootkit."
>
>More here:
>http://preview.tinyurl.com/yb6owjd
>=====
>" The idea is lame and old 31 July 2009 10:21
>
>This is very old story. More advanced MBR viruses are available for
>years.
>
>You can't install anything on your operating system because antivirus
>software detects MBR modification. Maybe he doesn't know it because
>"he is 18".
>
>This rusty idea has also nothing common with Truecrypt. Truecrypt
>purpose is to encrypt your data and the kid is talking about a virus.
>Many MBR viruses are available for years.
>
>There's nothing fancy in this article except the scream of wanna be
>young man. Poor man."
>
>More here:
>http://preview.tinyurl.com/y8mdy2r
>=====
>No, I'm not a troll, but you are an uninformed loudmouth who doesn't
>belong in this group. Again, I suggest alt.binaries.pictures.comics as
>the group for you.
>
>
>Il mittente di questo messaggio|The sender address of this
>non corrisponde ad un utente |message is not related to a real
>reale ma all'indirizzo fittizio|person but to a fake address of an
>di un sistema anonimizzatore |anonymous system
>Per maggiori informazioni |For more info
> https://www.mixmaster.it

No no no. You misunderstand, "John Smith" to whom you responded, is a
troll. I was suggesting that you do not respond, therein not feeding
the troll. I am the OP and hardly misinformed. We are having wires
crossed mein herr.

thang

[John Smith]

thang ornithorhynchus wrote:
> On Wed, 30 Dec 2009 04:45:15 +0100 (CET), George Orwell
> <***@mixmaster.it> wrote:
>
>> On Tue, 29 Dec 2009 17:01:11 +0800, thang ornithorhynchus
>> <***@spitzola.com.org.net> wrote:
>>
>>> On 28 Dec 2009 04:02:49 -0000, Kulin Remailer <***@reece.net.au>
>>> wrote:
>>>
>>>> On Mon, 05 Oct 2009 22:01:47 -0700, John Smith <***@invalid.org> wrote:
>>>> snipped
>>>>> If you want to talk about true crypt, a software solution that got
>>>>> hacked and busted by an 18 yr old, you're in the wrong group,
>>>> Are you really that ignorant?
>>>>
>>>> I suggest you go to alt.binaries.pictures.comics. You'll like it a >>lot
>>>> better there.
>>> Its a troll. Don't feed.
>>>
>>> thang
>> "This man is miserable and needs help. 02 August 2009 09:46
>>
>> Peter seems to seek fame. On his own page and blog he deletes all
>> posts which reveals the truth behind his "achievement".
>>
>> He took MBR rootkit idea known FOR YEARS and started screaming about
>> something he doesn't understand on his own.
>>
>> Thinking Peter's way we can say: RSA can be bypassed. RSA needs to
>> fix the issue because a keylogger can capture the password and
>> decrypt data protected with 4096bit key? Steganos need a fix too?
>> Peter? ;)
>>
>> He offends others by saying "TrueCrypt is lame" because "they do not
>> want to fix the issue". At the time this young man grows up he will
>> understand what is the difference between issue and compromised
>> system with usual rootkit."
>>
>> More here:
>> http://preview.tinyurl.com/yb6owjd
>> =====
>> " The idea is lame and old 31 July 2009 10:21
>>
>> This is very old story. More advanced MBR viruses are available for
>> years.
>>
>> You can't install anything on your operating system because antivirus
>> software detects MBR modification. Maybe he doesn't know it because
>> "he is 18".
>>
>> This rusty idea has also nothing common with Truecrypt. Truecrypt
>> purpose is to encrypt your data and the kid is talking about a virus.
>> Many MBR viruses are available for years.
>>
>> There's nothing fancy in this article except the scream of wanna be
>> young man. Poor man."
>>
>> More here:
>> http://preview.tinyurl.com/y8mdy2r
>> =====
>> No, I'm not a troll, but you are an uninformed loudmouth who doesn't
>> belong in this group. Again, I suggest alt.binaries.pictures.comics as
>> the group for you.
>>
>>
>> Il mittente di questo messaggio|The sender address of this
>> non corrisponde ad un utente |message is not related to a real
>> reale ma all'indirizzo fittizio|person but to a fake address of an
>> di un sistema anonimizzatore |anonymous system
>> Per maggiori informazioni |For more info
>> https://www.mixmaster.it
>
> No no no. You misunderstand, "John Smith" to whom you responded, is a
> troll. I was suggesting that you do not respond, therein not feeding
> the troll. I am the OP and hardly misinformed. We are having wires
> crossed mein herr.
>
> thang

[Kulin Remailer]

> No no no. You misunderstand, "John Smith" to whom you responded, is a
> troll. I was suggesting that you do not respond, therein not feeding
> the troll. I am the OP and hardly misinformed. We are having wires
> crossed mein herr.
>
> thang

Well, if that be true, then it is evident that it is I who should move
over to alt.binaries.pictures.comics until I can properly figure out how
to reply to the proper entity on Usenet. :o)

(Humble pie is not that bad if one uses enough ketchup.)