[FDE] FDE Digest, Vol 20, Issue 3
Albert
caruabertu at gmail.com
Tue May 6 03:32:44 MDT 2008
in my experience, enabling fips mode blocks web access to websites using
ssl2
2008/5/3 <fde-request at www.xml-dev.com>:
> Send FDE mailing list submissions to
> fde at www.xml-dev.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.xml-dev.com/mailman/listinfo/fde
> or, via email, send a message with subject or body 'help' to
> fde-request at www.xml-dev.com
>
> You can reach the person managing the list at
> fde-owner at www.xml-dev.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FDE digest..."
>
>
> Today's Topics:
>
> 1. Re: FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus, Utimaco, Poinsect, MobileArmor) (Ali, Saqib)
> 2. Re: Fujistu announces 2,5 inch SATA HDD with FDE
> (Garrett M. Groff)
> 3. FIPS vs. non-FIPS modes (Robert Jueneman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 May 2008 10:43:43 -0700
> From: "Ali, Saqib" <docbook.xml at gmail.com>
> Subject: Re: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus, Utimaco, Poinsect, MobileArmor)
> To: fde at www.xml-dev.com
> Message-ID:
> <addede3b0805021043v2c9a1a77te264edd656485fcf at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Eric,
>
> Thanks for the clarification.
>
> Elsewhere, I learned that a encryption production (hardware or
> software) is restricted to single-user mode when operating in FIPS
> mode. That is, there can be only ONE user account that can perform the
> decryption. Administrative / Helpdesk or other recovery accounts are
> not possible in FIPS mode. Is this correct?
>
> Thanks
>
> On Thu, May 1, 2008 at 1:47 PM, <eric.lengvenis at wellsfargo.com> wrote:
> > Just because they use FIPS approved or validated algorithms doesn't mean
> > they are FIPS validated modules. There is much more than just correctly
> > implementing the algorithm to FIPS mode. Some that come to mind are
> > zeroizing the key store if a tamper is suspected, or if account
> lock-out
> > numbers are reached, etc. Depending on the level of validation physical
> > keys (dongles, USB, smart cards) are needed to enable the device.
> >
> > Most encryption products have the option of running in FIPS mode or
> > non-FIPS mode. Generally FIPS modes are far more restrictive and slower
> > than necessary for typical non-classified usage. But, if you are
> storing
> > the root of your PKI on the disk, it would probably be considered a
> best
> > practice.
> >
> > Eric Lengvenis
> > Security Architecture
> >
> > This message may contain confidential and/or privileged information. If
> > you are not the addressee or authorized to receive this for the
> > addressee, you must not use, copy, disclose, or take any action based
> on
> > this message or any information herein. If you have received this
> > message in error, please advise the sender immediately by reply e-mail
> > and delete this message. Thank you for your cooperation.
> >
> >
> >
> > -----Original Message-----
> > From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
> > On Behalf Of Ali, Saqib
> > Sent: Thursday, May 01, 2008 2:55 PM
> > To: fde
> > Subject: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone,
> > Spyrus,Utimaco, Poinsect, MobileArmor)
> >
> > I was looking at the FIPS 140-2 Certificate[1] for the Stonewood's
> > Flagstone product, and it has a clause that says "(When operated in
> > FIPS mode)". What does this clause mean?
> >
> > I was under the impression that since Flagstone only implement FIPS
> > validated encryption algorithms (128-bit AES CBC/ECB and ANSI X9.31
> > AES 128 bit RNG) there would no non-FIPS mode.
> >
> > I later found out that, Spyrus, Utimaco, Poinsect, MobileArmor have
> > the same clause.
> >
> >
> > 1.
> >
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pd
> > f
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
> >
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
>
>
>
> --
> Saqib Ali, CISSP, ISSAP
> http://www.full-disk-encryption.net
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 May 2008 17:13:14 -0400
> From: "Garrett M. Groff" <groffg at gmgdesign.com>
> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
> To: <fde at www.xml-dev.com>
> Message-ID: <6A5BC307E2BE46688BD7DD6B9B7FDEC0 at Komputer01>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> I've seen that operation in the group policy as well. It seems to be set
> to
> off by default. Any know what the implications are of turning it on? What
> exactly does it do?
>
> Thanks.
>
> - G
>
> ----- Original Message -----
> From: "Duane Dyar" <duane.dyar at pkware.com>
> To: <fde at www.xml-dev.com>
> Sent: Thursday, May 01, 2008 5:16 PM
> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
>
>
> > You can modify the Windows operating system to use a FIPS Mode Operation
> > by opening the MMC console and changing the local security policy. This
> > will enable either a FIPS 140-1 or 140-2 validation mode depend on the
> > OS (Vista or something older).
> >
> > Duane
> >
> >
> > -----Original Message-----
> > From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
> > On Behalf Of Hubbert Smith
> > Sent: Wednesday, April 30, 2008 11:21 PM
> > To: fde at www.xml-dev.com
> > Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
> >
> > Hi all,
> > great thread, by the way. Pls keep it coming.
> > I'm not an expert, but I have read the spec.
> > FIPS does define "cryptography modules". FIPS does not require encrypted
> > drives http://en.wikipedia.org/wiki/FIPS_140
> > http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
> > so, I did not read anything that says that the "cryptography module"
> > _must_ be a disk drive and I did not read anything that says the
> > cryptography module _cannot_ be a laptop.
> >
> >
> > I guess what I'm attempting to sort out ...
> > it appears FIPS compliance for laptops can be attained with O/S level
> > encryption, today. (am I wrong?) so are we attempting to solve a problem
> > of FIPS compliance for _all_ laptops or are we attempting to improve
> > performance for _some_ FIPS compliant laptops?
> >
> >
> > cheers
> > Hubbert
> >
> >
> >
> >
> >
> >
> > ----- Original Message ----
> > From: Scott S <scott at u.washington.edu>
> > To: fde at www.xml-dev.com
> > Sent: Wednesday, April 30, 2008 6:52:51 PM
> > Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
> >
> > This might be possible for desktop computers where space is not a
> > constraint. However, in laptops (which are the computers that are most
> > vulnerable to theft and lost) where form factors are so specific and
> > compact, it would be problemmatic, especially to make it generic enough
> > to fit all brands.
> >
> > There is also the manufacturing aspect of it. Integration of components
> > brings down the overall cost of production. Once components are
> > separated out, it will be another product line with its own margins and
> > price points.
> >
> > Scott
> >
> > On Tue, 29 Apr 2008, Simson Garfinkel wrote:
> >
> >> Would it not be possible to certify an encryption module that fits
> >> between the hard drive and the host computer? This would allow you to
> >> use off-the-shelf drives while maintaining certification...
> >>
> >>
> >> On Apr 29, 2008, at 8:40 PM, Ali, Saqib wrote:
> >>
> >>> This is precisly the issue with obtaining FIPS certification for hard
> >
> >>> drives.
> >>>
> >>> Hard Drive design and development moves at a extremely rapid pace.
> >>> Time to market and innovation is key in the disk drive business.
> >>> Manufacturers like Hitachi, Fujitsu and Seagate have to release newer
> >
> >>> hardware every month to keep ahead of the competition. Whereas
> >>> obtaining FIPs certification is a slow and time consuming process. By
> >
> >>> the time these manufacturers obtain FIPS for a certain hardware, that
> >
> >>> hardware is already few generations old.
> >>>
> >> _______________________________________________
> >> FDE mailing list
> >> FDE at www.xml-dev.com
> >> http://www.xml-dev.com/mailman/listinfo/fde
> >>
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
> >
> >
> >
> >
> >
> >
> > ________________________________________________________________________
> > ____________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 May 2008 15:32:55 -0700
> From: "Robert Jueneman" <rjueneman at spyrus.com>
> Subject: [FDE] FIPS vs. non-FIPS modes
> To: <fde at www.xml-dev.com>
> Message-ID:
> <CFFCB4E687F4434CBAACED12D890DEB4A041F6 at cleopatra.spyrus.com>
> Content-Type: text/plain; charset="us-ascii"
>
> There are lots of reasons why a vendor might choose to offer a non-FIPS
> mode. There are even some (but perhaps fewer) good reasons why a
> security-conscious enterprise would or should choose to make use of such
> modes.
>
> The first non-FIPS case that comes to mind involves the use of a
> non-FIPS algorithm or mode. MD5, single-DES, CAST, etc., are all
> non-FIPS approved algorithms, but may have some utility for backwards
> compatibility.
>
> Even if all of the encryption algorithms are FIPS -approved, that
> particular mode of operation might not be approved, or might not have
> been at the time the module was certified. For example, the use of RSA
> for key exchange is not FIPS approved, although it is approved for
> digital signatures. HMAC, AES Galois Counter Mode, and the various
> "tweak" ciphers now being proposed many or many not fall into that gray
> area, although most can be composed as a series of ECB operations with
> pre- and post-processing.
>
> Other areas of concern may be the time required to complete all of the
> power-on self tests, which FIPS 140-2 requires be completed before ANY
> cryptographic operations are performed, vs. the draft FIPS 140-3
> specification which only requires that they be completed before that
> particular usage is first performed. So if you implement some
> relatively expensive but optional and infrequently used function (e.g.,
> ECDSA), you may cause a 10 to 15 second delay in smart card logon. A
> vendor might very reasonably choose to offer a non-FIPS mode to avoid
> the unnecessary overhead in that case.
>
> Finally, some functions may be required for FIPS Level 3, such as a
> secure channel for all PIN entry and key exchange, which may be
> difficult or expensive to do on all platforms. Rather than downgrade
> the product's rating to level 2, the vendor may choose to offer a
> non-FIPS mode that might be even worse, while still claiming level 3
> (although no one will use the product in that fashion.)
>
> As usual, the devil is in the details, and reading the Security Policy
> carefully before purchasing the product is essential to an informed
> decision.
>
> Bob
>
>
> Robert R. Jueneman
> Chief Scientist
> SPYRUS, Inc.
> www.spyrus.com
> 1860 Hartog Drive
> San Jose, CA 95131
> 408-392-4307 (Office)
> 408-422-2378 (Cell)
> Please note the new address and office telephone number.
>
> See http://www.spyrus.com/productdemo.asp for a brief video regarding
> the SPYRUS Hydra Privacy Card.
> This message and any attached documents may contain SPYRUS confidential
> information and may be subject to privilege or exempt from disclosure
> under applicable law. These materials are intended only for the use of
> the intended recipient. If you are not the intended recipient of this
> electronic message, you are hereby notified that any use of this message
> is strictly prohibited. Delivery of this message to any person other
> than the intended recipient shall not constitute any waiver of any
> privilege. If you have received this message in error, please delete
> this message from your system and notify the sender immediately. Thank
> you."
>
>
> -----Original Message-----
> From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
> On Behalf Of fde-request at www.xml-dev.com
> Sent: Friday, May 02, 2008 11:00 AM
> To: fde at www.xml-dev.com
> Subject: FDE Digest, Vol 20, Issue 2
>
> Send FDE mailing list submissions to
> fde at www.xml-dev.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.xml-dev.com/mailman/listinfo/fde
> or, via email, send a message with subject or body 'help' to
> fde-request at www.xml-dev.com
>
> You can reach the person managing the list at
> fde-owner at www.xml-dev.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FDE digest..."
>
>
> Today's Topics:
>
> 1. FIPS 140-2: When operated in FIPS mode? (Flagstone, Spyrus,
> Utimaco, Poinsect, MobileArmor) (Ali, Saqib)
> 2. Re: FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus, Utimaco, Poinsect, MobileArmor)
> (eric.lengvenis at wellsfargo.com)
> 3. Re: Fujistu announces 2,5 inch SATA HDD with FDE (Duane Dyar)
> 4. Re: Microsoft COFEE, - Alternatively a True Brute Force
> Attack on RFID (Allen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 May 2008 12:54:40 -0700
> From: "Ali, Saqib" <docbook.xml at gmail.com>
> Subject: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus, Utimaco, Poinsect, MobileArmor)
> To: fde <FDE at www.xml-dev.com>
> Message-ID:
> <addede3b0805011254y3ec2f3f7rb4a588dba7a09a99 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I was looking at the FIPS 140-2 Certificate[1] for the Stonewood's
> Flagstone product, and it has a clause that says "(When operated in
> FIPS mode)". What does this clause mean?
>
> I was under the impression that since Flagstone only implement FIPS
> validated encryption algorithms (128-bit AES CBC/ECB and ANSI X9.31
> AES 128 bit RNG) there would no non-FIPS mode.
>
> I later found out that, Spyrus, Utimaco, Poinsect, MobileArmor have
> the same clause.
>
>
> 1.
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pd
> f<http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pdf>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 1 May 2008 15:47:25 -0500
> From: <eric.lengvenis at wellsfargo.com>
> Subject: Re: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus, Utimaco, Poinsect, MobileArmor)
> To: <fde at www.xml-dev.com>
> Message-ID:
>
> <54A57803659B704A9A46A9D95D143597569B7A at msgswbmnmsp15.wellsfargo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Just because they use FIPS approved or validated algorithms doesn't mean
> they are FIPS validated modules. There is much more than just correctly
> implementing the algorithm to FIPS mode. Some that come to mind are
> zeroizing the key store if a tamper is suspected, or if account lock-out
> numbers are reached, etc. Depending on the level of validation physical
> keys (dongles, USB, smart cards) are needed to enable the device.
>
> Most encryption products have the option of running in FIPS mode or
> non-FIPS mode. Generally FIPS modes are far more restrictive and slower
> than necessary for typical non-classified usage. But, if you are storing
> the root of your PKI on the disk, it would probably be considered a best
> practice.
>
> Eric Lengvenis
> Security Architecture
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based on
> this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
>
> -----Original Message-----
> From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
> On Behalf Of Ali, Saqib
> Sent: Thursday, May 01, 2008 2:55 PM
> To: fde
> Subject: [FDE] FIPS 140-2: When operated in FIPS mode? (Flagstone,
> Spyrus,Utimaco, Poinsect, MobileArmor)
>
> I was looking at the FIPS 140-2 Certificate[1] for the Stonewood's
> Flagstone product, and it has a clause that says "(When operated in
> FIPS mode)". What does this clause mean?
>
> I was under the impression that since Flagstone only implement FIPS
> validated encryption algorithms (128-bit AES CBC/ECB and ANSI X9.31
> AES 128 bit RNG) there would no non-FIPS mode.
>
> I later found out that, Spyrus, Utimaco, Poinsect, MobileArmor have
> the same clause.
>
>
> 1.
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pd
> f<http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt779.pdf>
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 1 May 2008 16:16:18 -0500
> From: "Duane Dyar" <duane.dyar at pkware.com>
> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
> To: <fde at www.xml-dev.com>
> Message-ID:
>
> <266A8E49172277419236FC2411ED610E01D2B21E at mkesrv-exch01.pkware.com>
> Content-Type: text/plain; charset="us-ascii"
>
> You can modify the Windows operating system to use a FIPS Mode Operation
> by opening the MMC console and changing the local security policy. This
> will enable either a FIPS 140-1 or 140-2 validation mode depend on the
> OS (Vista or something older).
>
> Duane
>
>
> -----Original Message-----
> From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
> On Behalf Of Hubbert Smith
> Sent: Wednesday, April 30, 2008 11:21 PM
> To: fde at www.xml-dev.com
> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
>
> Hi all,
> great thread, by the way. Pls keep it coming.
> I'm not an expert, but I have read the spec.
> FIPS does define "cryptography modules". FIPS does not require encrypted
> drives http://en.wikipedia.org/wiki/FIPS_140
> http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
> so, I did not read anything that says that the "cryptography module"
> _must_ be a disk drive and I did not read anything that says the
> cryptography module _cannot_ be a laptop.
>
>
> I guess what I'm attempting to sort out ...
> it appears FIPS compliance for laptops can be attained with O/S level
> encryption, today. (am I wrong?) so are we attempting to solve a problem
> of FIPS compliance for _all_ laptops or are we attempting to improve
> performance for _some_ FIPS compliant laptops?
>
>
> cheers
> Hubbert
>
>
>
>
>
>
> ----- Original Message ----
> From: Scott S <scott at u.washington.edu>
> To: fde at www.xml-dev.com
> Sent: Wednesday, April 30, 2008 6:52:51 PM
> Subject: Re: [FDE] Fujistu announces 2,5 inch SATA HDD with FDE
>
> This might be possible for desktop computers where space is not a
> constraint. However, in laptops (which are the computers that are most
> vulnerable to theft and lost) where form factors are so specific and
> compact, it would be problemmatic, especially to make it generic enough
> to fit all brands.
>
> There is also the manufacturing aspect of it. Integration of components
> brings down the overall cost of production. Once components are
> separated out, it will be another product line with its own margins and
> price points.
>
> Scott
>
> On Tue, 29 Apr 2008, Simson Garfinkel wrote:
>
> > Would it not be possible to certify an encryption module that fits
> > between the hard drive and the host computer? This would allow you to
> > use off-the-shelf drives while maintaining certification...
> >
> >
> > On Apr 29, 2008, at 8:40 PM, Ali, Saqib wrote:
> >
> >> This is precisly the issue with obtaining FIPS certification for hard
>
> >> drives.
> >>
> >> Hard Drive design and development moves at a extremely rapid pace.
> >> Time to market and innovation is key in the disk drive business.
> >> Manufacturers like Hitachi, Fujitsu and Seagate have to release newer
>
> >> hardware every month to keep ahead of the competition. Whereas
> >> obtaining FIPs certification is a slow and time consuming process. By
>
> >> the time these manufacturers obtain FIPS for a certain hardware, that
>
> >> hardware is already few generations old.
> >>
> > _______________________________________________
> > FDE mailing list
> > FDE at www.xml-dev.com
> > http://www.xml-dev.com/mailman/listinfo/fde
> >
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
>
>
>
>
>
> ________________________________________________________________________
> ____________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 01 May 2008 17:43:38 -0700
> From: Allen <netsecurity at sound-by-design.com>
> Subject: Re: [FDE] Microsoft COFEE, - Alternatively a True Brute Force
> Attack on RFID
> To: Cryptography <cryptography at metzdowd.com>
> Cc: ekmi <ekmi at lists.oasis-open.org>, fde at www.xml-dev.com
> Message-ID: <481A63BA.9070907 at sound-by-design.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Funny you should be talking about this just as EFF references an
> article on BoingBoing where the "brute force attack" of choice
> against RFID is a hammer. ;->
>
> As to the Microsoft COFEE brute forcing passwords using tools on
> a USB key, I'd guess there is a lot of FUD involved. I don't
> believe one could shoehorn a Rainbow Table of a reasonable size
> into any current USB key, so one would be reduced to either
> LANMAN attacks or wiping the SAM file of the computer itself
> running ISOLinux. This would destroy the validity of the evidence
> for courtroom evidence purposes as not being able to prove that
> the data was not tampered with.
>
> A true brute force attack against 10 characters and a 66 (U/L
> alpha and numeric plus 4 non-alphanumeric) or so key space at
> 15X10^6 keys/second - average decent dual core rate - would take
> about a year assuming that you had a terabyte of storage on a
> portable USB drive with a pre-computed table that might
> conceivably take as little as 3+ years to pre-compute at 15x10^9
> keys/second. Add one more character to the password length or
> increase the key space and pre-computing the Rainbow Table is a
> couple of hundred years or more.
>
> So then what are you left with? You can map the files without the
> password if the disk is not encrypted and get a lot of
> information that way, but forget this if the drive(s) or the
> files are encrypted.
>
> FCCU Linux has almost all the tools one needs and it will fit and
> run from a USB key, so who needs Microsoft?
>
> The takeaway is encrypt the drive/files and use a password of at
> least 12 characters and a key space of U/L alpha, numeric and the
> common other keys and your computer is secure enough for the
> moment. Tomorrow? Who knows.
>
> Allen
>
> BTW, Thanks to "Rainbow Chain Hash Cracking Calculator" by Tom
> Sullivan for the figures on key strength. If you can't find a
> copy of this, I'll send you one.
>
> Adam Shostack wrote:
> > My understanding, based mostly on what I've read in the press, is that
> > COFFEE is a set of scripts that run existing tools, making it easier
> > for law enforcement to do things which are already known to be
> > possible. Note the words "executing 150 seperate commands," which, I
> > think, would be odd if this was something other than scripts, but
> > appear in a lot of the news stories.
> >
> > For example, I believe that there are several freely available
> > password cracking tools and some commercial ones. For example, you can
> > order John the Ripper to decrypt a system password on some operating
> > systems. I have no idea if a password cracker is included.
> >
> > Speaking for me.
> >
> > Adam
> >
> > On Wed, Apr 30, 2008 at 03:36:28PM -0400, Arshad Noor wrote:
> > | It can be "ordered to decrypt system passwords"??? So, I wonder
> > | what attackers can do with this...
> > |
> > | Arshad Noor
> > | StrongAuth, Inc.
> > |
> > | "Microsoft revealed its development of a digital forensic analysis
> toolkit at a security conference yesterday as part of a wider discussion
> of how technology can be used to fight crime. The Computer Online
> Forensic Evidence Extractor, or COFEE for short, is a USB thumb drive
> that contains software capable of executing approximately 150 separate
> commands. Once plugged in, COFEE can be ordered to decrypt system
> passwords, display a history of internet activity, and search the system
> for evidence...."
> > |
> > |
> http://arstechnica.com/news.ars/post/20080429-new-microsoft-law-enforcem
> ent-tool-bypasses-pc-security.html<http://arstechnica.com/news.ars/post/20080429-new-microsoft-law-enforcement-tool-bypasses-pc-security.html>
> > |
> > |
> ---------------------------------------------------------------------
> > | The Cryptography Mailing List
> > | Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at metzdowd.com
> >
> > ---------------------------------------------------------------------
> > The Cryptography Mailing List
> > Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at metzdowd.com
> >
>
>
> ------------------------------
>
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
> End of FDE Digest, Vol 20, Issue 2
> **********************************
>
>
>
> ------------------------------
>
> _______________________________________________
> FDE mailing list
> FDE at www.xml-dev.com
> http://www.xml-dev.com/mailman/listinfo/fde
>
>
> End of FDE Digest, Vol 20, Issue 3
> **********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.xml-dev.com/pipermail/fde/attachments/20080506/3ea10c84/attachment-0001.html
More information about the FDE
mailing list