Shaun you still up and about?

Discussion:

(too old to reply)

thang ornerythinchus

2013-12-21 05:57:52 UTC

Here's an interesting story.

http://www.reuters.com/article/2013/12/20/us-usa-security-rsa-idUSBRE9BJ1C220131220

Looks as though NSA did a deal with RSA division. How naughty.

How about you guys? You're incorporated in Deutschland, so I wouldn't
think there could be any pressure placed on your products, but have
you ever had a polite level of interest shown by anyone in the smart
community?

Don't guess you can say. Intriguing though isn't it?

cheers mate, would be nice to hear from you again :)

thang

Shaun H

2014-01-24 15:34:01 UTC

Permalink

On Sat, 21 Dec 2013 13:57:52 +0800, thang ornerythinchus

Post by thang ornerythinchus
Here's an interesting story.
http://www.reuters.com/article/2013/12/20/us-usa-security-rsa-idUSBRE9BJ1C220131220
Looks as though NSA did a deal with RSA division. How naughty.
How about you guys? You're incorporated in Deutschland, so I wouldn't
think there could be any pressure placed on your products, but have
you ever had a polite level of interest shown by anyone in the smart
community?
Don't guess you can say. Intriguing though isn't it?
cheers mate, would be nice to hear from you again :)
thang

Hi,

Yes I'm still here, but very rarely read this group now. Yes I've read
the article or at least a similar one regarding Snowdens relevations.

Yes I can say, and I say it honestly. Read on Sir. :-)

We don't use RSA for much, apart from software licensing so it isn't
really an issue. Even then we don't use the standard PRNG...

A program we use called Sharecrypt5 uses RSA, (with a different PRNG)
for admin->user control, to update user's key files, from
administrators but not for general encryption of the actual data.

We've never had any "official" interest in our products, or pressure
from governments save from occasional law enforcement requests for
help. We are always very honest with them here, and simply say there's
no back doors or anything, however much we sympathize with their needs
this is not, and never has been any kind of legal requirement, nor is
it likely to be in the future.

I think use of data encryption is so mainstream nowadays, it isn't
really such a big issue that there aren't back doors in products.
Hospitals, doctors, schools, law-enforcement, finance, etc. all use
these kind of products, many use ours, and they would be horrified to
discover a back way in. Indeed such a thing might even be illegal to
use for certain purposes in Europe at least, because the data wouldn't
be regarded as "properly" (in the legal sense) secure.

In order for it to be so, it would really have to be encrypted in a
way that we ourselves could not gain access, at least within any sort
of remotely practical time. The only people who are supposed to be
able to gain easy access are the owners of the data. Nobody else. If
they could, even via a hidden back door, then the product simply
isn't fit for purpose. Such a thing would evenutally be leaked I'm
sure of that.

Such product use is now legally required for storage of personal data
especially where machines are portable, and taken out into the field.

In the UK, the relevant laws are the Data Protection Act, and
Financial Services Authority regulations.

Regards,
Shaun.

thang ornerythinchus

2014-02-02 05:32:24 UTC

Permalink

Post by Shaun H
On Sat, 21 Dec 2013 13:57:52 +0800, thang ornerythinchus

Hi,
Yes I'm still here, but very rarely read this group now. Yes I've read
the article or at least a similar one regarding Snowdens relevations.
Yes I can say, and I say it honestly. Read on Sir. :-)
We don't use RSA for much, apart from software licensing so it isn't
really an issue. Even then we don't use the standard PRNG...
A program we use called Sharecrypt5 uses RSA, (with a different PRNG)
for admin->user control, to update user's key files, from
administrators but not for general encryption of the actual data.
We've never had any "official" interest in our products, or pressure
from governments save from occasional law enforcement requests for
help. We are always very honest with them here, and simply say there's
no back doors or anything, however much we sympathize with their needs
this is not, and never has been any kind of legal requirement, nor is
it likely to be in the future.
I think use of data encryption is so mainstream nowadays, it isn't
really such a big issue that there aren't back doors in products.
Hospitals, doctors, schools, law-enforcement, finance, etc. all use
these kind of products, many use ours, and they would be horrified to
discover a back way in. Indeed such a thing might even be illegal to
use for certain purposes in Europe at least, because the data wouldn't
be regarded as "properly" (in the legal sense) secure.
In order for it to be so, it would really have to be encrypted in a
way that we ourselves could not gain access, at least within any sort
of remotely practical time. The only people who are supposed to be
able to gain easy access are the owners of the data. Nobody else. If
they could, even via a hidden back door, then the product simply
isn't fit for purpose. Such a thing would evenutally be leaked I'm
sure of that.
Such product use is now legally required for storage of personal data
especially where machines are portable, and taken out into the field.
In the UK, the relevant laws are the Data Protection Act, and
Financial Services Authority regulations.
Regards,
Shaun.

Shaun

Nice to hear from you. I hope you are well and prospering in 2014 -
at the very least, as one of the pioneering cryptographers (up there
with Schneier and co, at the very least), you deserve to.

I like the inverted commas around "official" - as a euphemism, I think
we all (the few who still scan this group) know what it means esp. in
post-Snowden times.

To the point:

Your commentary relates predominantly to what I call "easy
encryption". That is, standard container encryption with a key.
Practically anyone with an IQ over 70 can create a container and
encrypt it -most such encryption will, until the advent of quantum
computing proper, remain unbreakable (within reasonable computing
time).

