Jump to content


Photo
- - - - -

Crypto Help


  • Please log in to reply
14 replies to this topic

#1 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 20 August 2003 - 09:59 PM

I was just reading an article about crypto and I was a little confused. The article said that the message is encrypted with symetric encryption(DES), while the symetric key is encrypted asymetrically with RSA. That makes sense, because it preserves the integrity of the DES key.
1. Does that imply that each user has it's own public and private key built into the browser?
2. And if so... who put them there?(insert diabolical background music here)
3. And can you see the key exchange when packet sniffing?
Any help would be appreciated.

#2 v90

v90

    Mack Daddy 31337

  • Members
  • 200 posts

Posted 20 August 2003 - 11:44 PM

I don't believe browsers can do DES and RSA (is SSL assymetric?) But yes a packet dump would show the transmission, it may be decrypted or encrypted with another key going out though, want to show us the URL?

#3 ntheory

ntheory

    data pillager

  • Agents of the Revolution
  • 1,757 posts

Posted 20 August 2003 - 11:54 PM

Intuitively I'd think that your browser generates a private key during the installation but it could probably also do it when you access your first SSL site.

You'll be able to sniff the key exchange but it won't get you much.

SSH does this type of 3DES/RSA mix but I'm not sure how it decides what to use for the 3DES key. Maybe it just generates a random number each time. I had never really thought about it until now though... interesting. That also means that even if you steal someone's secret key that you'd only be able to intercept an SSH session if you caught the initial key exchange at the start of the session. Damn, I need to do some more reading on this. Thanks for the info/inspiration!

#4 v90

v90

    Mack Daddy 31337

  • Members
  • 200 posts

Posted 20 August 2003 - 11:58 PM

Actually if you start snifffing at the START of the packet exchange of an SSL or SSHv1 (not v2) connection you can decrypt all of it :blink:

#5 ntheory

ntheory

    data pillager

  • Agents of the Revolution
  • 1,757 posts

Posted 21 August 2003 - 12:06 AM

How is that? Any links to illustrate it? I really don't know much/anything about the SSL/SSHv1 key exchange mechanism, just basically guessing how it works right now.

#6 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 21 August 2003 - 10:40 AM

I don't believe browsers can do DES and RSA (is SSL assymetric?) But yes a packet dump would show the transmission, it may be decrypted or encrypted with another key going out though, want to show us the URL?


I don't have any specific URL, put I recently sniffed a session with PayPal when I was getting my account activated. That was SSL, and it was encrypted. That got me reading a crypto article, and they described the DES/RSA mechanism. I don't know how accurate the info was, but it seemed like a pretty good way of encrypting info. They also mentioned that the destination sites public key is transmitted with the digital signature that they have verified by like Verisign. This public key is what the user uses to encrypt their message. The user still has to transmit it's public key for the destination site to encrypt messages back to the user. Purely speculation, but I would bet that the user encrypts their public key with the destination sites public key from the certificate. That would be why all of the packets I sniffed were encrypted. This must be the V2 you mentioned??
I need to learn some more about this stuff, thanks for the info.

#7 v90

v90

    Mack Daddy 31337

  • Members
  • 200 posts

Posted 21 August 2003 - 11:08 AM

How is that?  Any links to illustrate it?  I really don't know much/anything about the SSL/SSHv1 key exchange mechanism, just basically guessing how it works right now.

I'll try to find some links but I can't come up with anything right now... Check out ettercap...
http://216.239.57.10...&hl=en&ie=UTF-8
http://www.shmoo.com...9/msg01044.html
http://depts.washing...ctures/ssh.html

l0cache, yes, online the only encryption I believe you can use is SSL (HTTPS://), v2 was just another way that SSH worked I'm not sure if it's the same as what you're thinking, DES/RSA are good ideas, DES though by now is old and can be broken quite quickly by new computers built just for cracking DES... RSA depending on the key length (of course) is much more secure...

#8 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 21 August 2003 - 11:20 AM

Thanks Vlad, that first link answered my original question. It looks like there are no private/public keys in the browser, and each time you want to talk on SSL there are session keys based on random data passed to the client and destination. That's way better(depending on your hat) because each time you use SSL a new set of session keys is made.

EDIT - What stops someone from using the public key from the destination site and decrypting the session key sent between client and server?

#9 v90

v90

    Mack Daddy 31337

  • Members
  • 200 posts

Posted 21 August 2003 - 11:26 AM

Yes but SSL is only useful in four situations:

1) You can not trust the Internet (WAN), the computers between you and the server may sniff your packets and pick up everything (This is number 1 because it is true, always...)
2) You can not trust your LAN, someone might be ARP poisining
3) The attackers starts sniffing your packets in the _middle_ of the packet exchange
4) You are a paranoid freak


