Discussion:
You still around Shaun?
(too old to reply)
thang thylacinus
2013-02-13 13:17:22 UTC
Permalink
Raw Message
Do you still look this old NG up from time to time?

thang
Shaun Hollingworth
2013-06-21 15:43:56 UTC
Permalink
Raw Message
On Wed, 13 Feb 2013 21:17:22 +0800, thang thylacinus
Post by thang thylacinus
Do you still look this old NG up from time to time?
thang
Hi thang,

Still here. First time in ages though. Very little going on here now.
Perhaps I might start a blog!

Regards,
Shaun.

PS: You might have an email from me, by mistake. My apologies for
that.
John Smith
2013-08-10 19:52:33 UTC
Permalink
Raw Message
Post by Shaun Hollingworth
On Wed, 13 Feb 2013 21:17:22 +0800, thang thylacinus
Post by thang thylacinus
Do you still look this old NG up from time to time?
thang
Hi thang,
Still here. First time in ages though. Very little going on here now.
Perhaps I might start a blog!
Regards,
Shaun.
PS: You might have an email from me, by mistake. My apologies for
that.
Great new product line up Shaun!
thang ornerythinchus
2013-11-03 05:12:33 UTC
Permalink
Raw Message
On Fri, 21 Jun 2013 16:43:56 +0100, Shaun Hollingworth
Post by Shaun Hollingworth
On Wed, 13 Feb 2013 21:17:22 +0800, thang thylacinus
Post by thang thylacinus
Do you still look this old NG up from time to time?
thang
Hi thang,
Still here. First time in ages though. Very little going on here now.
Perhaps I might start a blog!
Regards,
Shaun.
PS: You might have an email from me, by mistake. My apologies for
that.
I haven't checked all my old addresses Shaun so I can't say no, but I
don't seem to have received an email from you. My usenet email
address of course isn't valid - pardon my paranoia :)

Hey apologies about the belatedness of this response. I re-created my
windows OS but forgot that the database for Agent was in the documents
and settings area which I didn't back up. Then I forgot to include
a.s.scramdisk when I tried to resurrect my favourite usenet folders.

I am so sorry for that. As usual, it is good to hear from you.

I have a lot of questions and observations actually.

Firstly, your DCPP product, now at v5.00 I believe. I don't own it so
I am simply working off your Securestar's website. It works with Win
8 so it must work with GPT and UEFI. However, have you gotten it to
work yet with MS secure boot hardware implementations? The only Win 8
in my house is on my wife's ultrabook - my system is still Win 7 X64
and will be for a long time as I don't particularly like Win 8 for a
few reasons (one of which may be that I am a dinosaur). My
understanding is that secure boot works on MS key authentication at
boot and if not disabled will not permit any non-Win 8 OS to load.
Does DCPP have a key which needs to be installed or does it require
secure boot to be disabled? Or, have you somehow gotten around the
entire issue in another way?

