U.S. Gov't to use Full Disk Encryption on All Computers

To address the issue of data leaks from stolen or missing laptops, US
Government is planning to use Full Disk Encryption (FDE) on all of the
Government owned computers. On June 23, 2006 a Presidential Mandate was
put in place requiring all agency laptops to fully encrypt data on the
HDD. The US Government is currently conducting the largest single
side-by-side comparison and competition for the selection of a Full
Disk Encryption product. This implementation will end up being the
largest single implementation ever, and all of the information
regarding the competition is in the public domain. The selected product
will be deployed on Millions of computers in the US federal government
space. The evaluation will come to a end in 90 days.

....... Read complete article at:
http://www.full-disk-encryption.net/fde_govt.html

Holy SH_ IT'S ABOUT TIME

"Saqib Ali" <docbook.xml@gmail.com> wrote in message
news:1167431729.448146.8640@v33g2000cwv.googlegrou ps.com...
> To address the issue of data leaks from stolen or missing laptops, US
> Government is planning to use Full Disk Encryption (FDE) on all of the
> Government owned computers. On June 23, 2006 a Presidential Mandate was
> put in place requiring all agency laptops to fully encrypt data on the
> HDD. The US Government is currently conducting the largest single
> side-by-side comparison and competition for the selection of a Full
> Disk Encryption product. This implementation will end up being the
> largest single implementation ever, and all of the information
> regarding the competition is in the public domain. The selected product
> will be deployed on Millions of computers in the US federal government
> space. The evaluation will come to a end in 90 days.
>
> ...... Read complete article at:
> http://www.full-disk-encryption.net/fde_govt.html
>

"Saqib Ali" <docbook.xml@gmail.com> wrote in message
news:1167431729.448146.8640@v33g2000cwv.googlegrou ps.com...
> To address the issue of data leaks from stolen or missing laptops, US
> Government is planning to use Full Disk Encryption (FDE) on all of the
> Government owned computers. On June 23, 2006 a Presidential Mandate
> was
> put in place requiring all agency laptops to fully encrypt data on the
> HDD. The US Government is currently conducting the largest single
> side-by-side comparison and competition for the selection of a Full
> Disk Encryption product. This implementation will end up being the
> largest single implementation ever, and all of the information
> regarding the competition is in the public domain. The selected
> product
> will be deployed on Millions of computers in the US federal government
> space. The evaluation will come to a end in 90 days.
>
> ...... Read complete article at:
> http://www.full-disk-encryption.net/fde_govt.html
>


Still won't help with all those boobs that walk away from their laptop
to leave it unattended while still logged on and without the screen
saver enabled or session otherwise locked out.

All very good points, no software will stop the total incompetence of the
users except replacing them with robots :-/
Dave


"Juergen Nieveler" <juergen.nieveler.nospam@arcor.de> wrote in message
news:Xns98AA90A4480Fjuergennieveler@nieveler.org.. .
> "Vanguard" <vanguard.news@yahooNIX.com> wrote:
>
>> Still won't help with all those boobs that walk away from their laptop
>> to leave it unattended while still logged on and without the screen
>> saver enabled or session otherwise locked out.
>
> Or with the username and password on a post-it attached to the laptop...
>
> Juergen Nieveler
> --
> "It's going to require numerous IRA agents."
> George W. Bush on Gore's tax plan, Greensboro, N.C., Oct. 10, 2000

Vanguard wrote:
> "Saqib Ali" <docbook.xml@gmail.com> wrote in message
> news:1167431729.448146.8640@v33g2000cwv.googlegrou ps.com...
>> To address the issue of data leaks from stolen or missing laptops, US
>> Government is planning to use Full Disk Encryption (FDE) on all of the
>> Government owned computers. On June 23, 2006 a Presidential Mandate was
>> put in place requiring all agency laptops to fully encrypt data on the
>> HDD. The US Government is currently conducting the largest single
>> side-by-side comparison and competition for the selection of a Full
>> Disk Encryption product. This implementation will end up being the
>> largest single implementation ever, and all of the information
>> regarding the competition is in the public domain. The selected product
>> will be deployed on Millions of computers in the US federal government
>> space. The evaluation will come to a end in 90 days.
>>
>> ...... Read complete article at:
>> http://www.full-disk-encryption.net/fde_govt.html
>>
>
>
> Still won't help with all those boobs that walk away from their laptop
> to leave it unattended while still logged on and without the screen
> saver enabled or session otherwise locked out.

