>Whoops...looks like I've started a new thread here. ;-)
>
>Hashing:
>
>What's green and red and goes a hundred miles an hour? You guessed it, a
>frog in a blender. When you "hash" a password, that's essentially what
>you're doing - putting it in a blender and making something completely
>different that no one would immediately recognize. And just like our poor
>frog (nod to PETA there), once it's gone through the blender, we will never,
>ever get a frog back from the goo. It's (theoretically) mathematically
>impossible to un-hash a hashed password (I know there are programs out there
>that do this, but I'm talking about MD5 hashing - can't be undone in this
>day and age...but has anyone else been following quantum computing? Scary
>stuff...).
Good description.
>
>Encryption:
>
>In encryption, we're "disguising" our frog to look like something else, with
>the *intention* of removing the disguise at some point and getting our
>original frog back. The technical term used is "key." We use a public key
>to encrypt, and a private key to decrypt. The point is, we get the original
>thing back in a useable form, and not just a lump of goo.
Encryption isn't the only means to hide information, although for
many years, it has been the main one to consider. In the specific
context of encryption, I would make the distinction that there are
two basic types:
Symmetrical: the same key is used for both encryption and decryption.
much faster than asymmetrical.
Asymmetrical: different keys are used for encryption and decryption.
whether or not the encryption or decryption key is
public depends on the application. There is a mathematical
relationship between the public and private keys, but it's
one-way.
There are two fundamental cryptographic applications: authentication,
where I am trying to make my "signature" or other identifying
information verifiable and tamper-proof, and confidentiality, where I
am trying to conceal my message content from unauthorized people. The
two can overlap -- there are applications where the message content
can be read, but must be tamper-proof.
In authentication with asymmetrical cryptography, you use the
SENDER's PRIVATE key to encrypt information that is known to the
sender (e.g., your name). The sender decrypts with your PUBLIC key,
and, if the correct information is decrypted, assumes the
communication is authentic.
To get confidentiality with asymmetrical cryptography, you encrypt
the confidential information with the RECEIVER's public key, and he
decrypts with his PRIVATE key.
With asymmetric cryptography, you need a public/private key for each
direction of transmission. For performance reasons, asymmetrical
cryptography is often used to negotiate a symmetric session key,
which is used for the bulk of the traffic.
>
>On the Cisco router, we have a command "service password-encryption." Well,
>what we're *really* doing is hashing.
Precisely.
>We're not using a public key to
>encrypt - we're hashing the password into an unrecognizeable lump of goo.
>When the router prompts us for a password, we enter it, and then the
>password we enter is run through the same blender - the same hashing
>algorithm. If the result is green and red and going a hundred miles an hour
>(which is what the router is looking for), then we're let in. If the result
>is blue and yellow and going a hundred miles an hour, then it obviously
>wasn't a frog we put into the blender.
>
Advanced mechanisms that may be worth knowing about are steganography
and covert channels. Both are ways of sneaking information around
firewalls. Steganography is the art of hiding something in plain
sight, or, at least, without formal cryptography. Historically, it
involved such things as secret inks. Today, you might see
steganography used to hide textual information in a JPEG...every Nth
pixel is actually a bit in a text message.
Covert channels are really nasty. They send information using a
mechanism that we normally think contains no information. For
example, we might delay packets for controlled amounts of time.
Simplifying and avoiding details of how it's implemented,
conceptually the inter-packet gap is one time longer than the
standard, it is signaling an "A," if it is two times longer, it's a
"B", etc. Alternatively, you might hide information in the size of a
TCP window, or the number of bytes sent before sending a flush
request.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