The other end of the spectrum, to which I was referring, is the
complex, plausible-deniability driven hidden OS type encryption. These
technologies, of which two stand out (DCPP and TC), are both driven by
AES256, are reasonably complex to implement properly and safely and
are those which aggravate the snooping authorities to the greatest
degree because there is not only little if any difference at raw level
between unformatted platters and hidden OS partition if the key to the
sacrificial OS is provided, but there is no leakage from the hidden OS
(and in the case of TC, rendering of all other drives "read only" -
I'm not certain what the analagous case is with DCPP). An encrypted
container sticks out like a sore thumb and is what is used typically
by say 95% of those in medicine, law, accounting, public services and
so on - the knowledge it is there is often good enough for the snoops.
The law takes over in many countries and there is a jail sentence for
failure to disclose the key(s).

There is no such equivalent knowledge available to the snoops in
respect of DCPP and TC. Those partitions are ascertainable, but the
contents are indistinguishable from a raw partition. At medium
sophistication, they do not know whether the sacrificed OS keys
represent the only encrypted component of the drive, or whether the
partitioning is a clue that there is another OS. Not enough to invoke
the law regarding disclosure of keys if there is no reasonable
evidence that there is indeed some encrypted component of the drive to
which such keys would relate. Only clearly evident containers have
been taken to court under the disclosure laws.

So, in my view the primary target of official approaches to encryption
organisations would be to somehow either backdoor FDE with hidden OS
(at the preboot stage) or somehow allow for identification that there
exists a hidden OS in the free space of the sacrificial. Both
approaches would be protected by law in the US - that is, there would
be an embargo on disclosure by the private organisation (so much for
the constitution).

The devs of TC protect themselves by being completely anonymous. No
one knows who the heck they are and probably never will. An approach
cannot be made to a shadow, which he/they are.

In your case, Securestar is incorporated in Deutschland, which has
much stronger digital privacy laws than the US and as far as I know,
no mandatory key disclosure laws. The totalitarian history of Germany
also means that there is a much stronger will to protect private data
- lest the drift back to Hitlerian ways of thought begin. In my view,
it is the best country in which to incorporate and operate an
encryption developement business. I therefore have no doubt that (a)
probably there has been no NSA level attempt at coercing a backdoor or
tag into your preboot authentication protocol; (b) if there has, it
would have been easily repulsed as the non-disclosure laws relating to
such contacts/requests/requirements do not obtain in Germany; and (c)
you personally have a reputation for integrity of the highest order
and, as the primary asset in Securestar, that integrity is
unimpeachable.

In my view however there is a problem with plausible deniability in
DCPP pre-authentication which doesn't appear to trouble TC - that is
(from memory - I haven't used DCPP now for at least 5 or 6 years or
more) that it was then at least discernable from the PB routine that
there were two pathways - one to the sacrificial OS and the other to
the hidden. This may have been fixed but from memory was present when
I last used DCPP and would be open to forensic proof that there was,
on balance, an encrypted system in the encrypted system. This can't
be ascertained in TC forensics.

As both systems are used in countries which do have mandatory key
disclosure laws, with jail sanctions, this is/was an important
difference.

You mentioned in your reply that "such a thing would be leaked". Well
no, Shaun, not when the full weight of the NSA or its equivalent in
most countries (GCHQ, ASIO etc) is brought to bear and the leaker
would probably disappear into a black hole for a very long time. The
"hidden devs"which many rail about have an excellent defence - they
are unknowable and their identitied have never been leaked. Are they
NSA? Who knows - if they are, then only national security would force
the backdoor open (not trivial FBI local enforcement issues) and the
entire tableau would be closed off, sealed and dropped into permanent
obscurity - Director's eyes only stuff. They probably aren't and
that's why I use TC - and I don't deal in national security matters,
I'm relatively happy with the status quo so for my purposes, TC is
suitable (business matters, patents, marketing, invoicing, etc).

All of this is a little more than academic for me after Snowden (lol,
in lieu of BC, AD etc - AS - "after Snowden") as I am a libertarian of
the highest order. Snowden set back the Orwellian march by decades.

By the way, it seems that in these times NNTP traffic is probably the
last reasonably secure means of communication on the planet. Pick an
NSP whose servers can sit out of the US, and is incorporated in
another country (astraweb comes to mind - EU servers and inc in HK)
and NNTP is fairly much ok. At least for these types of issues which
we are discussing.

kind regards

thang

thang ornerythinchus

2014-03-02 02:06:32 UTC

Permalink

On Sun, 02 Feb 2014 13:32:24 +0800, thang ornerythinchus

Post by thang ornerythinchus

Post by Shaun H
On Sat, 21 Dec 2013 13:57:52 +0800, thang ornerythinchus

Hi,
Yes I'm still here, but very rarely read this group now. Yes I've read
the article or at least a similar one regarding Snowdens relevations.
Yes I can say, and I say it honestly. Read on Sir. :-)
We don't use RSA for much, apart from software licensing so it isn't
really an issue. Even then we don't use the standard PRNG...
A program we use called Sharecrypt5 uses RSA, (with a different PRNG)
for admin->user control, to update user's key files, from
administrators but not for general encryption of the actual data.
We've never had any "official" interest in our products, or pressure
from governments save from occasional law enforcement requests for
help. We are always very honest with them here, and simply say there's
no back doors or anything, however much we sympathize with their needs
this is not, and never has been any kind of legal requirement, nor is
it likely to be in the future.
I think use of data encryption is so mainstream nowadays, it isn't
really such a big issue that there aren't back doors in products.
Hospitals, doctors, schools, law-enforcement, finance, etc. all use
these kind of products, many use ours, and they would be horrified to
discover a back way in. Indeed such a thing might even be illegal to
use for certain purposes in Europe at least, because the data wouldn't
be regarded as "properly" (in the legal sense) secure.
In order for it to be so, it would really have to be encrypted in a
way that we ourselves could not gain access, at least within any sort
of remotely practical time. The only people who are supposed to be
able to gain easy access are the owners of the data. Nobody else. If
they could, even via a hidden back door, then the product simply
isn't fit for purpose. Such a thing would evenutally be leaked I'm
sure of that.
Such product use is now legally required for storage of personal data
especially where machines are portable, and taken out into the field.
In the UK, the relevant laws are the Data Protection Act, and
Financial Services Authority regulations.
Regards,
Shaun.