Sure it will because the "mandate" must also require that the computer
automatically logout after 5 minutes of no use!

Saqib Ali wrote:
> To address the issue of data leaks from stolen or missing laptops, US
> Government is planning to use Full Disk Encryption (FDE) on all of the
> Government owned computers. On June 23, 2006 a Presidential Mandate was
> put in place requiring all agency laptops to fully encrypt data on the
> HDD. The US Government is currently conducting the largest single
> side-by-side comparison and competition for the selection of a Full
> Disk Encryption product. This implementation will end up being the
> largest single implementation ever, and all of the information
> regarding the competition is in the public domain. The selected product
> will be deployed on Millions of computers in the US federal government
> space. The evaluation will come to a end in 90 days.
>
> ...... Read complete article at:
> http://www.full-disk-encryption.net/fde_govt.html
>

I would assume that the encryption would also accompany compression. It
takes about as many cycles to decompress as it does to decrypt?

With FDE, the encryption is not a off-line process. Every bit is
encrypted at the Kernel or Hardware level as it is written to the HDD
platter. Think of it as a stream cipher. So there is no compression or
decompression involved......

saqib
http://www.full-disk-encryption.net



Rick Merrill wrote:
> Saqib Ali wrote:
> > To address the issue of data leaks from stolen or missing laptops, US
> > Government is planning to use Full Disk Encryption (FDE) on all of the
> > Government owned computers. On June 23, 2006 a Presidential Mandate was
> > put in place requiring all agency laptops to fully encrypt data on the
> > HDD. The US Government is currently conducting the largest single
> > side-by-side comparison and competition for the selection of a Full
> > Disk Encryption product. This implementation will end up being the
> > largest single implementation ever, and all of the information
> > regarding the competition is in the public domain. The selected product
> > will be deployed on Millions of computers in the US federal government
> > space. The evaluation will come to a end in 90 days.
> >
> > ...... Read complete article at:
> > http://www.full-disk-encryption.net/fde_govt.html
> >
>
> I would assume that the encryption would also accompany compression. It
> takes about as many cycles to decompress as it does to decrypt?

on 31 Dec 2006, something possessed Rick Merrill to write:

> Vanguard wrote:
>> "Saqib Ali" <docbook.xml@gmail.com> wrote in message
>> news:1167431729.448146.8640@v33g2000cwv.googlegrou ps.com...
>>> To address the issue of data leaks from stolen or missing laptops,
>>> US Government is planning to use Full Disk Encryption (FDE) on all
>>> of the Government owned computers. On June 23, 2006 a Presidential
>>> Mandate was put in place requiring all agency laptops to fully
>>> encrypt data on the HDD. The US Government is currently conducting
>>> the largest single side-by-side comparison and competition for the
>>> selection of a Full Disk Encryption product. This implementation
>>> will end up being the largest single implementation ever, and all of
>>> the information regarding the competition is in the public domain.
>>> The selected product will be deployed on Millions of computers in
>>> the US federal government space. The evaluation will come to a end
>>> in 90 days.
>>>
>>> ...... Read complete article at:
>>> http://www.full-disk-encryption.net/fde_govt.html
>>>
>>
>>
>> Still won't help with all those boobs that walk away from their
>> laptop to leave it unattended while still logged on and without the
>> screen saver enabled or session otherwise locked out.
>
> Sure it will because the "mandate" must also require that the computer
> automatically logout after 5 minutes of no use!
>
>

But does this mandate also require that the computer users don't accept
any old active-X plugin? Or prohibit Java except for certain webhosts?

on 31 Dec 2006, something possessed Saqib Ali to write:

