Re: decrypt files after lost pub/priv keys - possible?

From: Drew Cooper [MSFT] (dcoop_at_online.microsoft.com)
Date: 01/01/04

  • Next message: \(JD\): "Re: Minimum rights to Operating System Volume"
    Date: Wed, 31 Dec 2003 18:18:15 -0800
    
    

    There is no back door for feds. We couldn't have gotten Common Criteria
    EAP4 if there were. The NSA wouldn't let US government employees use EFS if
    there were a back door. We've even had 3rd party reviews of our EFS code -
    I'll repeat: NO BACK DOORS.

    Lucky for you, Win2k used DES for its symmetric encryption. Maybe you were
    even using the "for export" version of Win2k - it had weak keys because of
    government regulations about exporting crypto at the time. It would be
    possible to crack each file individually in this case. It would still take
    a lot of number-crunching and it would take a very long time on your single
    machine.
    Had you been running XP, the symmetric keys would have been AES 256 -
    nobody's cracked that yet.

    -- 
    Drew Cooper [MSFT]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    "Generally Crazy" <generalcrazy@verizon.net> wrote in message
    news:lAGIb.34352$E17.27396@nwrddc02.gnilink.net...
    >
    > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    > news:JmEIb.711404$Fm2.616570@attbi_s04...
    > > Drive C that contained your operating system and user profiles also
    > contained the EFS
    > > private keys needed to decrypt those files. The EFS private keys are
    > stored in the
    > > users and recovery agent's [local administrator by fefault] profiles and
    > unless you
    > > have copies of those profiles in a backup from a time after those file
    > were
    > > encrypted, then those files are lost.  --- Steve
    >
    > pardon the sarcastic humor, it's a NYC thing --- *G*
    >
    > Steve - no, that's NOT a good answer ... hehehehehehe.
    > www.beginningtoseethelight.org  - great resource.  I believe I found
    > workable keys <or the remnants of possibilities> as the "user" directory
    > <documents&settings> has some older keys.  I've already attempted to take
    > the system OFFLINE from the network and force it to try it's ADMIN keys -
    of
    > little success, so it's back to the original plan.
    >
    > From all that I know as I've done coding for a number of years prior to
    the
    > windows explosion, export laws require master keys be provided to the FEDS
    > to qualify for export.  Just so if they want to read something, they can
    > w/out the bull.  Win2K EFS is exportable under US law.  How the FEDS get
    the
    > keys is from those doing the encryption.  Hence Microsoft DOES know how 2
    > fix this as they provided the MASTER keys.  It's federal law - paranoid
    > lawyers, I'd imagine ... LOL.
    >
    > In my isolated case I have discovered several base "KEYS" from the MFT by
    > doing a simple NTBACKUP.  My only problem is order of alignment.  Once
    this
    > alignment is established, the brute force approach becomes simplified,
    > although time consuming.  We do have time ... as these are three 25K excel
    > files and one 250M outlook.pst file.  So allowing a running progie on a
    > single P4 system coded in assembler will allow it to run at max speed, and
    > with a little luck, the "known test key patterns" generated against the
    EFS
    > service will HIT the necessary thumbprint --- yes, the data is that
    > important to us.  At present, this project is going to require some
    EXTERNAL
    > help from the makers, so 2 speak.  Others interested with input for this
    > project email me.
    >
    > I don't do this for a living - so it is going to take some time - visual
    > anything & dotted net just don't work for me as it now presents a
    definitive
    > learning curve requirement.  Although I am versed in several forms of DES,
    > this undertaking is requiring help and time.  I have succeeded before
    > <another story> ... today is just another day to succeed again.  Although
    I
    > should publish my findings, it has not come to light unless I'm pressed to
    > do so by those who also have suffered the same loss.  My thought is this
    ...
    > admission to KNOWING how to do it by those empowered to fix what's broken
    > AND should be turned into a reliable repair service, of which I'm sure
    fees
    > would be exurbanite.  Back to the "Do It Yourself" shelf ... LOL :)
    >
    > Anyone else following this thread - BEWARE - a bit of a note on those
    > instruments which claim to be able to decrypt files - their algorithms
    they
    > say work - cannot work if you've done what I've done.  They match up users
    > to what you get from "efsinfo.exe" output.  This does NOT guarantee the
    file
    > is decryptable, as I have learned.  There is no SELF TEST performed on the
    > output to assure successful recovery.  Win2K (from what I can tell) does
    > establish a self-test good/bad in it's decryption process (ie.  it knows
    if
    > it's right or wrong) - built in function so Win2K knows it can ACCESS the
    > data, hence: ACCESSABLE OR INACCESSIBLE.  So if you cannot gain the first
    > 512 bytes of the file header to match up to a known file system, save your
    > bucks because it won't work.  Unless the aftermarket tools use the same
    > entry/exits that Win2K uses, understands what is sent back, their success
    is
    > varied.
    >
    > As Steve has said ... if you blow up your Documents and Settings folders -
    > it is almost a worthless cause to try recovering the data.
    >
    > I'll keep you good folks posted as to my results ... nothing is ever
    > impossible until you try.  Encryption is written in code, any code can be
    > broken effectively - time is the requirement to successful decryption of
    any
    > encryption (self-encapsulated encryption only).  So as we blowfish and sha
    > it, des'in it a bit with a bit of chump code, generators keep the power
    > flowing ... <rhetoric bull, I know>
    >
    >
    >
    >
    

  • Next message: \(JD\): "Re: Minimum rights to Operating System Volume"

    Relevant Pages

    • RE: Protecting sensitive files on a Windows file server
      ... Protecting sensitive files on a Windows file server ... Recovery keys aren't a problem. ... I don't care what your encryption program ... EFS only works on NTFS partitions. ...
      (Security-Basics)
    • Re: ciphered files
      ... > If you are not in a domin, and you did not export your encryption keys ... > My view on EFS: ... as well not having created a Recovery Agent (with backup of the ...
      (microsoft.public.windowsxp.security_admin)
    • RE: Encryption on Laptops?
      ... > This type of encryption is strong enough so that it can not be defeated ... over 14,000 computer users trying out various keys finally deciphered the ... which allow the admin password to be easier changed...bypassing EFS ... user account passwords on the box in question, log in as the user, and voila, I have the ...
      (Security-Basics)
    • Re: decrypting files from XP - tough question
      ... EFS uses a hybrid asymmetric/symmetric encryption scheme. ... It is to those keys which EFS encrypted the ... That session key can only be retrieved by those same certificates. ...
      (microsoft.public.security)
    • Re: Former Install Encryption Cracking
      ... > and then did a re-install the keys would be lost. ... > I have the feeling I may have done a second install and ... > I have the export version of Win2K, ie non-US to the best of my knowlegde. ... > encryption. ...
      (microsoft.public.win2000.security)