In any case, however you have approached the matter, you now have a
distinct lead over Truecrypt as it has yet to be implemented in
UEFI/GPT compatibility. DCPP has always had the lead over TC in that
the hidden OS is hidden within the "empty space" of the decoy OS with
DCPP, whereas the partitioning which is required by TC in my view
tends to attenuate any position of "plausible deniability" (eg TC
partitioning for a 2GB primary must be one third and two thirds if one
wishes to maximise space under NT for the hidden OS - it's a giveaway,
but probably not beyond reasonable doubt - a vulnerability that I
recall DCPP doesn't have).

But TC remains free and open source and potentially without backdoor.

Have you thought about Snowden's revelations especially those relating
to back doors in encryption products? This could be a snarky subject
in an open forum, google etc, but I think here on Usenet it is
probably ok to discuss. In this regard, another marketing positive
Securestar has is that it is a German company and there is little love
lost between Deutsch intelligence and that of the US. This means in
my book there is very little prospect that a backdoor has been built
into DCPP at least as far as the NSA etc goes.

I don't know what German requriements are for encryption products - do
you have any info on that? Is there a key embargo or the like in
Germany? I would think not as you would probably not be working
within such a system - your ethics are good and you were the first on
the scene with free OTF full encryption (scramdisk) for Windows, I
don't think you would accept such a system.

Not so with TC. I have been using it for years now (after first using
DCPP back in the day) without a thought but now I'm thinking. I'm
thinking it could be backdoored and even though there is a move now
for public contributions to an audit of its source code that would
take a long time as the code is certainly very complex. It would be a
search for a needle in a haystack. The best way in my view is to find
authors (such as you and Paul) who cannot be subverted due to your
background and sense of propriety. With TC, we don't even know who
the authors are - they could be anyone and they certainly had the
resources and time to build and update this product. You would know
how much effort that would take.

Can I ask one other thing? Back in the day, TC was built so as to
support Scramdisk. Were you ever consulted in any way about this? It
would be interesting if you could offer a titbit on who they are or
were. But I think you are as mystified as anyone else.

Shaun, a blog would be great. A forum and a blog would be better. But
if you go for either forum or a blog, be prepared for comments on back
doors, closed source vs open source and so on. I will be one of the
first to contribute if you do start a blog.
And, a blog with a forum will definitely enhance the marketability of
your products, without doubt. I run a small marketing firm (I won't
name it here) and I can tell you, having a forum is great for
business. Perhaps you can moderate it less than the TC forum which is
heavily moderated - ask a question about the devs and see what
happens. Also, you need to give your valid IP assigned email address
for the TC forum - my preference in security is to use throwaway email
addresses with Tor and Privoxy signup, Jave non-existent on my system
and scripting disabled. None of that acceptable at TC forums.

As I said, good to hear from you. I love security and discussions
thereof and, with Snowden, security has truly come into its age. Back
doors everywhere and collusion and subversion of the most devious
means...everywhere.

Over to you

thang
Shaun
2014-04-03 15:41:12 UTC
Permalink
Raw Message
On Sun, 03 Nov 2013 13:12:33 +0800, thang ornerythinchus
<***@gmail.com> wrote:

[...]
Post by thang ornerythinchus
I have a lot of questions and observations actually.
Firstly, your DCPP product, now at v5.00 I believe. I don't own it so
I am simply working off your Securestar's website. It works with Win
8 so it must work with GPT and UEFI. However, have you gotten it to
work yet with MS secure boot hardware implementations?
Yes it works with Secure Boot enabled.
Post by thang ornerythinchus
The only Win 8
in my house is on my wife's ultrabook - my system is still Win 7 X64
and will be for a long time as I don't particularly like Win 8 for a
few reasons (one of which may be that I am a dinosaur). My
understanding is that secure boot works on MS key authentication at
boot and if not disabled will not permit any non-Win 8 OS to load.
Does DCPP have a key which needs to be installed or does it require
secure boot to be disabled? Or, have you somehow gotten around the
entire issue in another way?
If I told you that then I'd have to....

No seriously - MS countersigned the binary. They will providing you
adhere to some rules which are ALL about security, and nothing to do
with them protecting their own interests. That was my experience
anyway. The main issue is not to permit any untrusted unsigned code to
be run. Then not to include code considered a security risk such as
some parts of the UEFI shell which we originally included.

They do want to know what the code is FOR as well, so a detailed
explanation was given which they were satisified with. They didn't
want to know how it worked, just what it was supposed to do.

As far as I know linux boot loaders have been signed too. The
experience we had with Microsoft was in fact VERY positive, and they
were extremely helpful, in assiting us to comply with their Secure
Boot requirements. No they didn't want to see the source code. ;-)
Post by thang ornerythinchus
In any case, however you have approached the matter, you now have a
distinct lead over Truecrypt as it has yet to be implemented in
UEFI/GPT compatibility. DCPP has always had the lead over TC in that
the hidden OS is hidden within the "empty space" of the decoy OS with
DCPP, whereas the partitioning which is required by TC in my view
tends to attenuate any position of "plausible deniability" (eg TC
partitioning for a 2GB primary must be one third and two thirds if one
wishes to maximise space under NT for the hidden OS - it's a giveaway,
but probably not beyond reasonable doubt - a vulnerability that I
recall DCPP doesn't have).
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Post by thang ornerythinchus
But TC remains free and open source and potentially without backdoor.
Indeed it is. Meanwhile the programmers seem to be begging and
starving. I wonder if I should send them something ?
Post by thang ornerythinchus
Have you thought about Snowden's revelations especially those relating
to back doors in encryption products?
I did read how they've supposedly got ways round SSL and how they had
a go at LavaBit.
Post by thang ornerythinchus
This could be a snarky subject
in an open forum, google etc, but I think here on Usenet it is
probably ok to discuss. In this regard, another marketing positive
Securestar has is that it is a German company and there is little love
lost between Deutsch intelligence and that of the US. This means in
my book there is very little prospect that a backdoor has been built
into DCPP at least as far as the NSA etc goes.
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
Post by thang ornerythinchus
I don't know what German requriements are for encryption products - do
you have any info on that? Is there a key embargo or the like in
Germany?
There are none as far as I know. No key restriction, no mandated back
doors. Here in the UK there are no restrictions either. It's a
European wide regime.

Domestically for UK users we have RIPA which allows for the demand of
your encryption keys... Very draconian for a supposedly free country
and I made my views about it known at the time.
Post by thang ornerythinchus
I would think not as you would probably not be working
within such a system - your ethics are good and you were the first on
the scene with free OTF full encryption (scramdisk) for Windows, I
don't think you would accept such a system.
I'd see if I could find a job programming software for sewerage works
before I would accept such a system. If I ever stop doing this, and
refuse to tell you why, but am still hanging around on here bored,
you can fear the worst. If I do tell you why, for example I say I won
the lottery, or have got another job sat at Microsoft, or have retired
to the seaside then that will tell you all is well. If ever I am got
at, and have to STOP doing this job, and I just say "I'm not doing it
any more" and refuse a reason then you can be assured of the worst.
Post by thang ornerythinchus
Not so with TC. I have been using it for years now (after first using
DCPP back in the day) without a thought but now I'm thinking. I'm
thinking it could be backdoored and even though there is a move now
for public contributions to an audit of its source code that would
take a long time as the code is certainly very complex.
I don't spot any backdoors from any kind of casual look at the source.
I'm not sure how accurate the binaries are compared with the source
though.
Post by thang ornerythinchus
It would be a
search for a needle in a haystack. The best way in my view is to find
authors (such as you and Paul) who cannot be subverted due to your
background and sense of propriety.
With TC, we don't even know who
the authors are - they could be anyone and they certainly had the
resources and time to build and update this product. You would know
how much effort that would take.
Indeed. I also know how much someone with the necessary skills would
cost to employ... It's not just about encryption... For products
like DCPP there's 16 bit preboot code, so you include a working
knowledge of 16 bit cpu mode/BIOS, assembler, still needed even if
using "C" for most of it, (in our case it's all assembler) a knowledge
of the kernel mode, and all the vagaries that go with it, the traps
you can fall into down there, the Win32 subsystem, and how to deal
with services, to avoid the need for elevation or administrator access
(essential for corporate users) Now there's the added requirement to
deal with UEFI on top of all that. I do it all right now, and I do it
cheaply too. It's because I enjoy it. But I couldn't do this, and do a
full time job doing something else to earn a living AS WELL! ;-)

Regards,
Shaun.
Post by thang ornerythinchus
Can I ask one other thing? Back in the day, TC was built so as to
support Scramdisk. Were you ever consulted in any way about this? It
would be interesting if you could offer a titbit on who they are or
were. But I think you are as mystified as anyone else.
They just hijacked the driver. They didn't ask, and the licence didn't
allow them to do it. I was not consulted at all.
Post by thang ornerythinchus
Shaun, a blog would be great. A forum and a blog would be better. But
if you go for either forum or a blog, be prepared for comments on back
doors, closed source vs open source and so on. I will be one of the
first to contribute if you do start a blog.
Personally I like opensource for this kind of software. The problem
is, it is simply not commercially viable and I rely on the work for my
living. Do you think TrueCrypt would have been UEFI compatible by now
had I publised our UEFI source code ? "So that's how they did it...."
of course. Actually it isn't that hard really. There's a few pennies
need to drop before anything worthwhile can be done, and it may be
that the way we did it isn't necessarily the best approach.
Post by thang ornerythinchus
And, a blog with a forum will definitely enhance the marketability of
your products, without doubt. I run a small marketing firm (I won't
name it here) and I can tell you, having a forum is great for
business. Perhaps you can moderate it less than the TC forum which is
heavily moderated - ask a question about the devs and see what
happens.
All this from someone (ostensibly ?) concerned about our freedom ?
Post by thang ornerythinchus
Also, you need to give your valid IP assigned email address
for the TC forum - my preference in security is to use throwaway email
addresses with Tor and Privoxy signup, Jave non-existent on my system
and scripting disabled. None of that acceptable at TC forums.
Hmmm Makes me wonder exactly who is behind all this and how may of
them there are.
Post by thang ornerythinchus
As I said, good to hear from you. I love security and discussions
thereof and, with Snowden, security has truly come into its age. Back
doors everywhere and collusion and subversion of the most devious
means...everywhere.
Sorry I didn't reply sooner. I just keep forgetting to come here
nowadays as its usually so quiet.

Shaun.
Post by thang ornerythinchus
Over to you
thang
thang ornerythinchus
2014-06-02 08:11:02 UTC
Permalink
Raw Message
Post by Shaun
On Sun, 03 Nov 2013 13:12:33 +0800, thang ornerythinchus
[...]
Post by thang ornerythinchus
I have a lot of questions and observations actually.
Firstly, your DCPP product, now at v5.00 I believe. I don't own it so
I am simply working off your Securestar's website. It works with Win
8 so it must work with GPT and UEFI. However, have you gotten it to
work yet with MS secure boot hardware implementations?
Yes it works with Secure Boot enabled.
Post by thang ornerythinchus
The only Win 8
in my house is on my wife's ultrabook - my system is still Win 7 X64
and will be for a long time as I don't particularly like Win 8 for a
few reasons (one of which may be that I am a dinosaur). My
understanding is that secure boot works on MS key authentication at
boot and if not disabled will not permit any non-Win 8 OS to load.
Does DCPP have a key which needs to be installed or does it require
secure boot to be disabled? Or, have you somehow gotten around the
entire issue in another way?
If I told you that then I'd have to....
No seriously - MS countersigned the binary. They will providing you
adhere to some rules which are ALL about security, and nothing to do
with them protecting their own interests. That was my experience
anyway. The main issue is not to permit any untrusted unsigned code to
be run. Then not to include code considered a security risk such as
some parts of the UEFI shell which we originally included.
They do want to know what the code is FOR as well, so a detailed
explanation was given which they were satisified with. They didn't
want to know how it worked, just what it was supposed to do.
As far as I know linux boot loaders have been signed too. The
experience we had with Microsoft was in fact VERY positive, and they
were extremely helpful, in assiting us to comply with their Secure
Boot requirements. No they didn't want to see the source code. ;-)
Post by thang ornerythinchus
In any case, however you have approached the matter, you now have a
distinct lead over Truecrypt as it has yet to be implemented in
UEFI/GPT compatibility. DCPP has always had the lead over TC in that
the hidden OS is hidden within the "empty space" of the decoy OS with
DCPP, whereas the partitioning which is required by TC in my view
tends to attenuate any position of "plausible deniability" (eg TC
partitioning for a 2GB primary must be one third and two thirds if one
wishes to maximise space under NT for the hidden OS - it's a giveaway,
but probably not beyond reasonable doubt - a vulnerability that I
recall DCPP doesn't have).
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Really? I should have read this again before I responded to the
thread below (about the TC debacle).

Do you mean that for a 3Tb disc, you can set up a DCPP decoy of say
1Tb and a hidden OS of 1Tb, all in NTFS, and use of the decoy doesn't
endanger the contents of the hidden OS?

If so, this would potentially render DCPP as good as TC for multi use
purposes - besides the open source aspect of course.

Can you elaborate on this Shaun? With TC, because of NTFS protocol,
the maximum decoy OS must be same size as the hidden OS while the
second partition must be 2/3rds that of the entire disk (to maximise
hidden OS size). I imagine your configuration if using NTFS would
have the same limitations.
Post by Shaun
Post by thang ornerythinchus
But TC remains free and open source and potentially without backdoor.
Indeed it is. Meanwhile the programmers seem to be begging and
starving. I wonder if I should send them something ?
Post by thang ornerythinchus
Have you thought about Snowden's revelations especially those relating
to back doors in encryption products?
I did read how they've supposedly got ways round SSL and how they had
a go at LavaBit.
Post by thang ornerythinchus
This could be a snarky subject
in an open forum, google etc, but I think here on Usenet it is
probably ok to discuss. In this regard, another marketing positive
Securestar has is that it is a German company and there is little love
lost between Deutsch intelligence and that of the US. This means in
my book there is very little prospect that a backdoor has been built
into DCPP at least as far as the NSA etc goes.
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
I'll take your word for that. Until Snowden stated his preferred FDE
program was TC, there was probably no spotlight on TC either. DCPP
and DC don't have anywhere near the public awareness of TC, therefore
I think I can be assured there is not only no backdoor (I accept your
assurances, I have been acquainted with you for a long time and your
background is spotless) but there is no significant TLA spotlight at
the moment.

And German is good. Just like Singapore or HK as far as I am
concerned. NSA was even spying on Merkel from what I read.
Post by Shaun
Post by thang ornerythinchus
I don't know what German requriements are for encryption products - do
you have any info on that? Is there a key embargo or the like in
Germany?
There are none as far as I know. No key restriction, no mandated back
doors. Here in the UK there are no restrictions either. It's a
European wide regime.
Domestically for UK users we have RIPA which allows for the demand of
your encryption keys... Very draconian for a supposedly free country
and I made my views about it known at the time.
And do you think there is sufficient plausible deniability inherent in
a properly setup DCPP 5.0 to protect against RIPA were there to be
something of interest on the hidden OS?
Post by Shaun
Post by thang ornerythinchus
I would think not as you would probably not be working
within such a system - your ethics are good and you were the first on
the scene with free OTF full encryption (scramdisk) for Windows, I
don't think you would accept such a system.
I'd see if I could find a job programming software for sewerage works
before I would accept such a system. If I ever stop doing this, and
refuse to tell you why, but am still hanging around on here bored,
you can fear the worst. If I do tell you why, for example I say I won
the lottery, or have got another job sat at Microsoft, or have retired
to the seaside then that will tell you all is well. If ever I am got
at, and have to STOP doing this job, and I just say "I'm not doing it
any more" and refuse a reason then you can be assured of the worst.
Thank you Shaun. Thanks for the heads up re: "warrant canary".
Post by Shaun
Post by thang ornerythinchus
Not so with TC. I have been using it for years now (after first using
DCPP back in the day) without a thought but now I'm thinking. I'm
thinking it could be backdoored and even though there is a move now
for public contributions to an audit of its source code that would
take a long time as the code is certainly very complex.
I don't spot any backdoors from any kind of casual look at the source.
I'm not sure how accurate the binaries are compared with the source
though.
They correspond, one of the first audit outcomes. The audit will
finish in a few months. I am still using it regardless of the recent
fiasco. I think it is ok providing old binaries are used - mine have
been on my HD since mid 2012.
Post by Shaun
Post by thang ornerythinchus
It would be a
search for a needle in a haystack. The best way in my view is to find
authors (such as you and Paul) who cannot be subverted due to your
background and sense of propriety.
With TC, we don't even know who
the authors are - they could be anyone and they certainly had the
resources and time to build and update this product. You would know
how much effort that would take.
Indeed. I also know how much someone with the necessary skills would
cost to employ... It's not just about encryption... For products
like DCPP there's 16 bit preboot code, so you include a working
knowledge of 16 bit cpu mode/BIOS, assembler, still needed even if
using "C" for most of it, (in our case it's all assembler) a knowledge
of the kernel mode, and all the vagaries that go with it, the traps
you can fall into down there, the Win32 subsystem, and how to deal
with services, to avoid the need for elevation or administrator access
(essential for corporate users) Now there's the added requirement to
deal with UEFI on top of all that. I do it all right now, and I do it
cheaply too. It's because I enjoy it. But I couldn't do this, and do a
full time job doing something else to earn a living AS WELL! ;-)
In other words, you need professionals and a lot of money. The TC
audit has both and the first outcomes are positive.


cheers

thang
Shaun Hollingworth
2014-06-02 11:56:12 UTC
Permalink
Raw Message
On Mon, 02 Jun 2014 16:11:02 +0800, thang ornerythinchus
<***@gmail.com> wrote:

[...
Post by thang ornerythinchus
Post by Shaun
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Really? I should have read this again before I responded to the
thread below (about the TC debacle).
Unfortunately hiddenOS is still currently limited to MBR
installations which are less than 2TB.

There are issues with GPT formatted disks which means a reworking of
HiddenOS isn't as simple as it might seem. However when I am free, we
are going to attempt to support it under GPT/UEFI drives.

Right now our priority is in extending existing UEFI support to our
corporate customers, and adding touch screen support. Both these are
nearly finished.
Post by thang ornerythinchus
Do you mean that for a 3Tb disc, you can set up a DCPP decoy of say
1Tb and a hidden OS of 1Tb, all in NTFS, and use of the decoy doesn't
endanger the contents of the hidden OS?
Yes as above, apart from the max size is 2TB and it still must be an
MBR formatted disk, The sizes of the disks are largely independent as
the cloning is not done with reference to the disk sizes, provided the
target volume as sufficient free space, to hold all the system files.
Post by thang ornerythinchus
If so, this would potentially render DCPP as good as TC for multi use
purposes - besides the open source aspect of course.
Can you elaborate on this Shaun? With TC, because of NTFS protocol,
the maximum decoy OS must be same size as the hidden OS while the
second partition must be 2/3rds that of the entire disk (to maximise
hidden OS size). I imagine your configuration if using NTFS would
have the same limitations.
We clone the data differently. provided the size of the hidden disk is
large enough to contain all the files,on the initial OS it will work.
You can make the second partition as large or as small as you like.
You can fill it up with as much data as you like. It really is quite
flexible. Currently there might be an issue if the disk is too large,
and this is something I need to double check.

[...]
Post by thang ornerythinchus
Post by Shaun
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
I'll take your word for that. Until Snowden stated his preferred FDE
program was TC, there was probably no spotlight on TC either. DCPP
and DC don't have anywhere near the public awareness of TC, therefore
I think I can be assured there is not only no backdoor (I accept your
assurances, I have been acquainted with you for a long time and your
background is spotless) but there is no significant TLA spotlight at
the moment.
And German is good. Just like Singapore or HK as far as I am
concerned. NSA was even spying on Merkel from what I read.
[...]
Post by thang ornerythinchus
Post by Shaun
Domestically for UK users we have RIPA which allows for the demand of
your encryption keys... Very draconian for a supposedly free country
and I made my views about it known at the time.
And do you think there is sufficient plausible deniability inherent in
a properly setup DCPP 5.0 to protect against RIPA were there to be
something of interest on the hidden OS?
I would hope so. But suspicions will remain if the software supports a
particular feature. But I guess this tips the balance in favour of the
user, without hard core proof. Even then one can just say "I tried
it"...
Post by thang ornerythinchus
Post by Shaun
Post by thang ornerythinchus
I would think not as you would probably not be working
within such a system - your ethics are good and you were the first on
the scene with free OTF full encryption (scramdisk) for Windows, I
don't think you would accept such a system.
I'd see if I could find a job programming software for sewerage works
before I would accept such a system. If I ever stop doing this, and
refuse to tell you why, but am still hanging around on here bored,
you can fear the worst. If I do tell you why, for example I say I won
the lottery, or have got another job sat at Microsoft, or have retired
to the seaside then that will tell you all is well. If ever I am got
at, and have to STOP doing this job, and I just say "I'm not doing it
any more" and refuse a reason then you can be assured of the worst.
Thank you Shaun. Thanks for the heads up re: "warrant canary".
[...]
Post by thang ornerythinchus
In other words, you need professionals and a lot of money. The TC
audit has both and the first outcomes are positive.
To be honest - A few of the comments in the audit which I have read,
surrounding the TrueCrypt boot loader and other parts bug me just a
little bit really. Are some of them over pedantic ? Are some of them
even relevant ?

Security issues - Yes fine. Point them out. No problem with that.

But do they really have to go so far as to worry what happens when a
disk size gets to be 8589934591 Tib ? The current count is about 6
isn't it for a single drive! (MS Terrabytes) Is that overflow going
to happen anytime soon ? Even then correcting a signed/unsigned error
regarding disksize value transgers they highlight will only double the
range. I won't be around to see what happens I'm sure of that! Is it a
security risk anyway ?

Or highlighting errors which might show up when the system has
BILLIONS of device objects in it ? IE Never ?

(Signed unsigned issues - If those are the worst they can find that is
a complete none issue.)


Then there's the \\device v \\Device issue. I have the same line and I
know what happens here as it is a throwback from Paul Le Roux's
orignal code. I didn't consider it to be any kind of security risk
though. In my case it will result in a simple file not found error as
\??\ gets tacked on to the front and the code tries to read a file
which isn't there.... No drive letter either, and there's no concept
of current disks down in the kernel. The user mode code always
supplies the currect data. If a hacker tried "\\device" I don't think
much would be gained for him or her!! Is this a none issue therefore ?

Just some idle observations I saw in the audit. Theory and practice I
suppose. Much of the TC code and architecture is based on the original
"Le Roux" driver so I'm very familiar with it of course and certainly
more than most would be.

BTW Visual studio 1.52 was the LAST ms compiler capable of creating 16
bit 8086 code, needed for the TC boot loader. Are the auditors aware
of that ? It's kept on MSDN for that reason alone. There maybe more
modern linux based tools, which generate 16 bit code, but I'm
concerned with the windows build. We use assembler, and an old
assembler... Would we be castigated for such an old tool too even
though the code in our case is 1-1 (source->macine) ?

Maybe some of this was enough to piss off the TrueCrypt devs.

Regards,
Shaun.
Post by thang ornerythinchus
cheers
thang
thang ornerythinchus
2014-06-06 00:31:16 UTC
Permalink
Raw Message
On Mon, 02 Jun 2014 12:56:12 +0100, Shaun Hollingworth
Post by Shaun Hollingworth
On Mon, 02 Jun 2014 16:11:02 +0800, thang ornerythinchus
[...
Post by thang ornerythinchus
Post by Shaun
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Really? I should have read this again before I responded to the
thread below (about the TC debacle).
Unfortunately hiddenOS is still currently limited to MBR
installations which are less than 2TB.
Well there is only one MBR so you mean the disk size is limited to
2TB? THat means that it really is defacto restricted to pre-GPT size
the same as TC - which is restricted to 2TB because GPT isn't
supported. I thought you said earlier somewhere that UEFI/GPT was
supported but it appears that addressing is still limited to 32bit
space.

TC places the decoy OS header on the MBR and then the encrypted
header for the hidden OS somewhere towards the end of the second
partition (64K from the end so it remains encrypted and can't be
distinguised through forensics).

Now that DCPP has two partitions, you must have two headers too. Do
you place your second header on the second partition so it stays
encrypted and therefore plausibly deniable? Or can it be
distinguished under forensic exam on the MBR etc?
Post by Shaun Hollingworth
There are issues with GPT formatted disks which means a reworking of
HiddenOS isn't as simple as it might seem. However when I am free, we
are going to attempt to support it under GPT/UEFI drives.
That would be great. You can send me a beta for testing if you like
then - I'll set it up on a 3 or 4TB disk and try it out and get back
to you with the results.
Post by Shaun Hollingworth
Right now our priority is in extending existing UEFI support to our
corporate customers, and adding touch screen support. Both these are
nearly finished.
I can't imagine any of your corporate clients wanting DCPP. Corporates
have strict internal audit requirements and so on and have no need for
hidden operating systems - they need containers - file and volume
encryption and that's all.

I would have thought that DCPP had very limited appeal at your price
point of $160USD or thereabouts. Especially as you don't make
available the source etc and your documentation is not as
comprehensive as TC's docs (which even bores down to the number of
iterations to generate the header keys). This probably justifies the
price - low volume sales, higher unit pricing to recover R&D costs
etc.

Whereas TC was free (still is), hyper-documented and high volume
downloads (in the multiple millions) and had no product
differentiation (such as with you - you differentiate between DC and
DCPP).

It seems to me that you could even discard DCPP and focus on DC - no
other software offers hidden OS functionality apart from DCPP and TC.

Have a look at this for instance:

http://www.jetico.com/welcome-truecrypt-users-migrate-to-bestcrypt

This comparison is quite dishonest. While open source and UEFI/GPT
support is great (TC by the way supports whole disc and volume
encryption of >2TB - it's only limited by the MBR to 2TB for OS
encryption), bestcrypt does not offer hidden OS functionality. Yet
they remain silent on this omission and give the impression they are
superior to TC overall.

It's low ball marketing and very undignified - I wouldn't touch
Bestcrypt now because of this.
Post by Shaun Hollingworth
Post by thang ornerythinchus
Do you mean that for a 3Tb disc, you can set up a DCPP decoy of say
1Tb and a hidden OS of 1Tb, all in NTFS, and use of the decoy doesn't
endanger the contents of the hidden OS?
Yes as above, apart from the max size is 2TB and it still must be an
MBR formatted disk, The sizes of the disks are largely independent as
the cloning is not done with reference to the disk sizes, provided the
target volume as sufficient free space, to hold all the system files.
Hopefully you will support UEFI/GPT someday - keep me on the beta
testing list please. I'll sign an NDR if you like...
Post by Shaun Hollingworth
Post by thang ornerythinchus
If so, this would potentially render DCPP as good as TC for multi use
purposes - besides the open source aspect of course.
Can you elaborate on this Shaun? With TC, because of NTFS protocol,
the maximum decoy OS must be same size as the hidden OS while the
second partition must be 2/3rds that of the entire disk (to maximise
hidden OS size). I imagine your configuration if using NTFS would
have the same limitations.
We clone the data differently. provided the size of the hidden disk is
large enough to contain all the files,on the initial OS it will work.
You can make the second partition as large or as small as you like.
You can fill it up with as much data as you like. It really is quite
flexible. Currently there might be an issue if the disk is too large,
and this is something I need to double check.
Yes, I think I recall you clone the files whereas TC clones RAW
(partition). Very different methods. Both have positives and
negatives.
Post by Shaun Hollingworth
[...]
Post by thang ornerythinchus
Post by Shaun
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
You assign your IP to them? If you develop the code in the UK, then
doesn't that mean the IP devolves to you automatically under British
copyright law? Then you would need an agreement with the Germans
whereby it is either licensed to them or ownership is transferred
outright - presumably.

I accept there are no backdoors. DCPP lacks the spotlight thrown on
TC by Snowden and Miranda's TC encrypted documention was not, and has
not yet, been decrypted.

http://leaksource.info/2013/08/30/truecrypt-protects-snowden-files-on-miranda-hard-drive-only-75-of-58000-documents-accessed-by-scotland-yard/

Therefore, no backdoor in TC or NSA/GCHQ would already know what
documents Snowden stole. And it's patently clear that they do not
know what he has...

So, with DCPP's far lower profile, sales from and perhaps ownership in
Germany, your integrity etc etc, it's highly unlikely there has been
any backdoor built into DCPP, nor has there been interest shown by
TLA's (or in the UK, the FLA).

Now all you have to do is:

1. Remove the 32bit addressing restriction and work with UEFI.
2. Ensure the headers for both partitions are equally plausibly
deniable - ie if not the case, move the second partition header to the
second partition, don't leave it in the MBR.
3. Improve your user documentation to the level of TC's docs.
4. Reduce your sale price.
5. Improve your marketing.
Post by Shaun Hollingworth
Post by thang ornerythinchus
I'll take your word for that. Until Snowden stated his preferred FDE
program was TC, there was probably no spotlight on TC either. DCPP
and DC don't have anywhere near the public awareness of TC, therefore
I think I can be assured there is not only no backdoor (I accept your
assurances, I have been acquainted with you for a long time and your
background is spotless) but there is no significant TLA spotlight at
the moment.
And German is good. Just like Singapore or HK as far as I am
concerned. NSA was even spying on Merkel from what I read.
[...]
Post by thang ornerythinchus
Post by Shaun
Domestically for UK users we have RIPA which allows for the demand of
your encryption keys... Very draconian for a supposedly free country
and I made my views about it known at the time.
In this country we have similar. However if the header for the second
partition is safely situated and encrypted on the second partition,
then plausible deniability will work here with good lawyers and
intelligent judiciary.
Post by Shaun Hollingworth
Post by thang ornerythinchus
And do you think there is sufficient plausible deniability inherent in
a properly setup DCPP 5.0 to protect against RIPA were there to be
something of interest on the hidden OS?
I would hope so. But suspicions will remain if the software supports a
particular feature. But I guess this tips the balance in favour of the
user, without hard core proof. Even then one can just say "I tried
it"...
But suspicion won't be enough to tip the balance in a court of law -
that there is reasonable suspicion that there is encryption present on
the disk. If your second headers are encrypted, situated on the
second partition and the entire second partition is encrypted, and the
RAW data on the second partition is indistinguishable from random
bits, then the only part of DCPP as installed which would point to any
encryption being present on the second partition is the part of the
cleartext application which looks for the second set of headers when
the password is entered. That will be present however whether or not
there are any headers on the second partition - it's a default aspect
of the software.

The mere presence of the second partition is cause for suspicion.
However a reasonable excuse is that there was the intention of setting
up a hidden OS, however it was too complex for limited intellect and
never went past first base - the setting up of the second partition.

Under examination, I assume with DCPP no forensic test could be
produced in court which could distinguish any of the bits on the
second partition from non-random data? Can you confirm this Shaun? It
is certainly the case with TC...

If all of the above is correct, then even under RIPA there would be no
conviction.
Post by Shaun Hollingworth
Post by thang ornerythinchus
Post by Shaun
Post by thang ornerythinchus
I would think not as you would probably not be working
within such a system - your ethics are good and you were the first on
the scene with free OTF full encryption (scramdisk) for Windows, I
don't think you would accept such a system.
I'd see if I could find a job programming software for sewerage works
before I would accept such a system. If I ever stop doing this, and
refuse to tell you why, but am still hanging around on here bored,
you can fear the worst. If I do tell you why, for example I say I won
the lottery, or have got another job sat at Microsoft, or have retired
to the seaside then that will tell you all is well. If ever I am got
at, and have to STOP doing this job, and I just say "I'm not doing it
any more" and refuse a reason then you can be assured of the worst.
Thank you Shaun. Thanks for the heads up re: "warrant canary".
[...]
Post by thang ornerythinchus
In other words, you need professionals and a lot of money. The TC
audit has both and the first outcomes are positive.
To be honest - A few of the comments in the audit which I have read,
surrounding the TrueCrypt boot loader and other parts bug me just a
little bit really. Are some of them over pedantic ? Are some of them
even relevant ?
Security issues - Yes fine. Point them out. No problem with that.
But do they really have to go so far as to worry what happens when a
disk size gets to be 8589934591 Tib ? The current count is about 6
isn't it for a single drive! (MS Terrabytes) Is that overflow going
to happen anytime soon ? Even then correcting a signed/unsigned error
regarding disksize value transgers they highlight will only double the
range. I won't be around to see what happens I'm sure of that! Is it a
security risk anyway ?
Good point. However, as an ex auditor myself (finance), I used to
tend to give extra value for clients' money. So, I would get a bit
pedantic when everything was kosher because a client always wants
results - they don't particularly want to be told that for their $50K
fee, everything was ok and nothing awry was found.

I think that's the case here...
Post by Shaun Hollingworth
Or highlighting errors which might show up when the system has
BILLIONS of device objects in it ? IE Never ?
(Signed unsigned issues - If those are the worst they can find that is
a complete none issue.)
Then there's the \\device v \\Device issue. I have the same line and I
know what happens here as it is a throwback from Paul Le Roux's
orignal code. I didn't consider it to be any kind of security risk
though. In my case it will result in a simple file not found error as
\??\ gets tacked on to the front and the code tries to read a file
which isn't there.... No drive letter either, and there's no concept
of current disks down in the kernel. The user mode code always
supplies the currect data. If a hacker tried "\\device" I don't think
much would be gained for him or her!! Is this a none issue therefore ?
For God's sake, keep these observations to yourself. We don't want
the auditors throwing in the towel now, due to loss of confidence :)

Again, they are trying to show value for money. For sure.
Post by Shaun Hollingworth
Just some idle observations I saw in the audit. Theory and practice I
suppose. Much of the TC code and architecture is based on the original
"Le Roux" driver so I'm very familiar with it of course and certainly
more than most would be.
Have you looked at the TC source code Shaun? Or can you tell just by
the performance and the way it sets itself up? I'd be interested in
any insight you have if you indeed have looked at the source.
Post by Shaun Hollingworth
BTW Visual studio 1.52 was the LAST ms compiler capable of creating 16
bit 8086 code, needed for the TC boot loader. Are the auditors aware
of that ? It's kept on MSDN for that reason alone. There maybe more
modern linux based tools, which generate 16 bit code, but I'm
concerned with the windows build. We use assembler, and an old
assembler... Would we be castigated for such an old tool too even
though the code in our case is 1-1 (source->macine) ?
Have a look at the other thread I responded to. A fellow at a uni
somewhere has compiled the source using 1.52 without complaint and
found the binaries to be ok. I've given you the link. He had no
problem with this version of VS.
Post by Shaun Hollingworth
Maybe some of this was enough to piss off the TrueCrypt devs.
I think that's likely, but the pointer to Bitlocker and the need to
have MS sign in order to exploit UEFI/GPT is equally likelier - that
is, they killed this anonymous dev driven software which was probably
the best in its field so that they could come back with perhaps a
commercial product, signed by MS, and make money.

That's what I would do. But I would never have done it for free in
any case...

cheers

thang
Shaun
2014-06-10 10:08:05 UTC
Permalink
Raw Message
On Fri, 06 Jun 2014 08:31:16 +0800, in alt.security.scramdisk you
Post by thang ornerythinchus
On Mon, 02 Jun 2014 12:56:12 +0100, Shaun Hollingworth
Post by Shaun Hollingworth
On Mon, 02 Jun 2014 16:11:02 +0800, thang ornerythinchus
[...
Post by thang ornerythinchus
Post by Shaun
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Really? I should have read this again before I responded to the
thread below (about the TC debacle).
Unfortunately hiddenOS is still currently limited to MBR
installations which are less than 2TB.
Well there is only one MBR so you mean the disk size is limited to
2TB? THat means that it really is defacto restricted to pre-GPT size
the same as TC - which is restricted to 2TB because GPT isn't
supported. I thought you said earlier somewhere that UEFI/GPT was
supported but it appears that addressing is still limited to 32bit
space.
GPT is supported in full but hiddenOS isn't at the moment. If you want
hiddenOS you have to install the OS on an MBR disk and OS. We do have
plans to add hiddenOS to UEFI soon, but it is a major job due to the
GPT layout. Right now I've had more pressing things to deal with such
as UEFI support on the corporate version of the software (which has
lots of users, and passwords for them) and touch screen support.
Post by thang ornerythinchus
TC places the decoy OS header on the MBR and then the encrypted
header for the hidden OS somewhere towards the end of the second
partition (64K from the end so it remains encrypted and can't be
distinguised through forensics).
Now that DCPP has two partitions, you must have two headers too. Do
you place your second header on the second partition so it stays
encrypted and therefore plausibly deniable? Or can it be
distinguished under forensic exam on the MBR etc?
DCPP does not use headers for any disks. As only one hidden partition
is supported by DCPP, (the OS) the data is contained in the encrypted
section of Bootauth, along with all other information. There are two
areas, one for the mainOS and one for any hiddenOS. Both are
randomized, if unused.
Post by thang ornerythinchus
Post by Shaun Hollingworth
There are issues with GPT formatted disks which means a reworking of
HiddenOS isn't as simple as it might seem. However when I am free, we
are going to attempt to support it under GPT/UEFI drives.
That would be great. You can send me a beta for testing if you like
then - I'll set it up on a 3 or 4TB disk and try it out and get back
to you with the results.
Thanks. Please feel free to email me.
Post by thang ornerythinchus
Post by Shaun Hollingworth
Right now our priority is in extending existing UEFI support to our
corporate customers, and adding touch screen support. Both these are
nearly finished.
I can't imagine any of your corporate clients wanting DCPP. Corporates
have strict internal audit requirements and so on and have no need for
hidden operating systems - they need containers - file and volume
encryption and that's all.
We have long had a lot of corporate clients. The corporate version
doesn't support hiddenOS.
Post by thang ornerythinchus
I would have thought that DCPP had very limited appeal at your price
point of $160USD or thereabouts. Especially as you don't make
available the source etc and your documentation is not as
comprehensive as TC's docs (which even bores down to the number of
iterations to generate the header keys). This probably justifies the
price - low volume sales, higher unit pricing to recover R&D costs
etc.
Well, perhaps the documentation does need an update. However I'm not
really responsible for it, but do get involved in it.
Post by thang ornerythinchus
Whereas TC was free (still is), hyper-documented and high volume
downloads (in the multiple millions) and had no product
differentiation (such as with you - you differentiate between DC and
DCPP).
DcPP and DC were (and still are) two separate programs.
Post by thang ornerythinchus
It seems to me that you could even discard DCPP and focus on DC - no
other software offers hidden OS functionality apart from DCPP and TC.
We have plans for DC which might involve what you hope for for it.
However the final decision hasn't been made. As for focusing on DC it
might surprise you to learn that DCPP is the more profitable program
for us by far.
Post by thang ornerythinchus
http://www.jetico.com/welcome-truecrypt-users-migrate-to-bestcrypt
This comparison is quite dishonest. While open source and UEFI/GPT
support is great (TC by the way supports whole disc and volume
encryption of >2TB - it's only limited by the MBR to 2TB for OS
encryption), bestcrypt does not offer hidden OS functionality. Yet
they remain silent on this omission and give the impression they are
superior to TC overall.
So did DCPP after an update. DCPP supports partitions >2gb which
aren't system partitions. Currently it doesn't support hidden volumes
on those. DC does however.
Post by thang ornerythinchus
It's low ball marketing and very undignified - I wouldn't touch
Bestcrypt now because of this.
I wouldn't be too hard on them. They are just trying to make a living.
If I was a very rich man, like I almost was when I owned a third of a
games company I would write this stuff for free, and give away the
source too. Which is how Scramdisk came about. As it happens, I need
to eat, and keep a roof over my head and subsidise my kids..
Post by thang ornerythinchus
Post by Shaun Hollingworth
Post by thang ornerythinchus
Do you mean that for a 3Tb disc, you can set up a DCPP decoy of say
1Tb and a hidden OS of 1Tb, all in NTFS, and use of the decoy doesn't
endanger the contents of the hidden OS?
Yes as above, apart from the max size is 2TB and it still must be an
MBR formatted disk, The sizes of the disks are largely independent as
the cloning is not done with reference to the disk sizes, provided the
target volume as sufficient free space, to hold all the system files.
Hopefully you will support UEFI/GPT someday - keep me on the beta
testing list please. I'll sign an NDR if you like...
Post by Shaun Hollingworth
Post by thang ornerythinchus
If so, this would potentially render DCPP as good as TC for multi use
purposes - besides the open source aspect of course.
Can you elaborate on this Shaun? With TC, because of NTFS protocol,
the maximum decoy OS must be same size as the hidden OS while the
second partition must be 2/3rds that of the entire disk (to maximise
hidden OS size). I imagine your configuration if using NTFS would
have the same limitations.
Why ?
Like truecrypt the "Decoy OS" and hiddenOS are on separate partitions.
In the case of DCpp the next partition can be any size, so long as it
is large enough to contain the OS and the decoy files, and subject to
the current restrictions of MBR. The decoy OS is effectly re-installed
on a smaller or larger disk.
Post by thang ornerythinchus
Post by Shaun Hollingworth
We clone the data differently. provided the size of the hidden disk is
large enough to contain all the files,on the initial OS it will work.
You can make the second partition as large or as small as you like.
You can fill it up with as much data as you like. It really is quite
flexible. Currently there might be an issue if the disk is too large,
and this is something I need to double check.
Yes, I think I recall you clone the files whereas TC clones RAW
(partition). Very different methods. Both have positives and
negatives.
Well, I don't see what is negative about the way we did it. We don't
impose any restrictions on the sizes, other than there's a minumum
size of wastage on NTFS which is much reduced on Windows 7
Post by thang ornerythinchus
Post by Shaun Hollingworth
[...]
Post by thang ornerythinchus
Post by Shaun
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
You assign your IP to them? If you develop the code in the UK, then
doesn't that mean the IP devolves to you automatically under British
copyright law? Then you would need an agreement with the Germans
whereby it is either licensed to them or ownership is transferred
outright - presumably.
We are in the European Union which allows for free exchange of such
things.
Post by thang ornerythinchus
I accept there are no backdoors. DCPP lacks the spotlight thrown on
TC by Snowden and Miranda's TC encrypted documention was not, and has
not yet, been decrypted.
http://leaksource.info/2013/08/30/truecrypt-protects-snowden-files-on-miranda-hard-drive-only-75-of-58000-documents-accessed-by-scotland-yard/
Hmm.. I wonder how they accessed ANY documents...They said 58 docs had
been accessed... Then they said it was 60gb of data and that 20 had
been accessed to date... 20 what ? Bytes ? Kilobytes ? Megabytes ?
Gigabytes ? 20GB with 58 docs ? How do they know it was truecrypt ?
Post by thang ornerythinchus
Therefore, no backdoor in TC or NSA/GCHQ would already know what
documents Snowden stole. And it's patently clear that they do not
know what he has...
Where did they get the 58000 UK documents from then ? It might well
have been full of hard core porn films for all they should know. Or it
could be just empty. It doesn't really make sense that they can
decrypt a few docs from a TC or similarly encrypted drive. Somehow I
think a few pork pies are being told to appease someone. However
that's only my imagination and based on no facts I know of.
Post by thang ornerythinchus
So, with DCPP's far lower profile, sales from and perhaps ownership in
Germany, your integrity etc etc, it's highly unlikely there has been
any backdoor built into DCPP, nor has there been interest shown by
TLA's (or in the UK, the FLA).
1. Remove the 32bit addressing restriction and work with UEFI.
That's easier said than done. We've supported UEFI since 2011 for
DCPP, one of the first companies to do so. UEFI is still a nightmare,
for the well designed spec is still widely broken, especially the
fully documented boot manager.
Post by thang ornerythinchus
2. Ensure the headers for both partitions are equally plausibly
deniable - ie if not the case, move the second partition header to the
second partition, don't leave it in the MBR.
The second area is always there. It isn't something added when a
hiddenOS is made on a machine. With DCPP you can even completely
destroy the first OS disk and remove bootauth, after copying all the
boot code to a USB stick and install a completly different OS on the
main partition of you want to and just boot from that. This is why
UEFI is delayed, because every aspect needs a complete re-think.
Post by thang ornerythinchus
3. Improve your user documentation to the level of TC's docs.
4. Reduce your sale price.
5. Improve your marketing.
I can deal with 1, 2 and 3 to a point, but the others... Marketing is
not my forte, or anything to do with me, and I don't decide the sale
price. Any opinion I have of those things I will keep to myself!
Anyway DCPP is easy enough to use, after one gets to understand the
keystore aspect of it.

As for 3 - If it's too good to be "true" it probably is. Software
development costs money and dedication.


I know about Truecrypt and the work which went into it. I cannot
understand how this was done for free - unless someone was supporting
it, who had good reason for it to be out there. I also don't
understand why the devs need to be anonymous, or why they kept a vice
like grip on things. They used our E4M code, and Win9x Scramdisk code,
without the common courtesy of even asking if it was OK. I've always
been very sceptical of TrueCrypt - now the devs seem to be hell bent
on destroying it. Is it a failed experiment by some party who has an
interest in getting everyone to use the same methods ?


[...]
Post by thang ornerythinchus
But suspicion won't be enough to tip the balance in a court of law -
that there is reasonable suspicion that there is encryption present on
the disk. If your second headers are encrypted, situated on the
second partition and the entire second partition is encrypted, and the
RAW data on the second partition is indistinguishable from random
bits, then the only part of DCPP as installed which would point to any
encryption being present on the second partition is the part of the
cleartext application which looks for the second set of headers when
the password is entered. That will be present however whether or not
there are any headers on the second partition - it's a default aspect
of the software.
DcPP uses exactly the same method it did when I developed the first
hidden operating system in the world on Windows XP WELL before
TrueCrypt did. Had I not done so, I do not know if they would have
have done it either. The same comments apply to encrypted headers.
These are two aspects they seem to take the credit for, but do not
deserve really. Before I did those things, as far as I know no one had
done them. Hidden disks in containers were a prior art however so I
claim no credit there. For DCPP the data for HOs is in Bootauth,
rather than on the start of the disks.

UEFI and GPT might give me an opportunity for a rethink, and for this
reason I don't want to rush into things and I'm queued up. I have a
different idea for this, which would increase plausible deniability
greatly. I need to experiment with some things, which take advantage
of particular aspects of UEFI.
Post by thang ornerythinchus
The mere presence of the second partition is cause for suspicion.
However a reasonable excuse is that there was the intention of setting
up a hidden OS, however it was too complex for limited intellect and
never went past first base - the setting up of the second partition.
Lots of computers have second partitions though, especially with
larger drives. I have loads on mine at home, and don't even have DcPP
on my machine there, having nothing worth encrypting really on that
machine. Just films, and music etc.
Post by thang ornerythinchus
Under examination, I assume with DCPP no forensic test could be
produced in court which could distinguish any of the bits on the
second partition from non-random data? Can you confirm this Shaun? It
is certainly the case with TC...
One has to encrypt the second partition first and then create the
hiddenOS on it.
Post by thang ornerythinchus
If all of the above is correct, then even under RIPA there would be no
conviction.
That's a matter for the authorities and for the courts not for me.


The purpose of Dcpp or any other of our products is not to try and
encourage people to evade the law or assist them to do so, it is to
proved them the means to protect their data against UNAUTHORISED
access. HiddenOS assists with that legal right just as decent locks
assist in preventing people breaking into your house. However we
would strongly encourage compliance with the law, but we could not
assist law enforcement in decrypting the data without user passwords,
as there's nothing else there, which could help them other than
employing standard code breaking techniques. But strictly the user
would be legally required to give up their passwords to the hiddenOS.
If they choose not to do so, that is their concern and not mine.


[...]


Regards,
Shaun.
thang ornerythinchus
2014-06-12 00:49:55 UTC
Permalink
Raw Message
On Tue, 10 Jun 2014 11:08:05 +0100, Shaun
Post by Shaun
On Fri, 06 Jun 2014 08:31:16 +0800, in alt.security.scramdisk you
Post by thang ornerythinchus
On Mon, 02 Jun 2014 12:56:12 +0100, Shaun Hollingworth
Post by Shaun Hollingworth
On Mon, 02 Jun 2014 16:11:02 +0800, thang ornerythinchus
[...
Post by thang ornerythinchus
Post by Shaun
Well, we now use a second partition, but its size can be larger, or
smaller then the main one provided the OS fits. This is because of the
way the OS is cloned.
Really? I should have read this again before I responded to the
thread below (about the TC debacle).
Unfortunately hiddenOS is still currently limited to MBR
installations which are less than 2TB.
Well there is only one MBR so you mean the disk size is limited to
2TB? THat means that it really is defacto restricted to pre-GPT size
the same as TC - which is restricted to 2TB because GPT isn't
supported. I thought you said earlier somewhere that UEFI/GPT was
supported but it appears that addressing is still limited to 32bit
space.
GPT is supported in full but hiddenOS isn't at the moment. If you want
hiddenOS you have to install the OS on an MBR disk and OS. We do have
plans to add hiddenOS to UEFI soon, but it is a major job due to the
GPT layout. Right now I've had more pressing things to deal with such
as UEFI support on the corporate version of the software (which has
lots of users, and passwords for them) and touch screen support.
Yep I've been running TC on three 3TB disks with the hidden container
option for a year or two now. Like you, they found UEFI too hard to
nonchalantly upgrade the hidden OS code.

You know, apart from mobile phones where there is no mechanical
keyboard, I find touchscreen availability almost an affectation (for
desktops and notebooks). I'm probably a dinosaur but have you
researched it? I would think upgrading hidden OS to UEFI/GPT would be
far more important - for one thing, you will be the first of the
hidden OS FDE providers to do so! What an achievment. I dare say that
was what mainly broke the back of the TC development (which doesn't
worry me because Win 7 will be around for a long long time).
Post by Shaun
Post by thang ornerythinchus
TC places the decoy OS header on the MBR and then the encrypted
header for the hidden OS somewhere towards the end of the second
partition (64K from the end so it remains encrypted and can't be
distinguised through forensics).
Now that DCPP has two partitions, you must have two headers too. Do
you place your second header on the second partition so it stays
encrypted and therefore plausibly deniable? Or can it be
distinguished under forensic exam on the MBR etc?
DCPP does not use headers for any disks. As only one hidden partition
is supported by DCPP, (the OS) the data is contained in the encrypted
section of Bootauth, along with all other information. There are two
areas, one for the mainOS and one for any hiddenOS. Both are
randomized, if unused.
Ok. Major difference and I should have remembered that. Correction
noted. I did use DCPP for about three years way back...it was one
thing actually which did appeal to me about DCPP, as I didn't like the
2 partition configuration at all when I became aware of TC - it seemed
to me it was a red flag...but then I came to your conclusion that many
disks are partitioned for various reasons and in TC's case it could be
said that the second partition was set aside but never used. It was
randomised including the headers.
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
There are issues with GPT formatted disks which means a reworking of
HiddenOS isn't as simple as it might seem. However when I am free, we
are going to attempt to support it under GPT/UEFI drives.
That would be great. You can send me a beta for testing if you like
then - I'll set it up on a 3 or 4TB disk and try it out and get back
to you with the results.
Thanks. Please feel free to email me.
I will. In the next few weeks. What's your timing - say, the next 6
months or so?
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
Right now our priority is in extending existing UEFI support to our
corporate customers, and adding touch screen support. Both these are
nearly finished.
I can't imagine any of your corporate clients wanting DCPP. Corporates
have strict internal audit requirements and so on and have no need for
hidden operating systems - they need containers - file and volume
encryption and that's all.
We have long had a lot of corporate clients. The corporate version
doesn't support hiddenOS.
That's what I meant. Or are you saying there is a version of DCPP
which doesn't support hiddenOS? I would think your clients would
prefer or require only DC - with appropriate corporate support.
Post by Shaun
Post by thang ornerythinchus
I would have thought that DCPP had very limited appeal at your price
point of $160USD or thereabouts. Especially as you don't make
available the source etc and your documentation is not as
comprehensive as TC's docs (which even bores down to the number of
iterations to generate the header keys). This probably justifies the
price - low volume sales, higher unit pricing to recover R&D costs
etc.
Well, perhaps the documentation does need an update. However I'm not
really responsible for it, but do get involved in it.
The corporate IT types would probably appreciate a more comprehensive
explanation of the mechanics of the products. Marketing can then
broadcast Securstar's "superior documentation" as an added fillip for
the conscientious IT professional (or CIO's).
Post by Shaun
Post by thang ornerythinchus
Whereas TC was free (still is), hyper-documented and high volume
downloads (in the multiple millions) and had no product
differentiation (such as with you - you differentiate between DC and
DCPP).
DcPP and DC were (and still are) two separate programs.
Yes. I was discussing the difference in product availability and
therefore documentation. I was once intimately familiar with both DC
and DCPP having used both for several years. I was not happy that TC
used two partitions - it seemed to me that plausible deniability was
compromised, unlike the DCPP scheme.
Post by Shaun
Post by thang ornerythinchus
It seems to me that you could even discard DCPP and focus on DC - no
other software offers hidden OS functionality apart from DCPP and TC.
We have plans for DC which might involve what you hope for for it.
However the final decision hasn't been made. As for focusing on DC it
might surprise you to learn that DCPP is the more profitable program
for us by far.
Did you mean "we have plans for DCPP"? And, yes, that does surprise
me. My reason for using a hidden OS is simply to prevent leakage of
multiple passwords for multiple purposes (banking, patents, client
information and a multititude of other purposes) into the numerous
niches and crannies which MS has created with its Frankenstein's
monster (eg page file, user accounts, program files, registry hive,
hiberfil, etc etc). I would think that corporates would not be as
careful, especially in context of auditability and central control of
access, and would therefore not need hidden OS availability. I would
have thought that on a "sales volume" basis DC>DCPP.
Post by Shaun
Post by thang ornerythinchus
http://www.jetico.com/welcome-truecrypt-users-migrate-to-bestcrypt
This comparison is quite dishonest. While open source and UEFI/GPT
support is great (TC by the way supports whole disc and volume
encryption of >2TB - it's only limited by the MBR to 2TB for OS
encryption), bestcrypt does not offer hidden OS functionality. Yet
they remain silent on this omission and give the impression they are
superior to TC overall.
So did DCPP after an update. DCPP supports partitions >2gb which
aren't system partitions. Currently it doesn't support hidden volumes
on those. DC does however.
I get it. DCPP is mainly sold as a OTF-FDE solution for your OS-boot
drive. Hidden OS functionality is an extra flavour.
Post by Shaun
Post by thang ornerythinchus
It's low ball marketing and very undignified - I wouldn't touch
Bestcrypt now because of this.
I wouldn't be too hard on them. They are just trying to make a living.
If I was a very rich man, like I almost was when I owned a third of a
games company I would write this stuff for free, and give away the
source too. Which is how Scramdisk came about. As it happens, I need
to eat, and keep a roof over my head and subsidise my kids..
I understand that - I have been a marketeer all of my professional
life. I'm semi retired and still have a short list of clients for
whom I market regularly.

However, as this was a specific comparison with TC *and* superiority
of BC over TC on a function by function basis was being trumpeted, to
leave one vital component out because they couldn't match it was just
...dishonest. It should have been left in and explained away on the
basis that, for instance, there is very limited need for a hidden OS
when OTF FDE of the first active partition (C drive) is available.

That's what I have done for clients and myself for the last 30 years -
because I believe that dishonesty in the corporate world is grubby and
low, and because there are intelligent types in that part of society
who *will* pick up on such dishonesty.

They painted themselves into that corner and then were dishonest in
their comparison.
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
Post by thang ornerythinchus
Do you mean that for a 3Tb disc, you can set up a DCPP decoy of say
1Tb and a hidden OS of 1Tb, all in NTFS, and use of the decoy doesn't
endanger the contents of the hidden OS?
Yes as above, apart from the max size is 2TB and it still must be an
MBR formatted disk, The sizes of the disks are largely independent as
the cloning is not done with reference to the disk sizes, provided the
target volume as sufficient free space, to hold all the system files.
I understand now Shaun that you offer UEFI/GPT support for DCPP but
not for DCPP in its incarnation with hidden OS functionality.
Therefore, max addressing space for hidden OS is restricted to 32bit.
Post by Shaun
Post by thang ornerythinchus
Hopefully you will support UEFI/GPT someday - keep me on the beta
testing list please. I'll sign an NDR if you like...
Yes, as agreed by you above - for DCPP if your plans are approved at
executive level for hidden OS functionality for UEFI/GPT.
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
Post by thang ornerythinchus
If so, this would potentially render DCPP as good as TC for multi use
purposes - besides the open source aspect of course.
Better. As of yet, TC and its forks (see Veracrypt) don't offer
UEFI/GPT functionality for hidden OS.

Although, Veracrypt probably has that in mind:

https://veracrypt.codeplex.com/workitem/list/basic

"GPT System Partitions cannot be encrypted because the bootloader does
not support GPT Partition Table"

and:

https://veracrypt.codeplex.com/discussions/547604#post1253164

"GPT partitions and UEFI are not supported yet. This is planned but it
is complex to implement. Work on it started but we can't give any
release date yet. As of today, no open source implementation of UEFI
boot encryption for Windows exists and we hope to be the first to
release such implementation." This was written in June 2014.

I don't know if you were aware of Veracrypt Shaun. They have already
upgraded TC source PBKDF2-RIPEMD160 from 1000 iterations to 327661 and
for standard containers and other partitions from 2000 iterations to
655331 for RIPEMD160 and 500000 iterations for SHA-2 and Whirlpool.

It seems they (he, actually) is working on this problem (UEFI/GPT)
right at the moment. He lives in France - that's a good thing. Out
of reach of the yanks and there is little love lost between the French
and the US - or you Brits.

His implementation is open source - if he does this, and this being a
fork of TC, and TC being audited at the moment and that audit being
fully funded through to completion, then it would be almost trivial to
compare the source code for his code exceptions (his method of
UEFI/GPT boot encryption) and then prove absence of backdoors etc. It
will all be open source.

Interesting, no?
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
Post by thang ornerythinchus
Can you elaborate on this Shaun? With TC, because of NTFS protocol,
the maximum decoy OS must be same size as the hidden OS while the
second partition must be 2/3rds that of the entire disk (to maximise
hidden OS size). I imagine your configuration if using NTFS would
have the same limitations.
Why ?
Like truecrypt the "Decoy OS" and hiddenOS are on separate partitions.
In the case of DCpp the next partition can be any size, so long as it
is large enough to contain the OS and the decoy files, and subject to
the current restrictions of MBR. The decoy OS is effectly re-installed
on a smaller or larger disk.
Yes, agreed. The decoy in your case is not a working OS. In TC's
case, it is and can be shown to be so for excellent plausible
deniability. In DCPP's case, if RIPA forces one to cough up the pass
for the decoy OS, there will be no time stamps etc on that decoy to
prove that it was in use and therefore it seems to me plausible
deniability will be that much more difficult to demonstrate.
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
We clone the data differently. provided the size of the hidden disk is
large enough to contain all the files,on the initial OS it will work.
You can make the second partition as large or as small as you like.
You can fill it up with as much data as you like. It really is quite
flexible. Currently there might be an issue if the disk is too large,
and this is something I need to double check.
Yes, I think I recall you clone the files whereas TC clones RAW
(partition). Very different methods. Both have positives and
negatives.
Well, I don't see what is negative about the way we did it. We don't
impose any restrictions on the sizes, other than there's a minumum
size of wastage on NTFS which is much reduced on Windows 7
Nothing negative at all. However, if you have for instance data which
your British authorities consider to be in the national interest (say
patents or IP regarding something which they want to confiscate and
quarantine for "national" use therefore denying the inventor or holder
of the IP the opportunity to commercialise internationally) can you
demonstrate how giving up the password for the decoy OS is going to
convince them of the absence of the hidden OS? Given that your
drawings, schematics, patents, IP etc all reside on the hidden OS? For
one thing, the decoy will not have been in use - correct? Therefore,
no current timestamps, no pagefile, no hiberfile, no roaming, temp,
and so on - unused. So, they ask, how come there are timestamps on
the other drives in the machine which demonstrate recent use (because
DCPP doesn't read-only other drives and partitions) - and what have
you been using if you haven't been using this OS?

It all becomes rather elaborate - oh, I have another desktop or laptop
which I have been using. Well, why have *this* machine set up with an
encrypted OS and a suspicious second partition, and data on the MBR
which shows there is a DCPP installation - and then use another
machine for your day to day stuff?

Whereas, with TC, there is a fully operational decoy/sacrificial
OS...and nothing but a second partition which is full of random data,
including the headers for that partition.
Post by Shaun
Post by thang ornerythinchus
Post by Shaun Hollingworth
[...]
Post by thang ornerythinchus
Post by Shaun
There are no backdoors in DCPP. Which by the way is developed in the
UK because I am British and live in England. It's owned and sold by
the German company though and we don't sell it from my workplace.
You assign your IP to them? If you develop the code in the UK, then
doesn't that mean the IP devolves to you automatically under British
copyright law? Then you would need an agreement with the Germans
whereby it is either licensed to them or ownership is transferred
outright - presumably.
We are in the European Union which allows for free exchange of such
things.
But not the exclusion of IP protection. Surely IP is protected there
for the creator/author? And above the level of code, the systems
themselves are protected by patents? Which means such "property" can
only be transferred for use by another party by way of formal contract
- an agreement. Unless you are an employee - in which case everything
you create (code and systems) vests automatically in your employer.

I doubt that "free exchange" means that an external consultant for
instance would work just so his inventions can be "freely exchanged".
Post by Shaun
Post by thang ornerythinchus
I accept there are no backdoors. DCPP lacks the spotlight thrown on
TC by Snowden and Miranda's TC encrypted documention was not, and has
not yet, been decrypted.
http://leaksource.info/2013/08/30/truecrypt-protects-snowden-files-on-miranda-hard-drive-only-75-of-58000-documents-accessed-by-scotland-yard/
Hmm.. I wonder how they accessed ANY documents...They said 58 docs had
been accessed... Then they said it was 60gb of data and that 20 had
been accessed to date... 20 what ? Bytes ? Kilobytes ? Megabytes ?
Gigabytes ? 20GB with 58 docs ? How do they know it was truecrypt ?
Perhaps you haven't read my other comment in the other thread about
the stuff which was posted on Pastebin a few years ago by the anon
hackers. They took down a full machine in the US which had
inter-agency emails involving a senior IT investigator in a State IB -
and his counterparts in the FBI. THE FBI has invented an internal
program called ZSearch specifically targeting TC and other FDE
programs - looking for PWs in the page file, memory, and so on. Fully
documented - I can post if you like, it was freely available for a
while. TC OS's and containers/files came up often and they could not
crack it directly outside of brute force or looking for leakage.

As to the Miranda issue, here is actually what happened with TC per
Oliver Robbins, your Deputy National Security Adviser for Intelligence
and Security, in the High Court of Justice in MIRANDA vs SECRETARY OF
STATE FOR THE HOME DEPARTMENT:

"13. I am advised that the data recovered from the claimant is
almost certain to contain some of the material passed by Mr Snowden to
Ms Poitras and Mr Greenwald. Much of the material is encrypted .
However, among the unencrypted documents recovered from the claimant
was a piece of paper containing basic instructions for accessing some
data, together with a piece of paper that included the password for
decrypting one of the encrypted files on the external hard drive
recovered from the claimant. I have been briefed that the authorities
have therefore been able to examine the data contained in this file.
They have been able to determine that the external hard drive contains
approximately 58,000 highly classified UK intelligence documents. Work
continues to access the content of the other files on the hard drive
and the USB sticks."

These are facts stated in defence of Miranda's application to the High
Court seeking restoration of his laptop. They were and still are
stuck on TrueCrypt - according to Greenwald, in a later statement,
said "...they only got access to 75 of the documents that he was
carrying, most of which are probably ones related to his school work
and personal use."

This situation hasn't changed - neither the external drive nor the
internal drive have been decrypted. Note also that Miranda did not
have a hidden OS setup - just containers with thousands of files in
them. Detective Superintendent Goode said that the information on the
external hard drive was encrypted by a system called “True Crypt,”
which she said “renders the material extremely difficult to access.”
Goode said the process to decode the material was complex and that “so
far only 75 documents have been reconstructed since the property was
initially received.”

With TC, there is no complex process. The file or container is
mounted (one click) and then a password is entered - and everything in
that container or file is available in plaintext. Why use the word
"reconstructed"? Well, with TC containers, files or even partitions
there is leakage of the PW of course to the page file and retention of
documents in plaintext etc not only in the swap but in unallocated
space and file tails. This is what she means by "reconstructed".

They still haven't accessed Miranda's encrypted containers - if they
had, he would have been charged, and he hasn't. They have picked up
some stuff from normal forensics of his unallocated space etc - the
leakage in the unencrypted OS.

If Miranda had used full disc encryption, not necessarily even the
hidden OS, then they would not have "reconstructed" even one file.


Don't tl;dr the above Shaun, I would like your comments please.
Otherwise, it's just a handy means of organising my own thoughts...
Post by Shaun
Post by thang ornerythinchus
Therefore, no backdoor in TC or NSA/GCHQ would already know what
documents Snowden stole. And it's patently clear that they do not
know what he has...
Where did they get the 58000 UK documents from then ? It might well
have been full of hard core porn films for all they should know. Or it
could be just empty. It doesn't really make sense that they can
decrypt a few docs from a TC or similarly encrypted drive. Somehow I
think a few pork pies are being told to appease someone. However
that's only my imagination and based on no facts I know of.
Nah, they knew Miranda was Greenwald's partner, of course. And they
knew Greenwald was the source of the revelations of part of Snowden's
haul. They knew with a fair degree of certainty what was in the
encrypted container.
Post by Shaun
Post by thang ornerythinchus
So, with DCPP's far lower profile, sales from and perhaps ownership in
Germany, your integrity etc etc, it's highly unlikely there has been
any backdoor built into DCPP, nor has there been interest shown by
TLA's (or in the UK, the FLA).
1. Remove the 32bit addressing restriction and work with UEFI.
That's easier said than done. We've supported UEFI since 2011 for
DCPP, one of the first companies to do so. UEFI is still a nightmare,
for the well designed spec is still widely broken, especially the
fully documented boot manager.
You have competition in France. See my comments on VeraCrypt above.
He is working towards supporting it for hidden OS purposes and open
source.

What do you mean "UEFI is still a nightmare for the well designed spec
is still widely broken"?
Post by Shaun
Post by thang ornerythinchus
2. Ensure the headers for both partitions are equally plausibly
deniable - ie if not the case, move the second partition header to the
second partition, don't leave it in the MBR.
The second area is always there. It isn't something added when a
hiddenOS is made on a machine. With DCPP you can even completely
destroy the first OS disk and remove bootauth, after copying all the
boot code to a USB stick and install a completly different OS on the
main partition of you want to and just boot from that. This is why
UEFI is delayed, because every aspect needs a complete re-think.
Yes, excuse my ignorance explained above on the basis of long
abstinence from the way you have designed things. Apologies. If you
are rethinking the entire UEFI/GPT/HiddenOS scenario, you should
ensure firstmost and foremost that the decoy is (a) fully usable and
therefore a plausible decoy and (b) have the option to write protect
everything but the hidden OS when the hidden OS is booted (this will
oneup TC because that factor is not optional - it's mandatory).
Post by Shaun
Post by thang ornerythinchus
3. Improve your user documentation to the level of TC's docs.
4. Reduce your sale price.
5. Improve your marketing.
I can deal with 1, 2 and 3 to a point, but the others... Marketing is
not my forte, or anything to do with me, and I don't decide the sale
price. Any opinion I have of those things I will keep to myself!
Anyway DCPP is easy enough to use, after one gets to understand the
keystore aspect of it.
For you it's easy enough to use, and for me...but not for the teeming
masses. The documentation needs to be twofold - simple for the
simpletons and complex for the professionals or dilettantes.

Marketing is essential - email me when you have determined which, if
any, course you are going to set for the UEFI/GPT compatible DCPP with
HiddenOS and I will give you at the least bullet points you can use on
your glossy material (website and emailable .pdfs). It's what I do
for a crust and my clients come in varieties up to transnational with
multi-billion toplines.
Post by Shaun
As for 3 - If it's too good to be "true" it probably is. Software
development costs money and dedication.
The money is often opportunity cost - the revenue you would have
generated elsewhere if not for the development you are engaged in. I
have a friend who is developing code for a provisioning system for use
by insurance companies in the motor vehicle sector - he has been paid
around $40K for it so far and has done about that amount again of
development for zero revenue - on the basis that if it takes off, then
he will be paid retrospectively and generate some revenue from
licensing etc.

There is always a motivation. Sometimes it's idealism (think: TC
devs) but that can fade over time. Sometimes it's just to prove a
point, but usually it's to generate income whether now or in the
future. Some people have the capacity to think strategically rather
than tactically - their timescales are in years not in months.
Post by Shaun
I know about Truecrypt and the work which went into it. I cannot
understand how this was done for free - unless someone was supporting
it, who had good reason for it to be out there. I also don't
understand why the devs need to be anonymous, or why they kept a vice
like grip on things. They used our E4M code, and Win9x Scramdisk code,
without the common courtesy of even asking if it was OK. I've always
been very sceptical of TrueCrypt - now the devs seem to be hell bent
on destroying it. Is it a failed experiment by some party who has an
interest in getting everyone to use the same methods ?
Idealism. Youthful. No longer so young or so idealistic. Can you
understand how you developed Scramdisk over 10 years ago when you were
young and idealistic? Before you had mouths to feed and were full of
the bullshit that society force feeds you on?

Anonymity is a good thing sometimes. I don't do FB, Twitter, Google+
or any of the other stuff which destroys privacy (anonymity). I have
always been that way. I don't do photographs. I don't reveal casual
personal data on the net or for that matter anywhere else. I never
have nor will I. I don't do linkedIn, or any of that stuff either.
I'm a "word of mouth man" and it's placed me in a great suburb in a
million dollar house (no mortgage) and all the trappings - if I want
those trappings which I don't. Because I don't do jealousy and envy
either.

More to the point, and illustrating my point about youthful idealism
and creativity, didn't you write Scramdisk with Paul back in 1999 and
with the following license?

"License Details

1.You accept that the creator of this software cannot be responsible
for *any* loss of data however caused (including by any incorrect
operation of this software program despite 'best efforts') and you
agree to back up any files you consider important before you use this
software on your system.


2.You agree that the creator of this program is anonymous, but wishes
to retain copyright and commercial rights to this software.


3.You agree not to redistribute this software in any form other than
that in which it was received by you, and will include all files
exactly as present when it was so received, if you do distribute it.


4.You agree in the event of loss, or forgetting of passwords used by
this software, no technical support can be given to assist in recovery
such passwords, and that you forgetting any passwords, EQUATES to loss
of your data when that data is stored on any disk partitions, or disk
drive images created, and opened by the execution of this software.
You accept no back doors exist, to gain access to scrambled data.


5.You agree that some of the ciphers used are the intellectual
property of others, and may need a licence for commercial use, such as
use on a business system.You acknowledge this is especially true in
the case of the IDEA algorithm and will read the documents regarding
the Ascom conditions of use of IDEA which can be found in the document
file 'scramdisk.doc' included in this software package.


6.You agree that if you obtain the publicly available source code, and
amend it you will submit the amended program and new source code to
the originators for publication, and understand that these amendments
shall not violate compatibility with older versions of the software or
reduce security levels in any way."

You and Paul wanted to be anonymous (see 2 above). Scramdisk at that
stage was free, freely distributable to non-commercial interests and
open source. Just like Truecrypt which came along later but never
turned commercial (Scramdisk -> Drivecrypt).

I still have your "sdfullsource202h.zip" on file Shaun. Source and
binaries, both PGP signed.

That's my point. They just never went commercial - but who's to say
going commercial *now* isn't part of their strategy, and killing off
TC a necessary preliminary to that?
Post by Shaun
[...]
Post by thang ornerythinchus
But suspicion won't be enough to tip the balance in a court of law -
that there is reasonable suspicion that there is encryption present on
the disk. If your second headers are encrypted, situated on the
second partition and the entire second partition is encrypted, and the
RAW data on the second partition is indistinguishable from random
bits, then the only part of DCPP as installed which would point to any
encryption being present on the second partition is the part of the
cleartext application which looks for the second set of headers when
the password is entered. That will be present however whether or not
there are any headers on the second partition - it's a default aspect
of the software.
DcPP uses exactly the same method it did when I developed the first
hidden operating system in the world on Windows XP WELL before
TrueCrypt did. Had I not done so, I do not know if they would have
have done it either. The same comments apply to encrypted headers.
These are two aspects they seem to take the credit for, but do not
deserve really. Before I did those things, as far as I know no one had
done them. Hidden disks in containers were a prior art however so I
claim no credit there. For DCPP the data for HOs is in Bootauth,
rather than on the start of the disks.
UEFI and GPT might give me an opportunity for a rethink, and for this
reason I don't want to rush into things and I'm queued up. I have a
different idea for this, which would increase plausible deniability
greatly. I need to experiment with some things, which take advantage
of particular aspects of UEFI.
Talk to me Shaun. I will endorse a NDA with you. My input can be
valuable, especially seeking your target market and then marketing to
that target population.

It will mean me converting to non-anonymous, so it will need to be
good :)

"...which would increase plausible deniability greatly." That's the
kicker.
Post by Shaun
Post by thang ornerythinchus
The mere presence of the second partition is cause for suspicion.
However a reasonable excuse is that there was the intention of setting
up a hidden OS, however it was too complex for limited intellect and
never went past first base - the setting up of the second partition.
Lots of computers have second partitions though, especially with
larger drives. I have loads on mine at home, and don't even have DcPP
on my machine there, having nothing worth encrypting really on that
machine. Just films, and music etc.
Yes, but those second partitions aren't accompanied by a DCPP header
on the MBR/GPT (or a TC header on the MBR). When you have both, you
have a suspicion in respect of the secondary partition, especially in
DCPP's case where the decoy has no usage, no recent timestamps, no
used pagefile, no evidence of regular use.
Post by Shaun
Post by thang ornerythinchus
Under examination, I assume with DCPP no forensic test could be
produced in court which could distinguish any of the bits on the
second partition from non-random data? Can you confirm this Shaun? It
is certainly the case with TC...
One has to encrypt the second partition first and then create the
hiddenOS on it.
You've already answered this - it's "randomized" to use your term
above.
Post by Shaun
Post by thang ornerythinchus
If all of the above is correct, then even under RIPA there would be no
conviction.
That's a matter for the authorities and for the courts not for me.
I'm talking RIPA Shaun, not some other conviction. RIPA means that if
they have evidence which is "reasonable" then the court can order a PW
be provided for decryption. If the PW is not provided, then a
conviction is recorded under RIPA for non-compliance. That's a matter
which can be determined by the encryption user based on whether the
degree of "plausible deniability" is sufficient for the "reasonable"
test to be *not* satisfied.

Eg: with TC hidden OS, the decoy is fully used with up to date time
stamps, functional swap file, plenty of evidence in the nonallocated
space and file tails of full usage, bloated registry hive and so on.
The second partition and its headers are fully encrypted and
randomized as you say - indistinguishable forensically from an
unformatted disk.

With DCPP, there is no evidence of usage of the decoy, there are no
current time stamps, no files in unallocated space, no file tails in
unused parts of clusters etc. Hard to show plausible deniability to a
reaonable degree especially in the face of a determined state player.

Hence, RIPA, give up a PW or face conviction...
Post by Shaun
The purpose of Dcpp or any other of our products is not to try and
encourage people to evade the law or assist them to do so, it is to
proved them the means to protect their data against UNAUTHORISED
access. HiddenOS assists with that legal right just as decent locks
assist in preventing people breaking into your house. However we
would strongly encourage compliance with the law, but we could not
assist law enforcement in decrypting the data without user passwords,
as there's nothing else there, which could help them other than
employing standard code breaking techniques. But strictly the user
would be legally required to give up their passwords to the hiddenOS.
If they choose not to do so, that is their concern and not mine.
What Shaun, not even RIPA? It's a law and a bad one at that along
with its equivalents in many other countries (but not the USA which
has an excellent constitution). Interesting to hear you say this when
your website talks about plausible deniability - which is surely an
"evasion" of the need to cough up a PW by allowing you to "evade"
detection of your hidden OS (even though it wouldn't stay hidden for
too long after the decoy OS is booted and shown to be a sham OS).

By not assisting in enforcement of RIPA you are, in essence, evading
RIPA. That's nothing to be ashamed of, but TC does it better by
allowing the decoy to be more than a decoy - I am using it right now
to type this on my NNTP client.

Some interesting stuff above. Get back to me please on the various
issues, I enjoy our discussions and I believe they are both useful to
me in my "hobby" and useful to you commercially, if you give it more
than a passing thought.

cheers

thang
Shaun
2014-06-12 16:52:43 UTC
Permalink
Raw Message
[...]

Hi thang,

Got to run as I've got to visit my mum in hospital.
Post by thang ornerythinchus
By not assisting in enforcement of RIPA you are, in essence, evading
RIPA. That's nothing to be ashamed of, but TC does it better by
allowing the decoy to be more than a decoy - I am using it right now
to type this on my NNTP client.
I just wanted to answer your last point - I really don't understand
what you mean that the decoy (none hidden) OS cannot be used ? It can
be used as much as you want.

That the "decoy OS" use was dangerous was certainly the case with the
old version of HiddenOS for FAT32 Windows XP only, because it hid the
os in the spare space of the SAME decoy XP OS disk so use was
automatically a bit risky. It is not the case now. now the hidden os
is installed in the spare space of an adjacent data partition so OF
COURSE the main OS can be used as much as you like. This has been the
case since windows 7 and vista support was added. Be sure the second
drive is encrypted with a different key so you can't accidentally
overwrite the hidden stuff, by copying extra data to the decoy drive.

Must dash - Will address some of the other comments tomorrow.

Regards,
Shaun.
thang ornerythinchus
2014-06-12 21:24:30 UTC
Permalink
Raw Message
On Thu, 12 Jun 2014 17:52:43 +0100, Shaun
Post by Shaun Hollingworth
[...]
Hi thang,
Got to run as I've got to visit my mum in hospital.
Post by thang ornerythinchus
By not assisting in enforcement of RIPA you are, in essence, evading
RIPA. That's nothing to be ashamed of, but TC does it better by
allowing the decoy to be more than a decoy - I am using it right now
to type this on my NNTP client.
I just wanted to answer your last point - I really don't understand
what you mean that the decoy (none hidden) OS cannot be used ? It can
be used as much as you want.
That the "decoy OS" use was dangerous was certainly the case with the
old version of HiddenOS for FAT32 Windows XP only, because it hid the
os in the spare space of the SAME decoy XP OS disk so use was
automatically a bit risky. It is not the case now. now the hidden os
is installed in the spare space of an adjacent data partition so OF
COURSE the main OS can be used as much as you like. This has been the
case since windows 7 and vista support was added. Be sure the second
drive is encrypted with a different key so you can't accidentally
overwrite the hidden stuff, by copying extra data to the decoy drive.
Must dash - Will address some of the other comments tomorrow.
Regards,
Shaun.
Hey I hope your mum is ok Shaun. Best wishes on that and I mean it.

When I used DCPP if memory serves me right, the one big limitation was
that the decoy OS could not be used as you say. I never used DCPP
after Win7 so again my understanding of DCPP is tainted by how it was
orginally configured. Apologies on that - do you have a link for the
complete documentation for DCPP v5.0? On your website as far as I can
tell you only have the annotated or bullet point type version which
does not have much detail. Alternatively, can you paste a link
somewhere or email it to me? I clearly need to read it.

So you're not restricted to FAT32 anymore either? And you mention the
hidden OS is stored in the "spare space" of an adjacent data partition
(D) - what do you mean by that? Is there plaintext on that drive as
well? With TC the entire D partition is encrypted and the hidden OS
is back in the last third of the physical drive space (due to NTFS
file journalling beginning at the middle or somesuch apparently - this
is why the *entire* D partition can't be used for the hidden TC OS).

Obviously need documentation. Go away. Read it. Come back more
informed :)

thang
Shaun
2014-06-13 15:10:12 UTC
Permalink
Raw Message
On Fri, 13 Jun 2014 05:24:30 +0800, thang ornerythinchus
<***@gmail.com> wrote:

[...]


Sorry I've still not got time to discuss things in your other mail but
Post by thang ornerythinchus
On Thu, 12 Jun 2014 17:52:43 +0100, Shaun
Post by Shaun Hollingworth
[...]
Hi thang,
Got to run as I've got to visit my mum in hospital.
Post by thang ornerythinchus
By not assisting in enforcement of RIPA you are, in essence, evading
RIPA. That's nothing to be ashamed of, but TC does it better by
allowing the decoy to be more than a decoy - I am using it right now
to type this on my NNTP client.
I just wanted to answer your last point - I really don't understand
what you mean that the decoy (none hidden) OS cannot be used ? It can
be used as much as you want.
That the "decoy OS" use was dangerous was certainly the case with the
old version of HiddenOS for FAT32 Windows XP only, because it hid the
os in the spare space of the SAME decoy XP OS disk so use was
automatically a bit risky. It is not the case now. now the hidden os
is installed in the spare space of an adjacent data partition so OF
COURSE the main OS can be used as much as you like. This has been the
case since windows 7 and vista support was added. Be sure the second
drive is encrypted with a different key so you can't accidentally
overwrite the hidden stuff, by copying extra data to the decoy drive.
Must dash - Will address some of the other comments tomorrow.
Regards,
Shaun.
Hey I hope your mum is ok Shaun. Best wishes on that and I mean it.
Hi Thang,

Thanks for the good wishes. Mum's ok. Suspected heart attack as she
already had two bypass ops in the past. But it was some kind of water
infection they said. She's coming home tomorrow.
Post by thang ornerythinchus
When I used DCPP if memory serves me right, the one big limitation was
that the decoy OS could not be used as you say. I never used DCPP
after Win7 so again my understanding of DCPP is tainted by how it was
orginally configured.
Ah well, when you are the first in the world at doing something,
someone can always improve on it... Including me and some anonymous
geeks who might have been working for the NSA for all I know.
Post by thang ornerythinchus
Apologies on that -
Not necessary.
Post by thang ornerythinchus
do you have a link for the
complete documentation for DCPP v5.0? On your website as far as I can
tell you only have the annotated or bullet point type version which
does not have much detail. Alternatively, can you paste a link
somewhere or email it to me? I clearly need to read it.
I will double check what's in the latest DCPP help file. I did update
that myself, but can't remember exactly what I wrote.
Thang, can you please send me your email address to:

s/h/a/u/n/(at)/s/e/c/u/r/s/t/a/r/(dot)/c/o/m

If it's the one your I could "reply to" your post via email, please
confirn. I get rejects if I try to contact you on it.
Post by thang ornerythinchus
So you're not restricted to FAT32 anymore either?
Nope. Not since Vista and Win7 support was added some time ago.
Post by thang ornerythinchus
And you mention the
hidden OS is stored in the "spare space" of an adjacent data partition
(D) - what do you mean by that? Is there plaintext on that drive as
well?
No it requires encryption before the hiddenOS is allowed to be created
on it. However you could use the skip option, but you are warned that
certain unused areas of the disk would not be encrypted in that case.
Skip was a much sought after feature, requested by customers with
larger drives. There's also "scrub" where the free space is randomised
but it doesn't save as much time, by any means.

Skip is not advised if you intend to create a hiddenOS on the
partition. The main purpose of the skip function is the encryption of
new hard drives, with the OS installed on it.

When the hiddenOS is created, due to the way the cloning works, it is
not encrypted when you boot it, so you have to then encrypt it again.

BTW all existing keys can be transported to hiddenOS. DCPP creates a
ramdisk of about 2mbytes (configurable) in none pagable Kernel ram,
using facilities provided by DCPP's device driver, and the keystore
for the hiddenOS is created there rather than on an existing disk
drive. Existing keys from our keystore are copied into it, and then
the disk cloner copies the keystore on the ramdrive to the new
hiddenOS drive ready for use later. So the new hiddenOS key data never
touches the harddisk apart from the HOS area. On login to DCPP running
under hiddenOS you are directed to this new keystore as the default
filename presented to DCPP.

Before you create the hiddenOS you are required to configure a Ramdisk
on the screen where you start the hiddenOS creation. The
transportation of existing keys allows hiddenOS to access the data on
the main operating system disk if you wish.
Post by thang ornerythinchus
With TC the entire D partition is encrypted and the hidden OS
is back 4in the last third of the physical drive space (due to NTFS
file journalling beginning at the middle or somesuch apparently - this
is why the *entire* D partition can't be used for the hidden TC OS).
Indeed. However it's not wise anyway having an empty partition if the
partition contains a hiddenOS. However Windows 7 NTFS is quite
different, on a 30gb drive, the loss is only about 3GB a loss of about
10%

On a test done today on Windows 7:

"D" drive (which can be any letter of course, so long as the partition
is adjacent to the right to the OS on Disk manager) has 30.4gb (no
decoy files) and the HiddenOS in it is 27.4. A HiddenOS on XP NTFS
would have lost significantly more than this. I'm not sure if TC
caught on to this different or not, but with our cloning scheme it
happens automatically when the drive partition's free space is
measured.
Post by thang ornerythinchus
Obviously need documentation. Go away. Read it. Come back more
informed :)
thang
Regards,
Shaun.
thang ornerythinchus
2014-06-17 22:50:55 UTC
Permalink
Raw Message
On Fri, 13 Jun 2014 16:10:12 +0100, Shaun
Post by Shaun
On Fri, 13 Jun 2014 05:24:30 +0800, thang ornerythinchus
[...]
Sorry I've still not got time to discuss things in your other mail but
Hey no problem Shaun. Respond when you can and if you can.
Post by Shaun
Post by thang ornerythinchus
On Thu, 12 Jun 2014 17:52:43 +0100, Shaun
Post by Shaun Hollingworth
[...]
Hi thang,
Got to run as I've got to visit my mum in hospital.
Post by thang ornerythinchus
By not assisting in enforcement of RIPA you are, in essence, evading
RIPA. That's nothing to be ashamed of, but TC does it better by
allowing the decoy to be more than a decoy - I am using it right now
to type this on my NNTP client.
I just wanted to answer your last point - I really don't understand
what you mean that the decoy (none hidden) OS cannot be used ? It can
be used as much as you want.
That the "decoy OS" use was dangerous was certainly the case with the
old version of HiddenOS for FAT32 Windows XP only, because it hid the
os in the spare space of the SAME decoy XP OS disk so use was
automatically a bit risky. It is not the case now. now the hidden os
is installed in the spare space of an adjacent data partition so OF
COURSE the main OS can be used as much as you like. This has been the
case since windows 7 and vista support was added. Be sure the second
drive is encrypted with a different key so you can't accidentally
overwrite the hidden stuff, by copying extra data to the decoy drive.
Must dash - Will address some of the other comments tomorrow.
Regards,
Shaun.
Hey I hope your mum is ok Shaun. Best wishes on that and I mean it.
Hi Thang,
Thanks for the good wishes. Mum's ok. Suspected heart attack as she
already had two bypass ops in the past. But it was some kind of water
infection they said. She's coming home tomorrow.
Good I hope that all went well for her. The wonders of modern
medicine are nothing to be sneered at.
Post by Shaun
Post by thang ornerythinchus
When I used DCPP if memory serves me right, the one big limitation was
that the decoy OS could not be used as you say. I never used DCPP
after Win7 so again my understanding of DCPP is tainted by how it was
orginally configured.
Ah well, when you are the first in the world at doing something,
someone can always improve on it... Including me and some anonymous
geeks who might have been working for the NSA for all I know.
Nah. Read my post regarding GCHQ's efforts to decrypt T/C. They
couldn't and nor could they decrypt the container on Miranda's machine
- nor have they yet. I pulled the High Court transcript and posted
part of it for you to read - you should draw your conclusions from
evidence such as that, I always have been an "Occam's razor" thinker
and in this case the simplest solution is almost certainly the correct
solution - the developers threw in the towel.

This is more likely in my mind because of something you say below.
Read on.
Post by Shaun
Post by thang ornerythinchus
Apologies on that -
Not necessary.
Post by thang ornerythinchus
do you have a link for the
complete documentation for DCPP v5.0? On your website as far as I can
tell you only have the annotated or bullet point type version which
does not have much detail. Alternatively, can you paste a link
somewhere or email it to me? I clearly need to read it.
I will double check what's in the latest DCPP help file. I did update
that myself, but can't remember exactly what I wrote.
Ok.
Post by Shaun
s/h/a/u/n/(at)/s/e/c/u/r/s/t/a/r/(dot)/c/o/m
If it's the one your I could "reply to" your post via email, please
confirn. I get rejects if I try to contact you on it.
No, I will email you from another server. I use a German server for
most of my email needs. The address you had is dead thanks to the NSA
- it was Lavabit, if you still have it. Snowden used it, and I used
it because of its stability and security, even for my business needs -
then, it was closed down due to a NSA letter. All of this coincidence
of course.

My business is sensitive and confidential and I don't trust my ISP not
to read my plaintext emails. You will get my email soon.
Post by Shaun
Post by thang ornerythinchus
So you're not restricted to FAT32 anymore either?
Nope. Not since Vista and Win7 support was added some time ago.
Good.
Post by Shaun
Post by thang ornerythinchus
And you mention the
hidden OS is stored in the "spare space" of an adjacent data partition
(D) - what do you mean by that? Is there plaintext on that drive as
well?
No it requires encryption before the hiddenOS is allowed to be created
on it. However you could use the skip option, but you are warned that
certain unused areas of the disk would not be encrypted in that case.
Skip was a much sought after feature, requested by customers with
larger drives. There's also "scrub" where the free space is randomised
but it doesn't save as much time, by any means.
Skip is not advised if you intend to create a hiddenOS on the
partition. The main purpose of the skip function is the encryption of
new hard drives, with the OS installed on it.
When the hiddenOS is created, due to the way the cloning works, it is
not encrypted when you boot it, so you have to then encrypt it again.
BTW all existing keys can be transported to hiddenOS. DCPP creates a
ramdisk of about 2mbytes (configurable) in none pagable Kernel ram,
using facilities provided by DCPP's device driver, and the keystore
for the hiddenOS is created there rather than on an existing disk
drive. Existing keys from our keystore are copied into it, and then
the disk cloner copies the keystore on the ramdrive to the new
hiddenOS drive ready for use later. So the new hiddenOS key data never
touches the harddisk apart from the HOS area. On login to DCPP running
under hiddenOS you are directed to this new keystore as the default
filename presented to DCPP.
Before you create the hiddenOS you are required to configure a Ramdisk
on the screen where you start the hiddenOS creation. The
transportation of existing keys allows hiddenOS to access the data on
the main operating system disk if you wish.
This seems very secure - in TC's case, the keys can't be found unless
the machine is on and a memory dump/capture possible - the two 256bit
keys which combine into the master 512bit key can then be found. There
are plenty of tools to do this - aeskeyfind for instance, but it can
only be done if the machine is on and RAM can be captured. In your
case, there is more security against cold boot intrusion but it's
still academic if the machine is off.
Post by Shaun
Post by thang ornerythinchus
With TC the entire D partition is encrypted and the hidden OS
is back 4in the last third of the physical drive space (due to NTFS
file journalling beginning at the middle or somesuch apparently - this
is why the *entire* D partition can't be used for the hidden TC OS).
Indeed. However it's not wise anyway having an empty partition if the
partition contains a hiddenOS. However Windows 7 NTFS is quite
different, on a 30gb drive, the loss is only about 3GB a loss of about
10%
Ok. I think the reason for TC's hidden OS geometry was the position
of the MFT - centre of partition under NTFS in order to reduce head
movement and increase the life of HD's.

TrueCrypt documentation states: "However, if the outer volume (not to
be confused with the system partition) is formatted as NTFS, the
partition for the hidden operating system must be at least 110% (2.1
times) larger than the system partition (the reason is that the NTFS
file system always stores internal data exactly in the middle of the
volume and, therefore, the hidden volume, which is to contain a clone
of the system partition, can reside only in the second half of the
partition)."

They are talking about the MFT here but you are saying that Windows 7
NTFS is quite different - in what way? Apparently the only way to
move the MFT from the centre is to use third party utilities such as
partition wizard to shrink the partition and then expand it again at
boot (so the OS is not in use and the MFT can be moved). Have you
therefore built this type of code (partition management) into DCPP? If
not, how do you deal with the problem which apparently the TC
developers couldn't deal with?


thang
Post by Shaun
"D" drive (which can be any letter of course, so long as the partition
is adjacent to the right to the OS on Disk manager) has 30.4gb (no
decoy files) and the HiddenOS in it is 27.4. A HiddenOS on XP NTFS
would have lost significantly more than this. I'm not sure if TC
caught on to this different or not, but with our cloning scheme it
happens automatically when the drive partition's free space is
measured.
Post by thang ornerythinchus
Obviously need documentation. Go away. Read it. Come back more
informed :)
thang
Regards,
Shaun.
Shaun
2014-06-19 09:41:40 UTC
Permalink
Raw Message
On Wed, 18 Jun 2014 06:50:55 +0800, thang ornerythinchus

[...]

[A quickie]
Post by thang ornerythinchus
They are talking about the MFT here but you are saying that Windows 7
NTFS is quite different - in what way? Apparently the only way to
move the MFT from the centre is to use third party utilities such as
partition wizard to shrink the partition and then expand it again at
boot (so the OS is not in use and the MFT can be moved). Have you
therefore built this type of code (partition management) into DCPP? If
not, how do you deal with the problem which apparently the TC
developers couldn't deal with?
Windows 7 NTFS disks (and Vista/W7 system disks are required to be
NTFS) are different from the start. I think the MFT starts earlier in
the disk when it is formatted by Windows 7. I think TC would also have
more room on Windows 7, if they parse the disk properly to see where
the first usable sector lies.

Regards,
Shaun.
Post by thang ornerythinchus
thang
Post by Shaun
"D" drive (which can be any letter of course, so long as the partition
is adjacent to the right to the OS on Disk manager) has 30.4gb (no
decoy files) and the HiddenOS in it is 27.4. A HiddenOS on XP NTFS
would have lost significantly more than this. I'm not sure if TC
caught on to this different or not, but with our cloning scheme it
happens automatically when the drive partition's free space is
measured.
Post by thang ornerythinchus
Obviously need documentation. Go away. Read it. Come back more
informed :)
thang
Regards,
Shaun.
Loading...