Shaun
Nice to hear from you. I hope you are well and prospering in 2014 -
at the very least, as one of the pioneering cryptographers (up there
with Schneier and co, at the very least), you deserve to.
I like the inverted commas around "official" - as a euphemism, I think
we all (the few who still scan this group) know what it means esp. in
post-Snowden times.
Your commentary relates predominantly to what I call "easy
encryption". That is, standard container encryption with a key.
Practically anyone with an IQ over 70 can create a container and
encrypt it -most such encryption will, until the advent of quantum
computing proper, remain unbreakable (within reasonable computing
time).
The other end of the spectrum, to which I was referring, is the
complex, plausible-deniability driven hidden OS type encryption. These
technologies, of which two stand out (DCPP and TC), are both driven by
AES256, are reasonably complex to implement properly and safely and
are those which aggravate the snooping authorities to the greatest
degree because there is not only little if any difference at raw level
between unformatted platters and hidden OS partition if the key to the
sacrificial OS is provided, but there is no leakage from the hidden OS
(and in the case of TC, rendering of all other drives "read only" -
I'm not certain what the analagous case is with DCPP). An encrypted
container sticks out like a sore thumb and is what is used typically
by say 95% of those in medicine, law, accounting, public services and
so on - the knowledge it is there is often good enough for the snoops.
The law takes over in many countries and there is a jail sentence for
failure to disclose the key(s).
There is no such equivalent knowledge available to the snoops in
respect of DCPP and TC. Those partitions are ascertainable, but the
contents are indistinguishable from a raw partition. At medium
sophistication, they do not know whether the sacrificed OS keys
represent the only encrypted component of the drive, or whether the
partitioning is a clue that there is another OS. Not enough to invoke
the law regarding disclosure of keys if there is no reasonable
evidence that there is indeed some encrypted component of the drive to
which such keys would relate. Only clearly evident containers have
been taken to court under the disclosure laws.
So, in my view the primary target of official approaches to encryption
organisations would be to somehow either backdoor FDE with hidden OS
(at the preboot stage) or somehow allow for identification that there
exists a hidden OS in the free space of the sacrificial. Both
approaches would be protected by law in the US - that is, there would
be an embargo on disclosure by the private organisation (so much for
the constitution).
The devs of TC protect themselves by being completely anonymous. No
one knows who the heck they are and probably never will. An approach
cannot be made to a shadow, which he/they are.
In your case, Securestar is incorporated in Deutschland, which has
much stronger digital privacy laws than the US and as far as I know,
no mandatory key disclosure laws. The totalitarian history of Germany
also means that there is a much stronger will to protect private data
- lest the drift back to Hitlerian ways of thought begin. In my view,
it is the best country in which to incorporate and operate an
encryption developement business. I therefore have no doubt that (a)
probably there has been no NSA level attempt at coercing a backdoor or
tag into your preboot authentication protocol; (b) if there has, it
would have been easily repulsed as the non-disclosure laws relating to
such contacts/requests/requirements do not obtain in Germany; and (c)
you personally have a reputation for integrity of the highest order
and, as the primary asset in Securestar, that integrity is
unimpeachable.
In my view however there is a problem with plausible deniability in
DCPP pre-authentication which doesn't appear to trouble TC - that is
(from memory - I haven't used DCPP now for at least 5 or 6 years or
more) that it was then at least discernable from the PB routine that
there were two pathways - one to the sacrificial OS and the other to
the hidden. This may have been fixed but from memory was present when
I last used DCPP and would be open to forensic proof that there was,
on balance, an encrypted system in the encrypted system. This can't
be ascertained in TC forensics.
As both systems are used in countries which do have mandatory key
disclosure laws, with jail sanctions, this is/was an important
difference.
You mentioned in your reply that "such a thing would be leaked". Well
no, Shaun, not when the full weight of the NSA or its equivalent in
most countries (GCHQ, ASIO etc) is brought to bear and the leaker
would probably disappear into a black hole for a very long time. The
"hidden devs"which many rail about have an excellent defence - they
are unknowable and their identitied have never been leaked. Are they
NSA? Who knows - if they are, then only national security would force
the backdoor open (not trivial FBI local enforcement issues) and the
entire tableau would be closed off, sealed and dropped into permanent
obscurity - Director's eyes only stuff. They probably aren't and
that's why I use TC - and I don't deal in national security matters,
I'm relatively happy with the status quo so for my purposes, TC is
suitable (business matters, patents, marketing, invoicing, etc).
All of this is a little more than academic for me after Snowden (lol,
in lieu of BC, AD etc - AS - "after Snowden") as I am a libertarian of
the highest order. Snowden set back the Orwellian march by decades.
By the way, it seems that in these times NNTP traffic is probably the
last reasonably secure means of communication on the planet. Pick an
NSP whose servers can sit out of the US, and is incorporated in
another country (astraweb comes to mind - EU servers and inc in HK)
and NNTP is fairly much ok. At least for these types of issues which
we are discussing.
kind regards
thang

C'mon Shaun, smith, trying to keep this group alive as usual...

thang

Shaun

2014-04-03 14:22:32 UTC

Permalink

Hi - Sorry I've not replied sooner but some interesting if perhaps
occasionally erroneous points have been made.

Firstly I'll say this AGAIN - I personally have never been hassled by
the NSA or GCHQ or anyone at all. We've been asked for help by various
authorities from time to time, but when I told them we can't there's
never been any kind of issue to speak of.

I'm not sure about your comments about "HiddenOS" but newer versions
use a separate data partition for the OS clone. This also allows the
main OS partition to be "Seen" as a data folder by HiddenOS by some
heavy juggling about and spoofing of the partition maps. The software
actually lies to the OS about where everything is! HiddenOS isn't
supported on GPT OS, on UEFI bios based booting. It will be eventually
but it's low down the list, because if you want a hiddenos it is still
easy to setup your os as MBR boot. After making a boot device you can
install something different completely if you want and boot up from
the boot device.

When creating HiddenOS to prevent key material lingering somewere on
the main drive, a new key and keystore is created for the hidden
volume. The DCPP device driver has a RAMDISK function working with
none pageable ram which becomes enabled for this and this is where the
keystore and keys are placed during store creation. Never on the main
drive or data drive. During the cloning of the OS the keystore is
copied onto the hiddenOS drive, and then the ramdisk destroyed.

TrueCrypt - Why do the authors of that software have to keep
themselves secret ? This is something which has always puzzled me. I
used to call myself "Aman" at first but then realised there wasn't
anything major to worry about. Sometimes I do wonder what their
motives are, or if they were being bankrolled by someone in authority
who thought it would be much better if most people were using the same
software to encrypt their data... Which meant giving it to them... In
the old days they seemed to release stuff almost by magic; it was as
if they had inside knowledge of certain aspects of the OS, and they
stayed completely up to speed. Now they are begging for money, and
haven't released a new version for over two years... Though UEFI and
the like is supposedly in the works for the software. Has the
bankrolling stopped ? Have the programmers finally got married and
realise (as I did when I lost my games company) that you actually need
to earn some money to provide for your kids ? I was rather hoping to
win the Euromillions so I could open up the source code...

My lonely efforts in recent times, have not been so focused on
advancing security (which it will be again soon) but trying to keep up
to speed with the ever changing Windows platform. In particular since
MS mandated the use of the UEFI BIOS for Windows 8 machines something
which in my opinion is the worst piece of committee inspired
technology I've ever come across. The theory is good. The specs are
tight for sure, and reasonably unambiguous. The trouble is that almost
every manufacturer seems to have *ignored* that wretched spec, one way
or another. For example - The BOOTxxxx and BOOTORDER variables can be
manipulated to make a certain program the startup program, under OS
software running at high priviledge on the computer. One manufacturer
ignores this. Well, no - It gets set up. Then the bios scribbles its
OWN private backup over the changes on the next boot. Another
hardwires the windows boot loader name. Yet another ignores a protocol
to determine the state of the ALT/CTRL/SHIFT keys needed for full
language keyboard translation. How on earth can some UEFI client
application needing to be consistent be written with such a cavalier
attitude as this.

At least we did manage to get DCPP UEFI support out quite early so
that the OS of such machines could be fully encrypted. Late 2011 in
fact. Certainly before Windows 8 came out. I did ALL the coding for
that.

Current versions have UEFI Secure Boot support, the UEFI binaries
having been countersigned by MS after their checks that there's no
known malware in there. One famous manufacter even forgot to put the
MS keys in the wretched BIOS. They are NOT the same keys as required
to boot Windows, which MS will use ONLY for their OWN products.

How time flies. It's some 17 years since the original version of
Scramdisk hit the streets.

Regards,
Shaun.

Post by thang ornerythinchus
On Sun, 02 Feb 2014 13:32:24 +0800, thang ornerythinchus

Post by thang ornerythinchus

Post by Shaun H
On Sat, 21 Dec 2013 13:57:52 +0800, thang ornerythinchus

Hi,
Yes I'm still here, but very rarely read this group now. Yes I've read
the article or at least a similar one regarding Snowdens relevations.
Yes I can say, and I say it honestly. Read on Sir. :-)
We don't use RSA for much, apart from software licensing so it isn't
really an issue. Even then we don't use the standard PRNG...
A program we use called Sharecrypt5 uses RSA, (with a different PRNG)
for admin->user control, to update user's key files, from
administrators but not for general encryption of the actual data.
We've never had any "official" interest in our products, or pressure
from governments save from occasional law enforcement requests for
help. We are always very honest with them here, and simply say there's
no back doors or anything, however much we sympathize with their needs
this is not, and never has been any kind of legal requirement, nor is
it likely to be in the future.
I think use of data encryption is so mainstream nowadays, it isn't
really such a big issue that there aren't back doors in products.
Hospitals, doctors, schools, law-enforcement, finance, etc. all use
these kind of products, many use ours, and they would be horrified to
discover a back way in. Indeed such a thing might even be illegal to
use for certain purposes in Europe at least, because the data wouldn't
be regarded as "properly" (in the legal sense) secure.
In order for it to be so, it would really have to be encrypted in a
way that we ourselves could not gain access, at least within any sort
of remotely practical time. The only people who are supposed to be
able to gain easy access are the owners of the data. Nobody else. If
they could, even via a hidden back door, then the product simply
isn't fit for purpose. Such a thing would evenutally be leaked I'm
sure of that.
Such product use is now legally required for storage of personal data
especially where machines are portable, and taken out into the field.
In the UK, the relevant laws are the Data Protection Act, and
Financial Services Authority regulations.
Regards,
Shaun.

