Re: Internal format of RSA private keys in microsoft keystore.

2003-10-12 Thread t . c . jones
key containers in MS are encrypted.
there is a capi m/l to be found at 
http://discuss.microsoft.com/archives/index.html
..tom
 Greetings,
 
 In the process of trying to work around some of the limitations
 of the m$-CAPI API, I'm trying to decipher the internal representation
 of private keys in the default m$ key store, in order to extract
 the private key out.
 
 The systems I'm working on are Win2K and XP, both on NTFS.
 
 Google didn't give me much. Has anyone been able to figure out
 the format of private key files? You can have a look at
 C:/Documents and Settings/username/Application Data/Microsoft/
 Crypto/RSA/*/filename
 
 I'm trying this because CryptAcquireContext() dies with the error
 NTE_BAD_KEYSET half the time. This is supposed to indicate that the
 key container doesn't exist or it could be corrupted. At this point
 I'm trying to see if the files are in good shape by reading them
 out.
 
 Having come from a Unix world, there may be something obvious I'm
 missing out, so please have patience :)
 
 Thanks,
 Sriram.
 
 
 -

 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Trusting the Tools - was Re: Open Source ...

2003-10-12 Thread Thor Lancelot Simon
On Thu, Oct 09, 2003 at 07:45:01PM -0700, Bill Frantz wrote:
 At 8:18 AM -0700 10/7/03, Rich Salz wrote:
 Are you validating the toolchain?  (See Ken Thompson's
 Turing Aware lecture on trusting trust).
 
 With KeyKOS, we used the argument that since the assembler we were using
 was written and distributed before we designed KeyKOS, it was not feasible
 to include code to subvert KeyKOS.  How do people feel about this form of
 argument?

Not too good.  If I knew what the target processor were, I think I could
arrange to do some damage to most general-purpose operating systems; they
all have to do some of the same fundamental things.

This is a bit more sophisticated than what Thompson's compiler did, but
it's the same basic idea.  There are some basic operations (in particular
on the MMU) that you can recognize regardless of their specific form and
subvert in a progammatic manner such that it's highly likely that you can
exploit the resulting weakness at a later date, I think.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-12 Thread Perry E. Metzger

[Moderator's note: Forwarded anonymously at the sender's request, so
if you reply to this, please cut my name out of it, it isn't my
message --Perry]


--
Perry, please forward anonymously.

On Friday, Oct 10, 2003, at 22:48 America/Chicago, David Honig wrote:
 At 12:08 AM 10/10/03 +0800, Ng Pheng Siong wrote:
 I believe SSL VPNs are easier than IPsec to deploy

 For the former, you give a password or two --maybe
 reuse a POP3 that your users already have-- and all your
 users get in fairly securely, and you can verify them.

Ugh.

Taking a page from the IETF playbook, I ran dsniff as a background task 
at a recent business meeting.  I captured hundreds of assorted 
passwords.  About half were POP passwords.

--

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Ease of setting up IPSEC

2003-10-12 Thread D.K. Smetters


John Gilmore wrote:

Rich $alz said:
 

it might be more useful to create a user-friendly management
interface to IPsec implementations to join the zero or so already
   

We've been making it simpler in just about every release.  Now you
basically have to download the RPM, install it, it spits out a public
key, and you install that public in your DNS in-addr records.  Then
 

Ah, but that last is the kicker.  I'm all for the whole 
DNSSEC-as-key-distribution model, but we're
a long way from it in practice.  In your example above, there are 
actually two more
common versions of step 3: 1) user who doesn't even know he has a public 
key takes it
to the guy in charge of maintaining DNS for his installation and 
attempts to convince him
that he ought to put it in the user's machine's in-addr record.  Or 2) 
home/roaming user
who has no effective DNS service for his endpoint from his ISP looks at 
his shiny new key
and wonders what to do.  (Yes, in theory you could grease the wheels 
with clever use of
dynamic DNS, but it's not currently deployed in a way that will help 
most people with this
problem.)

--Diana

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]