I am #4, so I do use SSL, but SSL only saves you in SOME situations, if someone was dedicated enough they could sniff your packets from the start so it's only useful in _some_ situations...

#10 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 21 August 2003 - 11:32 AM

I am #4, so I do use SSL, but SSL only saves you in SOME situations, if someone was dedicated enough they could sniff your packets from the start so it's only useful in _some_ situations...

That's what I was beginning to think... Thanks. BTW I am a paranoid freak as well, I think everyone here is.

#11 vooduHAL

vooduHAL

    SUPR3M3 31337 Mack Daddy P1MP

  • Agents of the Revolution
  • 415 posts

Posted 22 August 2003 - 11:35 PM

As I understand SSL, if I understand SSL(I probably don't), the public/private key pair is created after when ever it is inialized the first time, most of the time after the first install when sshd starts up. And if SSL is using RSA, RSA uses a basically a onetime pad for each session. It randomly generates a shared DES key that it then encrypts with the public key it received from the host. It sends the encrypted key back to the host where it decrypts. Both machines use this shared DES key for the transmissions. At least, this is the way RSA was initially used because of the computing resources needed to encrypted using a data RSA was pretty great and it had to be done quickly. You couldn't do it very quickly with RSA so you had to use a symmetric key (DES) as a one time pad (One time pads are used only once then discarded).

#12 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 25 August 2003 - 10:25 AM

I am #4, so I do use SSL, but SSL only saves you in SOME situations, if someone was dedicated enough they could sniff your packets from the start so it's only useful in _some_ situations...

Vlad - how can your info be non secure even if someone is sniffing the entire transmission. From what I've read, it's not computationally feasible to brute force the servers private key. I guess it depends on your definition of secure. Were you speaking as a paranoid freak, or were you refering to a weakness I didn't read about.

The only attack I found info on was the old man in the middle attack, which can be prevented by not being a retard. The other attack that I sort of got info alluding to was a timing attack, which greatly reduces the brute force key combinations to guess the encryption key. This attack works by timing the time required to encrypt the message from the server or the client, to guess the size of the encryption number, and their private key. This attack requires a certain level of control, and I'm not sure how valid it is over a real world network... but check out this excerpt from a cached google page:

"The paper documents a set of experiments using widely-available
hardware to attack a simplified model of an SSL/TLS-enabled web
server. The researchers were able to extract a 1024-bit RSA private
key from the model RSA decryption server in approximately two hours.
The attack requires ~350,000 samples, which to a web server may
appear as network connections and failed attempts to set up SSL/TLS
sessions."

With the new Eliptical Curve Cryptographic approach of TLS, a 163 bit key is equivalent to a 1024 bit RSA, it looks like even this advanced crypto is vulnerable to timing attacks.

There is a patch for OPenSSL, it would be interesting to know what other non unix OS's use for SSL. I did a search on MS support and found nothing on it. For papers on the timing vulnerability just google "timing attack on ssl".

Oh and thanks voodooHAL, that info seems to be the same as all the other stuff I read. I didn't look into the sshd stuff though, just general SSL only. An SSL attack is not specific to an application, because it lies below the application layer.

#13 White_Raven

White_Raven

    That's so raven!

  • Banned
  • 1,597 posts

Posted 25 August 2003 - 01:04 PM

Yes but brute forcing a sshd is a old attack; back in the day I had a slackware 7 box that got owned that way.

#14 v90

v90

    Mack Daddy 31337

  • Members
  • 200 posts

Posted 25 August 2003 - 05:13 PM

If they start sniffing your traffic at the start of the transcation of an SSL or SSHv1 session they can catch your keys and decrypt everything, it's not a mathematical weakness (ie. WEP/RC4) but more just insecure transmission...

#15 l0cache

l0cache

    I'm on default!

  • Members
  • 123 posts

Posted 25 August 2003 - 05:33 PM

vlad - I'm not saying I know everything(or anything really) about SSL, but I just spent 3 days looking through a bunch of books about the shit. If there is something I'm missing I'd love to know.
This is how I understand it. The only non encrypted data is the client hello, where the user passes their public key to the server. After that, everything is encrypted. The session key is public key encrypted, the server public key from the certificate is public key encrypted... There is no way capturing any of these packets can lead to deciphering the message without either the private key of the client, or the private key of the server. In order to get the private key from the client or server you have to either brute force it or expose it through a timing attack.
Am I missing something?




BinRev is hosted by the great people at Lunarpages!