Shaun
Nice to hear from you. I hope you are well and prospering in 2014 -
at the very least, as one of the pioneering cryptographers (up there
with Schneier and co, at the very least), you deserve to.
I like the inverted commas around "official" - as a euphemism, I think
we all (the few who still scan this group) know what it means esp. in
post-Snowden times.
Your commentary relates predominantly to what I call "easy
encryption". That is, standard container encryption with a key.
Practically anyone with an IQ over 70 can create a container and
encrypt it -most such encryption will, until the advent of quantum
computing proper, remain unbreakable (within reasonable computing
time).
The other end of the spectrum, to which I was referring, is the
complex, plausible-deniability driven hidden OS type encryption. These
technologies, of which two stand out (DCPP and TC), are both driven by
AES256, are reasonably complex to implement properly and safely and
are those which aggravate the snooping authorities to the greatest
degree because there is not only little if any difference at raw level
between unformatted platters and hidden OS partition if the key to the
sacrificial OS is provided, but there is no leakage from the hidden OS
(and in the case of TC, rendering of all other drives "read only" -
I'm not certain what the analagous case is with DCPP). An encrypted
container sticks out like a sore thumb and is what is used typically
by say 95% of those in medicine, law, accounting, public services and
so on - the knowledge it is there is often good enough for the snoops.
The law takes over in many countries and there is a jail sentence for
failure to disclose the key(s).
There is no such equivalent knowledge available to the snoops in
respect of DCPP and TC. Those partitions are ascertainable, but the
contents are indistinguishable from a raw partition. At medium
sophistication, they do not know whether the sacrificed OS keys
represent the only encrypted component of the drive, or whether the
partitioning is a clue that there is another OS. Not enough to invoke
the law regarding disclosure of keys if there is no reasonable
evidence that there is indeed some encrypted component of the drive to
which such keys would relate. Only clearly evident containers have
been taken to court under the disclosure laws.
So, in my view the primary target of official approaches to encryption
organisations would be to somehow either backdoor FDE with hidden OS
(at the preboot stage) or somehow allow for identification that there
exists a hidden OS in the free space of the sacrificial. Both
approaches would be protected by law in the US - that is, there would
be an embargo on disclosure by the private organisation (so much for
the constitution).
The devs of TC protect themselves by being completely anonymous. No
one knows who the heck they are and probably never will. An approach
cannot be made to a shadow, which he/they are.
In your case, Securestar is incorporated in Deutschland, which has
much stronger digital privacy laws than the US and as far as I know,
no mandatory key disclosure laws. The totalitarian history of Germany
also means that there is a much stronger will to protect private data
- lest the drift back to Hitlerian ways of thought begin. In my view,
it is the best country in which to incorporate and operate an
encryption developement business. I therefore have no doubt that (a)
probably there has been no NSA level attempt at coercing a backdoor or
tag into your preboot authentication protocol; (b) if there has, it
would have been easily repulsed as the non-disclosure laws relating to
such contacts/requests/requirements do not obtain in Germany; and (c)
you personally have a reputation for integrity of the highest order
and, as the primary asset in Securestar, that integrity is
unimpeachable.
In my view however there is a problem with plausible deniability in
DCPP pre-authentication which doesn't appear to trouble TC - that is
(from memory - I haven't used DCPP now for at least 5 or 6 years or
more) that it was then at least discernable from the PB routine that
there were two pathways - one to the sacrificial OS and the other to
the hidden. This may have been fixed but from memory was present when
I last used DCPP and would be open to forensic proof that there was,
on balance, an encrypted system in the encrypted system. This can't
be ascertained in TC forensics.
As both systems are used in countries which do have mandatory key
disclosure laws, with jail sanctions, this is/was an important
difference.
You mentioned in your reply that "such a thing would be leaked". Well
no, Shaun, not when the full weight of the NSA or its equivalent in
most countries (GCHQ, ASIO etc) is brought to bear and the leaker
would probably disappear into a black hole for a very long time. The
"hidden devs"which many rail about have an excellent defence - they
are unknowable and their identitied have never been leaked. Are they
NSA? Who knows - if they are, then only national security would force
the backdoor open (not trivial FBI local enforcement issues) and the
entire tableau would be closed off, sealed and dropped into permanent
obscurity - Director's eyes only stuff. They probably aren't and
that's why I use TC - and I don't deal in national security matters,
I'm relatively happy with the status quo so for my purposes, TC is
suitable (business matters, patents, marketing, invoicing, etc).
All of this is a little more than academic for me after Snowden (lol,
in lieu of BC, AD etc - AS - "after Snowden") as I am a libertarian of
the highest order. Snowden set back the Orwellian march by decades.
By the way, it seems that in these times NNTP traffic is probably the
last reasonably secure means of communication on the planet. Pick an
NSP whose servers can sit out of the US, and is incorporated in
another country (astraweb comes to mind - EU servers and inc in HK)
and NNTP is fairly much ok. At least for these types of issues which
we are discussing.
kind regards
thang

C'mon Shaun, smith, trying to keep this group alive as usual...
thang

Shaun

2014-04-03 14:52:31 UTC

Permalink

Post by Shaun
Hi - Sorry I've not replied sooner but some interesting if perhaps
occasionally erroneous points have been made.

PS: Sorry about the top posting last post - I so seldom get on Usenet
nowadays I forget....

Regards,
Shaun.

SafeBoot Simon

2014-05-29 21:28:20 UTC

Permalink

So Shaun (long time, no speak btw!) - are you still hanging around here bored? Still working on encryption software?

Shaun Hollingworth

2014-05-30 09:45:44 UTC

Permalink

On Thu, 29 May 2014 14:28:20 -0700 (PDT), SafeBoot Simon

Post by SafeBoot Simon
So Shaun (long time, no speak btw!) - are you still hanging around here bored? Still working on encryption software?

Hello Simon - How are you - Yes long time no speak. :-)

