Re: Encryption question

[Lars Georg Paulsen <maillist () braindead nu>]

As I have just picked this info out from something I have read, 
I don't understand the hole theory behind it all. 

A mistake by me, is calling it the himlic method... it's actually called
Diffie-Hellman key exchange method. This is only, Not a encrypting
algorithm, but to exchange a key, with out exchanging the key. 

As I understand out from what I have read, you have no two keys, that 
will be able to encrypt and decrypt the same messange. 

I found a quite good article about the method, if anyone is interrested.
http://www.netip.com/articles/keith/diffie-helman.htm

This is usally just used, for lots of traffic, because if you use to
asymetric keys the encrypting and decrypting will take quite a long
time, with this method the keys are symetric, then there will be a lot
faster transfer. 

If I understand right, this can be ablyed to any almost anything, but if
it's worth doing it on a email messange, that's the questions, the it
would be easyer to encrypt the messange with bob's public key and sign
it with alice private key.... 

As I said in the beginning, I don't understand the hole theory.. so if I
wrong, please correct me. 

regards
Lars Georg Paulsen.


On Thu, 2004-02-26 at 01:36, Hollis Johnson wrote:
> Lars. That's interesting. I always thought Priv/Pub keys had to be composed 
> of two primes. If you "combine" them (i'm thinking p*q) the result is no 
> longer prime -- although it may not be any easier to break -- Is that what 
> you meant? or did you mean applying one then the other??
>
> Thanks for any additional info :-)
>
> Hollis
>
> At 07:17 PM 2/25/2004 +0100, Lars Georg Paulsen wrote:
> > The encrypted key you have made, is not valid. Bob can't decrypt the
> > messange with his public nor with is private.
> >
> > If alice sends a message to bob, and what him to be the only one to read
> > it, she will encrypt it with his public key. And to make sure bob can
> > trust the message, and tell for sure it's from alice, she will sign the
> > message with alice private key.
> >
> > What you think of, combinding a private key and a public to make a new
> > key, is the himlich method. The way describe above takes quite long time
> > to decrypt.
> >
> > Another scenarior, is to make to new keys that are identical.
> > This you do by combinding private keys and public keys.
> > Alice makes a new key with her private and bobs public key.
> > Bobs makes a new key with his private and alices public key.
> > The two new keys are now identical, can not be produced by any
> > outsiders.
> >
> > Hopes this answer a bit of your question.
> >
> > regards
> > Lars Georg Paulsen.
> >
> > On Tue, 2004-02-24 at 20:01, Preston, Tony wrote:
> > > Tony Preston
> > > Systems Engineer, AS&T Inc.
> > > Division of L3 Corporation
> > > (609) 485-0205 x 181
> > >
> > > I have what is a rather basic question...  I probably am missing something
> > > so I thought I would ask here.
> > >
> > > Alice and Bob both have a public and private key.
> > >
> > > Alice encrypts her email to Bob using his public key.  Sends the email and
> > > Bob decrypts it using his keys..
> > >
> > > Since both Bob and Alice's public keys are known, Why can't I take Alice's
> > > public key and create a key pair using any other private key.  Now, I fake
> > > an electronic signature from Alice using the pair I created and send a 
> > bogus
> > > encrypted message to Bob with my "fake" Alice signature.  Bob checks the
> > > signature by using the public key and it is valid.   Bob assumes the 
> > message
> > > is from Alice...
> > >
> > > What prevents me from spoofing someone's electronic signature this way?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------------
> > ----------------------------------------------------------------------------
> > >
> >
> >
> > ---------------------------------------------------------------------------
> > ----------------------------------------------------------------------------


---------------------------------------------------------------------------
----------------------------------------------------------------------------