> With FDE, the encryption is not a off-line process. Every bit is
> encrypted at the Kernel or Hardware level as it is written to the HDD
> platter. Think of it as a stream cipher. So there is no compression or
> decompression involved......
>
> saqib
> http://www.full-disk-encryption.net
>
>
>
> Rick Merrill wrote:
>> Saqib Ali wrote:
>> > To address the issue of data leaks from stolen or missing laptops,
>> > US Government is planning to use Full Disk Encryption (FDE) on all
>> > of the Government owned computers. On June 23, 2006 a Presidential
>> > Mandate was put in place requiring all agency laptops to fully
>> > encrypt data on the HDD. The US Government is currently conducting
>> > the largest single side-by-side comparison and competition for the
>> > selection of a Full Disk Encryption product. This implementation
>> > will end up being the largest single implementation ever, and all
>> > of the information regarding the competition is in the public
>> > domain. The selected product will be deployed on Millions of
>> > computers in the US federal government space. The evaluation will
>> > come to a end in 90 days.
>> >
>> > ...... Read complete article at:
>> > http://www.full-disk-encryption.net/fde_govt.html
>> >
>>
>> I would assume that the encryption would also accompany compression.
>> It takes about as many cycles to decompress as it does to decrypt?
>
>

Does this full-disk encryption protect against most trojan-downloader
users, though? I mean, if some program like Back Orifice got onto the
machine, then couldn't the remote cracker get access to the data, even
though the entire disk is encrypted, via whatever host-kernal's
encryption/decryption mechanism?

In article <Xns98ABB196CD1Williamyourclothes@207.115.17.102 >,
William <starrwarz@g_~-clothes-~_m~more_clothes~ail.com> wrote:

> Does this full-disk encryption protect against most trojan-downloader
> users, though? I mean, if some program like Back Orifice got onto the
> machine, then couldn't the remote cracker get access to the data, even
> though the entire disk is encrypted, via whatever host-kernal's
> encryption/decryption mechanism?

This is not the threat they're attempting to deal with, so why is this
relevant? No single mandate is expected to be a panacea that can solve
all problems. They're trying to deal with the problems that have been
caused by all the highly-publicized losses of laptops.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (06-12-31 20:42:16):

> I would assume that the encryption would also accompany
> compression. It takes about as many cycles to decompress as it does to
> decrypt?

Why? The one has nothing to do with the other (besides some base
theories). Compressed encryption would, however, increase security,
because it would destroy a lot of redundancy. But firstly this is not
possible for online encryption. Secondly it would decrease performance
drastically. And finally today's encryption modes (to mention at least
CBC and LRW; the latter is favorable IMO) successfully scramble that
redundancy.


Happy new year --
Regards,
E.S.

Ertugrul Soeylemez wrote:
> Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (06-12-31 20:42:16):
>
>> I would assume that the encryption would also accompany
>> compression. It takes about as many cycles to decompress as it does to
>> decrypt?
>
> Why? The one has nothing to do with the other (besides some base
> theories). Compressed encryption would, however, increase security,
> because it would destroy a lot of redundancy. But firstly this is not
> possible for online encryption. Secondly it would decrease performance
> drastically. And finally today's encryption modes (to mention at least
> CBC and LRW; the latter is favorable IMO) successfully scramble that
> redundancy.

There are tools that compress using a password - think of runlength
encoding with a CRC.

> Does this full-disk encryption protect against most trojan-downloader
> users, though? I mean, if some program like Back Orifice got onto the
> machine, then couldn't the remote cracker get access to the data, even
> though the entire disk is encrypted, via whatever host-kernal's
> encryption/decryption mechanism?

That is not what the objective of this project is. The project is aimed
towards protecting the data while it is "at rest". i.e. in case of the
theft of the mobile device. The intend is to prevent exposure of
confidential data when a Gov't agency loses a laptop.

But having said that, Enova's X-Wall Asic (Hardware based FDE) supports
a "Pass Through Mode". Which makes it possible to configure your
system such that any attempt to download data to an "outside the box"
location (e.g. a Web Site or other IP address) would automatically
invoke the "Pass Though Mode" and all the downloader gets is the
encrypted data.

If you are the owner of that data you can still have access if you have
an X-Wall enabled device using the same key/dongle combination. This
way you can have secure access to you data anywhere you are so long as
you have a network connection.

saqib
http://www.full-disk-encryption.net

Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (07-01-01 15:34:55):

> > > I would assume that the encryption would also accompany
> > > compression. It takes about as many cycles to decompress as it does
> > > to decrypt?
> >
> > Why? The one has nothing to do with the other (besides some base
> > theories). Compressed encryption would, however, increase security,
> > because it would destroy a lot of redundancy. But firstly this is
> > not possible for online encryption. Secondly it would decrease
> > performance drastically. And finally today's encryption modes (to
> > mention at least CBC and LRW; the latter is favorable IMO)
> > successfully scramble that redundancy.
>
> There are tools that compress using a password - think of runlength
> encoding with a CRC.

