Bill Browning wrote:
>
> Yes I must agree on re-read I made two fatal mistakes. One should definitely
> not pass encrypted tokens to the client and one should not design an
> authentication scheme in the time takes to type out a message. Proper
> approach would have been to replace steps 4 and 5
AIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 3:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: How can I encrypt public key in handshake?
>
> > > 3. Verify that the server is who you think it is (via the public key)
> > > (client can now trust server)
> > > 4.
Date sent: Tue, 20 Mar 2001 16:22:53 -0800
Subject:Re: How can I encrypt public key in handshake?
From: "corky peavy" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Send reply to: [EMAIL PROTECTED]
Again, if
3:58 PM
To: [EMAIL PROTECTED]
Subject: Re: How can I encrypt public key in handshake?
> > 3. Verify that the server is who you think it is (via the public key)
> > (client can now trust server)
> > 4. Pass an encrypted token to the client (encrypted with client
password)
A cl
http://www-cs-students.stanford.edu/~tjw/srp/whatisit.html
http://www-cs-students.stanford.edu/~tjw/srp/project.html
http://www-cs-students.stanford.edu/~tjw/srp/download.html
__
OpenSSL Project ht
> This kind of ad hoc
> thinking by amateurs never results in a protocol worthy of deployment.
>
> The whole concept of encrypting public keys is ludicrous, and it
> doesn't matter what the answers are when you're asking the wrong
> questions.
> __
> I did not want certificates for my application, sorry.
Then use SRP.
Leave crpyto protocol design to those qualified. :)
/r$
__
OpenSSL Project http://www.openssl.org
User Support Mailin
"Kenneth R. Robinette" <[EMAIL PROTECTED]> wrote:
> From: Bill Browning <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: How can I encrypt public key in
> 1. Give your public key to anyone who want its (email what ever..)
> 2. create an SSL connection from client to server.
> 3. Verify that the server is who you think it is (via the public key)
> (client can now trust server)
> 4. Pass an encrypted token to the client (encrypted with client passwo
> > 3. Verify that the server is who you think it is (via the public key)
> > (client can now trust server)
> > 4. Pass an encrypted token to the client (encrypted with client password)
A classic, and amateur-level mistake. You should NEVER hand out
something encrypted with a user's password to
"Kenneth R. Robinette" wrote:
> okay, well try this approach:
>
> 1. Give your public key to anyone who want its (email what ever..)
> 2. create an SSL connection from client to server.
> 3. Verify that the server is who you think it is (via the public key)
> (client can now trust server)
> 4. P
Corky,
It sounds like you are trying to do SSL with password-based
authentication instead of certificate-based authentication. There is an
effort being made to standardize this approach using the SRP techniques, see
(http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-00.txt) for ideas.
Th
From: Bill Browning <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: How can I encrypt public key in handshake?
Date sent: Tue, 20 Mar 2001 15:29:05 -0800
Send reply t
It sound like what you are doing should happen like this:
1. Client (C) connects to Server (s)
2. S gets user name from C
3. S encrypts public key using password for C
4. S sends password to C
5. C saves password for use with SSL_CTX_load_verify_locations
6. C starts an ssl negotiation with S.
W
corky peavy wrote:
> Background and Rationale -- if you are interested.
>
> I need to do this because our product would not be practical with the
> headaches of certificate authorities, but we do need some user authentication,
> and defense against man-in-the-middle attacks.
See SKIP v2 w/UDH c
15 matches
Mail list logo