Yes I'm still here, and still working on the stuff.

I don't come here all that much. I've come today to see if there's any
comments on the TrueCrypt issue.

Currently I am extremely mystified by that TrueCrypt saga, and what
the hell is going on with them. I long suspected there was more to
this than meets the eye somehow. One thing I don't understand is them
pointing everyone to bitlocker. Bitlocker might be ok, but it will
naturally be untrusted because it is MS provided and owned.

What are you up to nowadays ? Are you still working with the SafeBoot
or Endpoint as I think it is now called ?

Currently working on some new UEFI preboot code for DCPP adding touch
screen and corporate versoion support. DCPP has had UEFI support since
2011 including getting it signed by you know who for use with Secure
Boot. A process we have to go through again shortly.

Please feel free to email me shaun at securstar dot com

Regards,
Shaun.

thang ornerythinchus

2014-06-02 07:46:50 UTC

Permalink

On Fri, 30 May 2014 10:45:44 +0100, Shaun Hollingworth

Post by Shaun Hollingworth
On Thu, 29 May 2014 14:28:20 -0700 (PDT), SafeBoot Simon

Post by SafeBoot Simon
So Shaun (long time, no speak btw!) - are you still hanging around here bored? Still working on encryption software?

Hello Simon - How are you - Yes long time no speak. :-)
Yes I'm still here, and still working on the stuff.
I don't come here all that much. I've come today to see if there's any
comments on the TrueCrypt issue.
Currently I am extremely mystified by that TrueCrypt saga, and what
the hell is going on with them. I long suspected there was more to
this than meets the eye somehow. One thing I don't understand is them
pointing everyone to bitlocker. Bitlocker might be ok, but it will
naturally be untrusted because it is MS provided and owned.
What are you up to nowadays ? Are you still working with the SafeBoot
or Endpoint as I think it is now called ?
Currently working on some new UEFI preboot code for DCPP adding touch
screen and corporate versoion support. DCPP has had UEFI support since
2011 including getting it signed by you know who for use with Secure
Boot. A process we have to go through again shortly.
Please feel free to email me shaun at securstar dot com
Regards,
Shaun.

