What I still don't get - Why don't you want the symmetrical key to be sent in an encrypted form? Sending a random AES key RSA encrypted over the net is no way less secure than using DH to generate it. Both systems are broken the moment the private key leaks. DH has a secret and a public number as well, it's just that classic DH generates them randomly whereas El Gamal keeps them. If you sign the random numbers it's just overhead since you have to keep another keypair for signing. So just encrypt a random symmetric key and send it asymmetrically encrypted, there is no security gain doing it some other weird way.
smu johnson wrote: > Yep, I have a lot to learn about all this stuff... ;) > > I suppose I should stop using definitions I read off the internet, > because they are too vague. Instead of me throwing around the hybrid > word around, I should just simply say, that I do not want the > symmetric cipher key ever sent across the transmission. Essentially, > my main goal is to still implement the STS thing, which I don't think > Crypto++ does... or at least I have to use some of the API to do it > myself. My brother and I looked through some of the docs, and we are > arriving at this conclusion. > > Best to start cracking open my textbook so I can beef up on my crypto > knowledge, and maybe learn exactly what ElGamal does, as you suggested. > > Thank you for responding > > On Tue, Jul 13, 2010 at 6:22 PM, Elias Önal <[email protected] > <mailto:[email protected]>> wrote: > > Using DH to get a shared secret and then go on using symmetrical IS > hybrid encryption. I don't get your signing part - signing usually is > encryption using the public key, whereas verification is decryption > using the public key. (For RSA - It's different for other > algorithms) So > you have to rely on secret private keys here as well since asymmetric > signing schemes need them. So instead of generating random DH > proposals > and sign them using a private key you probably better use El Gamal in > the first place. El Gamal basically is DH without the > generate-new-random-numbers part. This would allow you to get rid > of the > whole signing. > > smu johnson wrote: > > Thanks for replying. > > > > On Tue, Jul 13, 2010 at 2:18 PM, Elias Önal > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > Have you heard of OTR? > > http://en.wikipedia.org/wiki/Off-the-Record_Messaging > > > > > > I have, and I have found it very tedious and annoying to use. My > > friend and I tried it a few times and couldn't stand how > annoying it. > > Simp makes it far more seamless and far less of a headache to > use. I > > can't count how many times I got complete jibberish from my > friend and > > vice-versa because OTR just wasn't doing any handshaking properly. > > Not only that, you must request a conversation to be OTR > everytime you > > want it secret. Simp does all your conversations encrypted if it > > detects your friend is using Simp too. And that is a heck of a lot > > easier as you don't have to keep pestering your friends to > initiate an > > OTR conversation. > > > > About 3DES-128, at least they're not using 3ROT-13 I guess ;D > > > > > > Indeed. ;) > > > > > > If you want to make it free (as in GPL) - why not make it public > > domain? > > > > > > It is going to be a proxy, instead of an IM plugin type thing. That > > is how Simp does it, so it is external to any IM program. As > for GPL, > > I'm leaning towards that way in case someone rips off my hard work. > > > > > > what I don't get, you state you want to use symmetric and > asymmetric > > encryption to securely exchange the key (which actually is > hybrid > > encryption) > > > > > > Last I checked, the hybrid method encrypts the proposed symmetric > > secret key using the asymmetric cipher. Meaning that if the private > > key needed to see what the symmetric key was compromised, then there > > goes the message that was previously sent. In no circumstance do I > > want the key sent, encrypted or not, to the other person. I would > > like both parties to arrive at it on their own, as in a DH exchange. > > > > > > but then you say hybrid encryption ain't an option cause of > > the public/private keypair which have to be kept secret. In > addition I > > don't see how you think you can defeat mitm. > > > > > > I believe STS is the term that will allow you to do this. A bit > of it > > is explained here: > > http://en.wikipedia.org/wiki/Station-to-Station_protocol > > > > I think the idea is that it is like a regular DH exchange, where the > > key is never sent, except that the arrangements needed to do so are > > digitally signed, defeating the MITM provided the public key > > fingerprints are valid. Please correct me if I'm wrong, as I'm > a bit > > of a novice to this whole stuff. > > > > Thanks for taking an interesting in my post! > > > > > -- > smu johnson <[email protected] <mailto:[email protected]>> > -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
