Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Jan 19, 2007, at 4:06 AM, Bill Stewart wrote: [...] if you're trying to protect against KGB-skilled attacks [...] On the other hand, if you're trying to protect against lower-skilled attackers, [...] I always find these arguments particularly frustrating. By slowly raising the bar for the lower-skilled criminals, you get the effect in Steven's firewall book cover (I forget the version, where you must be a certain height to attack the castle.) For me, the bottom line is that if you protect against the former, then you get the latter, and it is only a small matter of time when the lower-skilled people will get a script to do the higher quality attacks. Remember WEP? I really have to question continuing a snail's pace information protection arms war when we have all the tools we need to properly defend ourselves. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Jan 18, 2007, at 6:57 PM, Saqib Ali wrote: When is the last time you checked the code for the open source app that you use, to make sure that it is written properly? 30 seconds ago. What mode is it using? How much information is encrypted under a single key. Was the implementation FIPS certified. And the list goes on. These are important issues. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Victor Duchovni [EMAIL PROTECTED] writes: It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning behind this. I don't think any ASN.1-using security toolkit since TIPEM has done character-set checking, it would fail to verify a large chunk of the certs out there (I once had a TIPEM user complain to me that they had to stop using it specifically because it would reject invalid character strings, which encompassed a nontrivial portion of their user base). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Fri, 19 Jan 2007, Bill Stewart wrote: Obviously if you're trying to protect against KGB-skilled attacks on stolen/confiscated hardware, you'd like to have the swap partition encrypted as well as any user data partitions, though you may not care whether your read-only utility software was protected (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) [[...]] On the other hand, if you're trying to protect against lower-skilled attackers, e.g. laptop thieves who are reselling disks to the Nigerians and other hardware on eBay, you want to protect your file systems, but probably don't need to protect your swap. It's certainly nice to do that, of course, and might be a Good Thing for Linux and ***BSD to include in their standard swap drivers, OpenBSD has had swap-space encryption for some years, and recent versions turn it on in the default install. I don't know what the other BSDs or various Linuxen do by default. OpenBSD's swap encryption uses Rajndael/AES implemented in software. The performance hit is small on modern hardware, and still acceptable even on slow hardware (I haven't seen any problems on an old 486/33 laptop I'm using as a home firewall/router). For laptops (where physical theft is major concern), I think the combination of an encrypting file system and swap encryption gives a pretty good -- and readily configurable -- security/performance tradeoff. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote: Victor Duchovni [EMAIL PROTECTED] writes: It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning behind this. I don't think any ASN.1-using security toolkit since TIPEM has done character-set checking, it would fail to verify a large chunk of the certs out there (I once had a TIPEM user complain to me that they had to stop using it specifically because it would reject invalid character strings, which encompassed a nontrivial portion of their user base). I understand the motivation, and agree that this is the right thing to do, indeed in the application (Postfix) I just map the content to UTF8 (using the identity mapping where appropriate) and then decide what characters are acceptable, I don't need the original ASN.1 string type after the string is in canonical form. My point was that not all the fine details are always documented (even in closed source libraries with funded documentation teams), and having the source allows me to move beyond cargo-cult programming and to understand how to use the library correctly. I guess this is RTFS to extract the semantics out of the syntax documentation. In addition, I think that the library should-provide idiot-friendly interfaces for handling ASN.1 string data holding security sensitive information (CommonName, subjectAltName, ...), because the code one finds and copies from other projects is not sufficiently careful. RFC 3820 suggests that it is OK to consider strings of different ASN.1 types as different content for comparison and then, by implication, just compare the raw content when the types match, but what one finds is that applications mostly IGNORE the ASN.1 string type and use the raw octets for comparison, display, ... and they do that at their peril. It is also almost universal practice (in C code anyway) to not check for embedded NUL in the ASN.1 strings, and I wonder how may CAs would issue eve.biz a cert for alice.com\0..eve.biz? (If the CA's code handles NUL in octet strings as just another byte, this could happen. But we digress again, the source is useful in any case, and not just for full code reviews, used with care it is the ultimate documentation. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Thu, Jan 18, 2007 at 03:57:46PM -0800, Saqib Ali wrote: When is the last time you checked the code for the open source app that you use, to make sure that it is written properly? Yesterday, in the case of OpenSSL, though I was only looking at how ASN.1 strings that store the subject CN and subjectAltName deal with the various possible supported encodings, embedded NUL octets, ... It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. - Rather in OpenSSL all the ASN.1 string types are opaque TLV byte arrays, with a manifest type and arbitrary content that may or not be consisten with the type, and may hold embedded NUL bytes which require some care in C applications, but at least it *is* possible if is careful, to check that: ASN_STRING_length(s) == strlen(ASN1_STRING_DATA(s)) - Conversion to UTF8 is implemented correctly, without prematurely stopping on internal NUL octets. This also checks that BMPString and UniversalStrings have encoded lengths that are even or divisible by 4 respectively, and that UTF8 input is valid and minimal. This means that as a user of the library, I must (and fortunately can): - Convert the raw ASN.1 encoded data if BMPString or UniversalString to UTF8. - Check CommonNames and DNS subjectAltNames for internal NULs, because I can't rely on no CA to ever mess up and sign a cert for alice.com\0.eve.com. This check is not found in most sample applications that (cargo-cult programming rampant in other problem spaces is also common with SSL). - Check CommonNames and DNS subjectAltNames for unexpected non-printable or non-printable characters as appropriate. This is not the same as a full code review, but having access to the source means that I can make sure that my code is a correct use of the interface, that I am not making unfounded assumptions, and there are no obvious bugs in the part of the library that I am reviewing. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
At 03:57 PM 1/18/2007, Saqib Ali wrote: When is the last time you checked the code for the open source app that you use, to make sure that it is written properly? When is the last time you carefully checked the code for a closed source app that you use? (Besides the one you mentioned to start this thread) Steve - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
As far as Full Disk Encryption's usefulness as a term goes, I'd distinguish between several different kinds of applications for encrypting the contents of a disk 1 - The disk drive or maybe disk controller card (RAID, SCSI, etc.) encrypts all the bits written to the drive and decrypts all the bits read from the drive, usually with some keying input from the OS. 2 - The operating system's driver software encrypts/decrypts all bits written to/from the drive 3 - The operating system's file system driver software encrypts/decrypts all bits written to/from a file system (which might or might not occupy a drive partition.) 4 - Utility software encrypts/decrypts bits written to/from directories. 5 - Application software encrypts/decrypts contents of files. Obviously if you're trying to protect against KGB-skilled attacks on stolen/confiscated hardware, you'd like to have the swap partition encrypted as well as any user data partitions, though you may not care whether your read-only utility software was protected (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) Whether you implement that in the disk controller or OS is really a matter of convenience and user support economics - if you're a small conspiracy you may want to roll your own, but if you're a corporate IT shop, you've probably got economic issues that affect whether you customize the OS (more) or the disks or both and it's the operational processes that will trip you up. On the other hand, if you're trying to protect against lower-skilled attackers, e.g. laptop thieves who are reselling disks to the Nigerians and other hardware on eBay, you want to protect your file systems, but probably don't need to protect your swap. It's certainly nice to do that, of course, and might be a Good Thing for Linux and ***BSD to include in their standard swap drivers, but hopefully your file system drivers would keep their keys in non-swappable memory, and most other things get overwritten often enough that attackers not using electron microscopes probably won't bother with them much. In most OS's, swap isn't persistent across system reboots, so you can actually generate a new key on the fly every time and not bother the user about entering it, unlike regular filesystems or full-disk-encryption systems. Of course, if the KGB *is* after you, they may black-bag your PC before they confiscate it - if there's a key-logger chip added to your keyboard or a camera mounted in your ceiling light, it may not matter how cool your FDE is. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Saqib Ali wrote: Since when did AES-128 become snake-oil crypto? How come I missed that? Compusec uses AES-128 . And as far as I know AES is NOT snake-oil crypto Saqib, I believe you are correct as to the algorithm, but the snake-oil is in the implementation, As I have often said, A misplaced comma in an English sentence will merely get you a bad reputation as a writer, however, a misplaced comma in a nuclear weapons project may leave an enduring mark on the world. Algorithms can be perfect and implementation sloppy. If you can review the code you might find the problem, but with proprietary code, fergetit. Closed-source doesn't mean that it is snake-oil. If that was the case, the Microsoft's EFS, and Kerberos implementation would be snake oil too. As I recall there have been a few problems with Kerberos in the past. Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Algorithms can be perfect and implementation sloppy. If you can review the code you might find the problem, but with proprietary code, fergetit. I think you guys are missing the point. The term Snake-Oil Crypto refers to the algorithm and NOT the actual implementation. This is a important distinction. I am copying Matt Curtain (who maintains Snake-Oil Crypto FAQ) and Bruce Schneier so that they can correct me if I am wrong. We all know that many open crypto algorithms (like kerberos, AES) have been implemented in sloppy manner in both open-source and close-source world. Being open source doesn't necessarily mean that the implementation is secure. When is the last time you checked the code for the open source app that you use, to make sure that it is written properly? saqib http://www.full-disk-encryption.net On 1/18/07, Allen [EMAIL PROTECTED] wrote: Saqib Ali wrote: Since when did AES-128 become snake-oil crypto? How come I missed that? Compusec uses AES-128 . And as far as I know AES is NOT snake-oil crypto Saqib, I believe you are correct as to the algorithm, but the snake-oil is in the implementation, As I have often said, A misplaced comma in an English sentence will merely get you a bad reputation as a writer, however, a misplaced comma in a nuclear weapons project may leave an enduring mark on the world. Closed-source doesn't mean that it is snake-oil. If that was the case, the Microsoft's EFS, and Kerberos implementation would be snake oil too. As I recall there have been a few problems with Kerberos in the past. Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Mon, 15 Jan 2007 08:39:18 -0800 Saqib Ali [EMAIL PROTECTED] wrote: An article on how to use freely available Full Disk Encryption (FDE) products to protect the secrecy of the data on your laptops. FDE solutions helps to prevent data leaks in case the laptop is stolen or goes missing. The article includes a brief intro, benefits, drawbacks, some tips, and a complete list of FDE solutions in the market. http://www.full-disk-encryption.net/intro.php I'll turn it around -- why should you use it? In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. It's harmful because you can lose a key. (Your web page does address that, but I'm perplexed -- what is challenge/response authentication for key recovery?) Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. (Caveat: I'm assuming that when you dispose of systems, you run DBAN or some such on the drives -- if not, we're back to the physical access threat.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Mon, 15 Jan 2007 08:39:18 -0800 Saqib Ali [EMAIL PROTECTED] wrote: An article on how to use freely available Full Disk Encryption (FDE) products to protect the secrecy of the data on your laptops. FDE solutions helps to prevent data leaks in case the laptop is stolen or goes missing. The article includes a brief intro, benefits, drawbacks, some tips, and a complete list of FDE solutions in the market. http://www.full-disk-encryption.net/intro.php On Tue, 16 Jan 2007, Steven M. Bellovin wrote: I'll turn it around -- why should you use it? In most situations, disk encryption is useless and probably harmful. [[cogent arguments snipped]] A further point: Do you really want the granularity of your encryption to be one key per disk? I much prefer a cryptographic file system which lets me have separate keys for separate categories of information (eg one key for my tax forms, a different key for company-confidential project stuff, a different key for old love letters, still another one for My Secret Plan For World Domination, etc etc). These might all live on the same laptop, but they probably need quite different key policies. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007, Steven M. Bellovin wrote: [[about full-disk encryption]] In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. Yes, encrypted disks aren't much good unless the OS also encrypts (at least) swap space. I note that OpenBSD ships with swap-space encryption turned on by default. The encryption is done in software using Rijndael. On modern hardware the performance hit is minimal (compared to the cost of the disk access). See http://www.openbsd.org/papers/swapencrypt.ps for a discussion of the security model. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. As governments widen their definitions of just who is a potential threat it makes increasing sense for citizens engaged in previous innocuous activities (especially political and financial privacy) to protect their data from being useful if seized. This goes double for those operating privacy-oriented services and their servers. As an example, when TOR servers were recently seized in German raids (with the implication that they were being used as conduits for child porn) the police knew enough to only take the hot-swap drives (which were encrypted and therefore paper weights after removal) if only for show. The main loss to the operators was repair to the cage locks. Steve - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007 07:56:22 -0800 Steve Schear [EMAIL PROTECTED] wrote: At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. As governments widen their definitions of just who is a potential threat it makes increasing sense for citizens engaged in previous innocuous activities (especially political and financial privacy) to protect their data from being useful if seized. This goes double for those operating privacy-oriented services and their servers. As an example, when TOR servers were recently seized in German raids (with the implication that they were being used as conduits for child porn) the police knew enough to only take the hot-swap drives (which were encrypted and therefore paper weights after removal) if only for show. The main loss to the operators was repair to the cage locks. Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. And of course, there's always rubber hose cryptanalysis in jurisdictions where that's acceptable. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Dr. Bellovin, In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. I am not sure I understand this. With FDE, the HDD is unlocked by a pre-boot kernel (linux). It is not the function of the resident OS to unlock the drive. It's harmful because you can lose a key. (Your web page does address that, but I'm perplexed -- what is challenge/response authentication for key recovery?) Challenge/Response password recovery, as I understand, is a very simplified implementation of Secret Sharing. It allows for 2 parties, in this case the IT HelpDesk and the User, to collaborate and recover a Secret. 1) Upon forgetting the password, the user calls the Help Desk. 2) The IT Help Desk authenticates the user in the usual ways (e.g. check office voice mail etc), as the policy dictates. 3) Once authenticated the user give the partial secret to the HelpDesk. 4) The HelpDesk then combine it with the secret they have to produce a temporary password. 5) The temporary password is then used to unlock the HDD once, and new credentials are created. -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin Yup. Disk Crypto has a ugly side as well, as highlighted by the recent incident where FBI was unable to crack the encryption used by a pedophile and murderer. There was a long discussion on this topic on the Security-Basics mailing list: http://www.xml-dev.com/lurker/thread/20061020.173753.ee4c6a0c.en.html#20061020.173753.ee4c6a0c saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007 08:19:41 -0800 Saqib Ali [EMAIL PROTECTED] wrote: Dr. Bellovin, In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. I am not sure I understand this. With FDE, the HDD is unlocked by a pre-boot kernel (linux). It is not the function of the resident OS to unlock the drive. Not necessarily -- many of my systems have multiple disk drives and file systems, some of which are on removable media. Apart from that, though, this is reinforcing my point -- what is the threat model? It's harmful because you can lose a key. (Your web page does address that, but I'm perplexed -- what is challenge/response authentication for key recovery?) Challenge/Response password recovery, as I understand, is a very simplified implementation of Secret Sharing. It allows for 2 parties, in this case the IT HelpDesk and the User, to collaborate and recover a Secret. 1) Upon forgetting the password, the user calls the Help Desk. 2) The IT Help Desk authenticates the user in the usual ways (e.g. check office voice mail etc), as the policy dictates. 3) Once authenticated the user give the partial secret to the HelpDesk. 4) The HelpDesk then combine it with the secret they have to produce a temporary password. 5) The temporary password is then used to unlock the HDD once, and new credentials are created. I wouldn't call that challenge/response, I'd call that key escrow. Key escrow isn't a bad idea for storage encryption, but you need *really* good authentication mechanisms for the backup channel. Visualize this phone call to the help desk: Hi, I'm Pat, the CFO. I'm in New York for the Board meeting, and my laptop blue-screened and won't reboot -- it's not accepting my passphrase. Help! Of course, more or less by definition, Pat isn't online at that point, so the help desk can't manipulate anything remotely. (I should add that most secondary authentication mechanisms I've seen are garbage, especially when it comes to people on the road. Since we're talking about laptops here, that's a very serious threat.) I don't dispute the need for FDE for (many) laptops. But remember that security is a systems property; it's not something you can get by bolting on crypto. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Yes, encrypted disks aren't much good unless the OS also encrypts (at least) swap space. I note that OpenBSD ships with swap-space I think you are confusing Disk Encryption with Full Disk Encryption (FDE). They are two different beast. FDE encrypts the entire boot drive, including the OS, kernel and the swap space. Disk Encryption, on the other hand, only encrypts the non-OS portion. saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Steven M. Bellovin wrote: On Tue, 16 Jan 2007 07:56:22 -0800 Steve Schear [EMAIL PROTECTED] wrote: At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. As governments widen their definitions of just who is a potential threat it makes increasing sense for citizens engaged in previous innocuous activities (especially political and financial privacy) to protect their data from being useful if seized. This goes double for those operating privacy-oriented services and their servers. As an example, when TOR servers were recently seized in German raids (with the implication that they were being used as conduits for child porn) the police knew enough to only take the hot-swap drives (which were encrypted and therefore paper weights after removal) if only for show. The main loss to the operators was repair to the cage locks. Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. The situation here in the UK is that Parliament has passed a law (RIPA) that allows the UK government to introduce key disclosure powers if it wishes to do so. So far these powers have not been bought into operation but the UK government initiated a consultation last year on whether it should take this step. We are still awaiting a decision on this. Brian Gladman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Steven M. Bellovin wrote: ... Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. And of course, there's always rubber hose cryptanalysis in jurisdictions where that's acceptable. In the UK Part III of the Regulation of Investigatory Powers Act 2000 - see http://www.opsi.gov.uk/Acts/acts2000/2023.htm - includes powers for certain classes of officials to require encrypted materials to be decrypted or to require a key to be provided. There are some safeguards, regarded by some as insufficient. The powers have not yet been brought into force, but the Government intends to bring them into force in the near future. The powers are of course wholly ineffectual where perfect forward secrecy obtains, are of limited value in relation to ephemeral encrypted communications where keys are (or may plausibly be claimed to be) changed frequently or lost, but may be of some real value in relation to encrypted storage media where key preservation, with or without key recovery mechanisms, will obviously be important to most users. Nicholas Bohm -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285(+44 1279 870285) Mobile 07715 419728(+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]