Hey Shaun how are you? I feel I'm entitled to bust in here as I was
the OP :)

Re: the TC matter. I wanted to give it a few days to settle and to
think about it all before committing to commentary here. However, I
think the fiasco can be condensed into the following rationales:

1. The devs were sick and tired of doing development for nothing
but headaches and accusations - even the TC audit had a significant
contribution of around $65K which was much more than ever contributed
to the devs - and they didn't have the stamina or the motivation to
develop TC for Win 8 (such as you yourself have done with DCPP with
UEFI and GPT partitioning, although I haven't experimented with DCPP
5.0 yet). They decided to basically say "fuck you" to the world and
tear it all down, irretrievably (in their view) by destroying "trust"
and making ridiculous statements on their sourceforge page (migrate to
Bitlocker indeed hah) and providing binaries which would only decrypt
existing encrypted partitions. I tend to this explanation, not the
tinfoil hat explanations.

2. They were somehow intimidated by a TLA and used the old
"warrant canary" to advise those with reasonable intelligence of a
"lavabit" type intrusion. Hence: the words "Using TC is (n)ot
(s)ecure (a)s it may contain unfixed security issues"; the truly
ridiculous instruction to migrate to Bitlocker; the disappearance of
the forum; the disappearance of relevant pages from waybackmachine,
archives.org etc; and so on. However, a TLA could only hope to
include a backdoor in future versions or existing Win7 etc binaries
(7.1a) - not those millions of copies which have been downloaded all
over the world. For instance, I have all versions back to 2004 (1.0a)
and my copy of 7.1(a) was dl'd on 4 May 2012, just after release. TLA
could only hope to backdoor from now on, or to destroy trust to such
an extent that people did what the buffalo did and follow each other
into oblivion.

3. The TC audit was on the verge of identifying a huge hole in
the program - perhaps a fault with the random number generator, a back
door or something of that nature. However, why pull the plug now? Why
not wait and see if the audit finds it? After all, the devs are still
anonymous - and will remain so whether the audit finds anything or
not. And the audit will continue - Green is sitting on almost $70K of
other people's money and he has confirmed continuation. TC may even
be forked at some point after the audit.

For what it's worth, I am continuing to use TC and will do so unless
there is a gaping hole revealed by the audit. The audit will be
finalised soon (several months) and if there is no hole, then we will
have the added benefit of both the probability of a fork and the
reliability of a publicly audited source code in the past. As usual,
the lenght and complexity of the pw is the final determinant in these
cases.

I considered DCPP Shaun to be fair. The main problem I have with DCPP
is not the copywritten code nor the devs (you- you are as close to
unimpeachable that I have ever encountered, next to perhaps Schneier,
Zimmerman, Zax and a few others from the old days) - it is the fact
that the decoy OS is unusable, whereas with TC it can be used because
it is a completely separate partition. With TC, I can and do use the
decoy all of the time - business wise, downloading, letters, personal,
photos, games and so on. If I were to use DCPP, then I could not do
this - decoy use would likely destroy the hidden OS.

This is a fundamental difference which can't be changed unless the
code is re-written from the bottom up. Most of my access is to the
decoy OS, which I need to be fully functional. I only have
intermittent need for the hidden OS but I use that because there is
simply *no* leakage seeing as it is encrypted from boot to top.

So what are your thoughts? TLA intervention is unlikely - unless it
were simply to destroy trust and the audit will eventually reinstate
trust (or not perhaps). I think it was a shit fit by the devs and
they simply grew fatigued and threw in the towel and burnt their
wonderful invention to the ground. If so, what a shame.

cheers

thang

ps Actually, a few more points.

1. There is a lot of knee jerk reaction about and a lot of
alternatives being thrown about, but not strangely enough including DC
or more importantly, DCPP. I think you have an issue with marketing
of these two products - I don't know what your volumes are but these
products are not in the public persona to the extent that TC etc
are/were.

2. Can you flip me an appraisal copy of DCPP? Perhaps a temp
license or similar? It won't end up on the net (after all, you and I
have been discussing stuff on Usenet now for years and years - there's
some trust there I think) and I wouldn't mind setting it up on a 1Tb
disk I have lying around to take it through its paces. If it comes up
to scratch (with plausible deniability that is) then I may buy it.

3. An abiding mystery. Whatever happened to Sarah Dean? She too
has disappeared from waybackmachine and so on - now she would be
perfect to lead a fork of TC (or yourself Shaun, you were on the
startblocks back then too).

4. The TC licence is a funny thing. It may well prohibit a fork.
However, the devs would no longer be anonymous if they took suit over
a breach of IP were a fork to go ahead. What do you think?

xxxxxxxxxxSn Hollingwxxxorth

2014-06-02 12:34:55 UTC

Permalink

On Mon, 02 Jun 2014 15:46:50 +0800, thang ornerythinchus

Post by thang ornerythinchus
Hey Shaun how are you? I feel I'm entitled to bust in here as I was
the OP :)

Sure. :-)

Post by thang ornerythinchus
Re: the TC matter. I wanted to give it a few days to settle and to
think about it all before committing to commentary here. However, I
1. The devs were sick and tired of doing development for nothing
but headaches and accusations - even the TC audit had a significant
contribution of around $65K which was much more than ever contributed
to the devs - and they didn't have the stamina or the motivation to
develop TC for Win 8 (such as you yourself have done with DCPP with
UEFI and GPT partitioning, although I haven't experimented with DCPP
5.0 yet). They decided to basically say "fuck you" to the world and
tear it all down, irretrievably (in their view) by destroying "trust"
and making ridiculous statements on their sourceforge page (migrate to
Bitlocker indeed hah) and providing binaries which would only decrypt
existing encrypted partitions. I tend to this explanation, not the
tinfoil hat explanations.

I reckon added to that, that some of the stuff in that present audit
has really pissed them off, and if so, I do have some sympathy.
Some of it would annoy me for sure I think.