Yes, but "compression using a password" is actually "compressing, and
then encrypting with a password". The CRC is something completely
independent of both steps. It only helps spotting transmission errors.
And encoding has nothing (much) to do with encryption.


Regards,
E.S.

Saqib Ali wrote:
> To address the issue of data leaks from stolen or missing laptops, US
> Government is planning to use Full Disk Encryption (FDE) on all of the
> Government owned computers. On June 23, 2006 a Presidential Mandate
> was put in place requiring all agency laptops to fully encrypt data
> on the HDD. The US Government is currently conducting the largest
> single side-by-side comparison and competition for the selection of a
> Full Disk Encryption product. This implementation will end up being
> the largest single implementation ever, and all of the information
> regarding the competition is in the public domain. The selected
> product will be deployed on Millions of computers in the US federal
> government space. The evaluation will come to a end in 90 days.
>
> ...... Read complete article at:
> http://www.full-disk-encryption.net/fde_govt.html

Hello,

There is an alternative to full disk encryption, providing the same privacy
level, at no cost: to run a virtual machine whose files are stored in an
encrypted container.

Examples:

- Virtual machine software: Virtual PC (on Windows host machine), VMware and
Qemu (on Windows and Linux host machines)
- Guest machines: any X86 machine (DOS, Windows, Linux, FreeBSD...)
- OTFE encryption software: TrueCrypt (Windows, Linux).

The whole solution can be done at no cost.

The guest machine doesn't leak anything; all its files (including temp and
swap files) are in an encrypted container.

Backup of the host machine is unchanged, backup of the guest machine is
simply and securely done by copying the file corresponding to the encrypted
container on a backup media (i.e. USB mass storage disk).

Precautions should be taken to transfer data to the guest machine without
letting "plain" traces on the host machine; for example, a secure ftp client
connects from the guest machine to a secure ftp server on a LAN; encrypted
data get through the host TCPIP stack to the guest machine.

I built such a solution very easily with:
- host machine: Windows XP,
- virtual machine software: VMware Player (yes, you can build a guest
machine with VMware Player, even if VMware says it is not possible; see for
example http://www.easyvmx.com/easyvmx.shtml; you also need to get VMware
tools from a VMware test distribution),
- guest machine: Windows 2000 Professional (with two vmdk disks, one of 4 GB
for system, one of 5 GB for data),
- OTFE software: TrueCrypt (one container, 12 GB contains the two vmdk disks
+ vmx configuration file; this lets room for VMware temporary files and for
enventually copying the ISO image of a CD-ROM to be mounted).

I think this solution less risky to implement than a full disk encrytption
one (newsgroups are full of people having done something wrong and unable to
recover their system). And TrueCrypt is an *OpenSource* software (how could
you rely on an undisclosed source encryption software)?

Just some comments about www.full-disk-encryption.net site:

- In the list of FDE, you could add GBDE and GELI, both FreeBSD modules
allowing full disk encryption, see
http://www.freebsd.org/doc/en_US.ISO...ncrypting.html
and
http://events.ccc.de/congress/2005/f...Encryption.pdf.
GBDE and GELI are OpenSource softwares.

- The site does not mention hardware solutions, for example HP Drivecrypt on
some notebooks, Trust Way RCI (Bull) or Flagstone disks (Hermitage
Solutions).

- Your comparative list should indicate which solutions are OpenSource and
which aren't.

Regards,


--
Michel Nallino aka WinTerMiNator
http://anonapps.samizdat.net (Anonymat sur Internet)
Adresse e-mail invalide; pour me contacter:
http://www.cerbermail.com/?vdU5HHs5WG

