-
May 21st, 2003, 05:43 AM
#1
SssssssSsssssLlllllll RSA RSA RSA ! ! !
Alright, again I was bored so i decided to write a tutorial after I did
a little bit of research/reading. I find some of the implementations of
the Secure Sockets Layer (SSL) very interesting and concluded that hey,
maybe someone else would as well.
What SSL's job is to manage the transmission of messages across the
internet in a safe, secure way. This is done by many methods of
encryption.
Almost any web browser/server/network app can be enabled to use SSL or
its recent successor TLS which is based on SSL but isn't near as wide-
spread/used yet so I wont go into that. For instance, netscape, bleh IE,
and like I said basically any other.
The use of encryption is asymmetrically designed so that only a private
key can be decrypted by a public key, and that only a public key can be
decrypted by a private key. The public key is distributed widely and the
private key is always kept safe and out of harms way (So don't worry about
another public key decrypting this and spreading it across the internet
like the melissa virus :P )
Back before implementations of SSL, nearly anyone could spoof their access
across the net by simply lying to another server/site/network/whatever.
er0k sends message to stormhawk
stormhawk says "Who is this? "
er0k says "This is er0k"
stormhawk says "Lemme see your public key"
er0k throws the public key out and stormhawk has no idea whether this is
valid or not. Then er0k proves it by encrypting something already there
and sending it across. Stormhawk is oblivious now.
But SSL came up with a way to prevent this from occuring. Its called
certificates. You all have probably seen certificates across the net from
your own browser's, asking for authenticity and things of the sort before
you download a program. Well this is SSL at work in browser form, although
other protocol's that use the SSL protocol do it in the same way just not
so graphical and scary, simply because you cannot see it.
In a transmission of a certificate with SSL, the server checks for:
the issuers name, his/her public key, time stamps, and several other
methods of authentication.
Of course, like anything, this is and has been easily exploitable, for
instance er0k and stormhawk passing the same messages back and forth
messages being encrypted, and er0k taking the messages and making them
very difficult to understand, but seem reasonable because he sent
stormhawk someone else's certificate since er0k is now trying to be
someone else. Stormhawk believes him finally and lets him come visit.
Now stormhawk begins to throw in some MAC (Not machine address, machine
access code) stuff at er0k, and now er0k is in big trouble. He doesn't
know the code, and has a very rare chance of getting it. The machine
access code is MD5, which is nearly impossible to decrypt unless you are
the NSA with the algorithms/machines working on it for about 10 seconds.
Chances are SSL is going to win always, TSL apparently is even better
with new RSA public key auth, mac, etc, algorithms.
Moral of the tutorial, dont lie to people, there is always a method of
catching you
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|