The fact that to build requires Visual C 1.52 for example. Do the
audit team KNOW WHY it is necessary to use a tool so old ? I
certainly can't find anything more suitable, at least that runs under
Windows, and I have to use it for some of my DcPP stuff. Not the
bootloader though as that uses assembler. But the enviroment we are
dealing with is older than the compiler is, that's for sure.

To me - That they questioned the use of that compiler makes me wonder
about certain aspects of this audit...

Post by thang ornerythinchus
2. They were somehow intimidated by a TLA and used the old
"warrant canary" to advise those with reasonable intelligence of a
"lavabit" type intrusion. Hence: the words "Using TC is (n)ot
(s)ecure (a)s it may contain unfixed security issues"; the truly
ridiculous instruction to migrate to Bitlocker; the disappearance of
the forum; the disappearance of relevant pages from waybackmachine,
archives.org etc; and so on. However, a TLA could only hope to
include a backdoor in future versions or existing Win7 etc binaries
(7.1a) - not those millions of copies which have been downloaded all
over the world. For instance, I have all versions back to 2004 (1.0a)
and my copy of 7.1(a) was dl'd on 4 May 2012, just after release. TLA
could only hope to backdoor from now on, or to destroy trust to such
an extent that people did what the buffalo did and follow each other
into oblivion.
3. The TC audit was on the verge of identifying a huge hole in
the program - perhaps a fault with the random number generator, a back
door or something of that nature. However, why pull the plug now? Why
not wait and see if the audit finds it? After all, the devs are still
anonymous - and will remain so whether the audit finds anything or
not. And the audit will continue - Green is sitting on almost $70K of
other people's money and he has confirmed continuation. TC may even
be forked at some point after the audit.
For what it's worth, I am continuing to use TC and will do so unless
there is a gaping hole revealed by the audit. The audit will be
finalised soon (several months) and if there is no hole, then we will
have the added benefit of both the probability of a fork and the
reliability of a publicly audited source code in the past. As usual,
the lenght and complexity of the pw is the final determinant in these
cases.
I considered DCPP Shaun to be fair. The main problem I have with DCPP
is not the copywritten code nor the devs (you- you are as close to
unimpeachable that I have ever encountered, next to perhaps Schneier,
Zimmerman, Zax and a few others from the old days) - it is the fact
that the decoy OS is unusable, whereas with TC it can be used because
it is a completely separate partition. With TC, I can and do use the
decoy all of the time - business wise, downloading, letters, personal,
photos, games and so on. If I were to use DCPP, then I could not do
this - decoy use would likely destroy the hidden OS.

I'm not sure why you still say this. DCPP now has uses a separate
partition too and has since HiddenOS support was added for windows 7.
I thought you recognised this in another post. It has to be ajacent
the system partition, but it can be a partition of any reasonable
size.

Post by thang ornerythinchus
This is a fundamental difference which can't be changed unless the
code is re-written from the bottom up. Most of my access is to the
decoy OS, which I need to be fully functional. I only have
intermittent need for the hidden OS but I use that because there is
simply *no* leakage seeing as it is encrypted from boot to top.

Well, we don't block out other data. Indeed the mainOS partition can
be accessed from hiddenos if you want. The only thing missing is the
data in the partition which stores the hiddenOS.

You can encrypt all of the paritions with different keys if you want
and control access to what you want in that way.

USB isn't blocked off. It's your choice if you want to plug something
in there though I guess we could add that at some point. Maybe I
should add a feature if a "sealed" environment is required. How do you
back stuff up then though ?

Post by thang ornerythinchus
So what are your thoughts? TLA intervention is unlikely - unless it
were simply to destroy trust and the audit will eventually reinstate
trust (or not perhaps). I think it was a shit fit by the devs and
they simply grew fatigued and threw in the towel and burnt their
wonderful invention to the ground. If so, what a shame.

I've always thought there's more to all this than meets the eye. You
know, it is said in a very old adage that "if it is too good to be
'True' " then it probably is.

So here we are with people using code updated by complete unknowns...
I have no idea what their motives are or were, or why they have thrown
in the towel right now. I do believe however that this audit has
triggered something, perhaps just a last straw. But what they have
been doing requires time, dedication, a certain disposition, and
immunity from going absolutely stark raving bonkers. It also requires
money to pay for the time spent, because earning a living doing
something else at the same time isn't really an option. Which is why
I've always thought that someone is (or was) bankrolling them for some
reason. But there's been no updates for two years, and much to do
really. Windows 8, makes some heavy requirements on system disk
encryption for a start, not least UEFI.

There's also the issue regarding UEFI and the promised update of the
software which never happened. Maybe secure boot is getting in the way
for them. Microsoft certainly want to know who you are, and what the
code is for, when they are signing your code.

Regards,
Shaun.

Post by thang ornerythinchus
cheers
thang
ps Actually, a few more points.
1. There is a lot of knee jerk reaction about and a lot of
alternatives being thrown about, but not strangely enough including DC
or more importantly, DCPP. I think you have an issue with marketing
of these two products - I don't know what your volumes are but these
products are not in the public persona to the extent that TC etc
are/were.
2. Can you flip me an appraisal copy of DCPP? Perhaps a temp
license or similar? It won't end up on the net (after all, you and I
have been discussing stuff on Usenet now for years and years - there's
some trust there I think) and I wouldn't mind setting it up on a 1Tb
disk I have lying around to take it through its paces. If it comes up
to scratch (with plausible deniability that is) then I may buy it.
3. An abiding mystery. Whatever happened to Sarah Dean? She too
has disappeared from waybackmachine and so on - now she would be
perfect to lead a fork of TC (or yourself Shaun, you were on the
startblocks back then too).
4. The TC licence is a funny thing. It may well prohibit a fork.
However, the devs would no longer be anonymous if they took suit over
a breach of IP were a fork to go ahead. What do you think?

thang ornerythinchus

2014-06-05 23:05:59 UTC

Permalink

On Mon, 02 Jun 2014 13:34:55 +0100, xxxxxxxxxxSn Hollingwxxxorth

Post by xxxxxxxxxxSn Hollingwxxxorth
On Mon, 02 Jun 2014 15:46:50 +0800, thang ornerythinchus