Ertugrul Soeylemez wrote:
> Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (07-01-01 15:34:55):
>
>>>> I would assume that the encryption would also accompany
>>>> compression. It takes about as many cycles to decompress as it does
>>>> to decrypt?
>>> Why? The one has nothing to do with the other (besides some base
>>> theories). Compressed encryption would, however, increase security,
>>> because it would destroy a lot of redundancy. But firstly this is
>>> not possible for online encryption. Secondly it would decrease
>>> performance drastically. And finally today's encryption modes (to
>>> mention at least CBC and LRW; the latter is favorable IMO)
>>> successfully scramble that redundancy.
>> There are tools that compress using a password - think of runlength
>> encoding with a CRC.
>
> Yes, but "compression using a password" is actually "compressing, and
> then encrypting with a password". The CRC is something completely
> independent of both steps. It only helps spotting transmission errors.
> And encoding has nothing (much) to do with encryption.
>
>
> Regards,
> E.S.

Originally true, but the particular CRC pattern is chosen to deal with
the expected noise impact during transmission (e.g. 1 sec bursts). You
can use other CRC patterns to encrypt.

> There is an alternative to full disk encryption, providing the same privacy
> level, at no cost: to run a virtual machine whose files are stored in an
> encrypted container.

All of your suggestion involve quite a bit of overhead, are inelegant
and require user interaction.

One of the requirement for this Government project is that the solution
has to be transparent to the user.

saqib
http://www.full-disk-encryption.net

Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (07-01-02 12:57:24):

> > > There are tools that compress using a password - think of
> > > runlength encoding with a CRC.
> >
> > Yes, but "compression using a password" is actually "compressing,
> > and then encrypting with a password". The CRC is something
> > completely independent of both steps. It only helps spotting
> > transmission errors. And encoding has nothing (much) to do with
> > encryption.
>
> Originally true, but the particular CRC pattern is chosen to deal with
> the expected noise impact during transmission (e.g. 1 sec bursts). You
> can use other CRC patterns to encrypt.

I really don't know why you relate CRC to encryption in any way. CRC is
just a checksum algorithm. It's not secure, it's not clever, it's just
a checksum.


Regards,
E.S.

Ertugrul Soeylemez wrote:
> Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (07-01-02 12:57:24):
>
>>>> There are tools that compress using a password - think of
>>>> runlength encoding with a CRC.
>>> Yes, but "compression using a password" is actually "compressing,
>>> and then encrypting with a password". The CRC is something
>>> completely independent of both steps. It only helps spotting
>>> transmission errors. And encoding has nothing (much) to do with
>>> encryption.
>> Originally true, but the particular CRC pattern is chosen to deal with
>> the expected noise impact during transmission (e.g. 1 sec bursts). You
>> can use other CRC patterns to encrypt.
>
> I really don't know why you relate CRC to encryption in any way. CRC is
> just a checksum algorithm. It's not secure, it's not clever, it's just
> a checksum.
>
>
> Regards,
> E.S.


CRC != checksum in any way shape or form. Check with your professor.

> CRC != checksum in any way shape or form. Check with your professor.

CRC is a function that produces a checksum. See:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check


saqib
http://www.full-disk-encryption.net

Saqib Ali wrote:
>> CRC != checksum in any way shape or form. Check with your professor.
>
> CRC is a function that produces a checksum. See:
> http://en.wikipedia.org/wiki/Cyclic_redundancy_check
>
>
> saqib
> http://www.full-disk-encryption.net
>

If you get your learning from Wiki you are in a sorry state.
The Wiki entry is incorrect in it's terminology. A "checksum"
is the 1's complement of the sum of all preceding bits. A
drop in of zeros of any length will not produce an invalid
checksum. I'm sure you can see that.

However, a drop in of any number of zero bytes will produce
an invalid result when using a CRC.

This is really just a language problem caused because true
'checksum' is so rare these days.

Rick Merrill <rick0.merrill@NOSPAM.gmail.com> (07-01-04 11:46:03):

> If you get your learning from Wiki you are in a sorry state. The Wiki
> entry is incorrect in it's terminology. A "checksum" is the 1's
> complement of the sum of all preceding bits. A drop in of zeros of any
> length will not produce an invalid checksum. I'm sure you can see
> that.
>
> However, a drop in of any number of zero bytes will produce an invalid
> result when using a CRC.
>
> This is really just a language problem caused because true 'checksum'
> is so rare these days.

Still it's unclear what you mean. You're talking about noise and a CRC
for encrypting. Yes, CRC is supposed to detect noise, but it can't be
used in any way in a cryptographic application. Cryptographic hash
functions are your friends there.


Regards,
E.S.