Post by thang ornerythinchus
Hey Shaun how are you? I feel I'm entitled to bust in here as I was
the OP :)

Sure. :-)

I reckon added to that, that some of the stuff in that present audit
has really pissed them off, and if so, I do have some sympathy.
Some of it would annoy me for sure I think.

You strike me as a very temperate and level headed person. If *you*
would be inclined to exasperation by the above and the VC issue, then
they would almost certainly. The weight of opinion is starting to
swing towards this view by such as Dr Green et al.

Post by xxxxxxxxxxSn Hollingwxxxorth
The fact that to build requires Visual C 1.52 for example. Do the
audit team KNOW WHY it is necessary to use a tool so old ? I
certainly can't find anything more suitable, at least that runs under
Windows, and I have to use it for some of my DcPP stuff. Not the
bootloader though as that uses assembler. But the enviroment we are
dealing with is older than the compiler is, that's for sure.
To me - That they questioned the use of that compiler makes me wonder
about certain aspects of this audit...

Yes. This is a very important issue of which I wasn't previously
aware (I'm not a programmer) - thanks for the professional insight.
1.52 was used here:

https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/

to compile the binaries (with a good match and all differences
explained). The writer, Xavier de Carné de Carnavalet, didn't have
any issue with use of a tool "so old" at all and ensured only the
updates to SP1 available at the time the source was developed were
used in his compilation.

Post by xxxxxxxxxxSn Hollingwxxxorth

I haven't used DCPP for a long time (I used it for several years) -
I'm wrong and I apologise. I assume DCPP thus has two encrypted
headers - track 0 for the standard system encryption header on the
first partition and somewhere on the second partition is the hidden
header (maybe 64K back from the end of the second partition like TC?)
which unless the appropriate PW flags it, will remain encrypted and
therefore deniable?

If so, then DCPP is the only semi-equivalent solution to those whose
nerves are frayed by the TC/dev debacle - "solutions" such as
bestcrypt etc do not offer hidden OS functionality.

Post by xxxxxxxxxxSn Hollingwxxxorth

Well, we don't block out other data. Indeed the mainOS partition can
be accessed from hiddenos if you want. The only thing missing is the
data in the partition which stores the hiddenOS.

That's a problem. When using the hidden OS in TC, the only "write"
which can be performed outside of that partition is on paper. Even
thumb drives are read only. No leakage at all.

Post by xxxxxxxxxxSn Hollingwxxxorth
You can encrypt all of the paritions with different keys if you want
and control access to what you want in that way.

Too unwieldy. Isn't it reasonably easy to disable/write protect all
other drives?

Post by xxxxxxxxxxSn Hollingwxxxorth
USB isn't blocked off. It's your choice if you want to plug something
in there though I guess we could add that at some point. Maybe I
should add a feature if a "sealed" environment is required. How do you
back stuff up then though ?

It would be a good feature and put your product up there with TC as a
viable alternative. Backups or transfers of data with TC require the
creation of a hidden volume on a thumb drive or on another drive - the
only exception to complete write protect.

Post by xxxxxxxxxxSn Hollingwxxxorth

I've always thought there's more to all this than meets the eye. You
know, it is said in a very old adage that "if it is too good to be
'True' " then it probably is.

That's pretty obscure Shaun. I know what your feelings have been
about the "hidden devs" in the past but I know for a fact that the FBI
could not crack TC up until at least 2011. If TC was set up as a
honeypot for some major group or even enemy state players, then you
would expect that the FBI would have access to the backdoor,
compromised random number generator or whatever. It wasn't the case
at least up until 2011 - reason being that they developed a thing
called ZSearch then to counter easily available encryption such as TC.
It was disclosed in the big "FBI Friday" hack a few years ago where
thousands of emails were splattered all over pastebin. FBI couldn't
touch TC, nor could they touch bitlocker (FWIW), PGP or Bestcrypt.

The honeypot theory is the only theory worth considering and it would
have needed to have been a huge honeypot with gigantic prospective
bees. Because it certainly hasn't been triggered yet! Because if it
had, then Snowden's messenger's TC encrypted hard drive with 50K
encrypted NSA docs on it would have been decrypted when Greenwald's
boyfriend was detained in England. And they weren't and still haven't
been decrypted.

The devs were in my view a couple (or just one) young idealistic
fellows who had the energy and motivation of youth and youthful ideals
who are now over a decade older, jaded and worn by the reality of life
and sick to the guts of people clamoring for rewrites to suit Win8 and
GPT and under perpetual attack - they took their football and went
home.

Perhaps they'll write some commercial code now and make a fortune? Who
knows.

Post by xxxxxxxxxxSn Hollingwxxxorth
So here we are with people using code updated by complete unknowns...
I have no idea what their motives are or were, or why they have thrown
in the towel right now. I do believe however that this audit has
triggered something, perhaps just a last straw. But what they have
been doing requires time, dedication, a certain disposition, and
immunity from going absolutely stark raving bonkers. It also requires
money to pay for the time spent, because earning a living doing
something else at the same time isn't really an option. Which is why
I've always thought that someone is (or was) bankrolling them for some
reason. But there's been no updates for two years, and much to do
really. Windows 8, makes some heavy requirements on system disk
encryption for a start, not least UEFI.
There's also the issue regarding UEFI and the promised update of the
software which never happened. Maybe secure boot is getting in the way
for them. Microsoft certainly want to know who you are, and what the
code is for, when they are signing your code.

That's another interesting point. Sigs would destroy anonymity.
Although perhaps the unusual step of recommending Bitlocker is nothing
but a ploy to gain the approval of MS so that a future version of
something which will not be named TC can be signed by MS? No one has
considered this - what if the devs want to fork TC and make some money
out of a future version, but in order to do that they need to
modernise it for Win 8 and future WinXX's and in order to do that they
need to have it signed - what better way than to kill it now,
recommend MS proprietary code (only available to professional and
ultimate however) and then gain the approval of MS?

Interesting...

regards

thang

Post by xxxxxxxxxxSn Hollingwxxxorth
Regards,
Shaun.