From: Tim (ccie2be@nyc.rr.com)
Date: Sun Jan 01 2006 - 14:22:31 GMT-3
I've heard you say that before - that you can drink a lot. OK, here are 2
q's:
1) How much can u really drink?
2) Do you get nasty when you're drunk?
If you're a good drunk, then I don't care how much you drink. I say bring
it on.
Regarding Hashing: I was about to mention the idea of combining a shared
key with the plaintext message to create a message digest that does more
than just verify the integrity of the original message but then I thought
lots not clutter too many thoughts in one post.
But, since you mentioned it, I think a whole lot of people would understand
all this stuff much better if info like this were just spelled out plainly.
For example:
At simplest:
1) parity
What it does... How it works... Where it's used...
Pros... Cons...
2) CRC
What it does... How it works... Where it's used...
Pros... Cons...
3) Basic Hash
What it does... How it works... Where it's used...
Pros... Cons...
Different versions...
4) Hash with Shared secret key (HMAC)
5) Hash with Private Key (Digital Signature)
I think if it's broken down like this, even (non-Einstein) people like me
can understand it.
I also wouldn't mind seeing a clear concise comparison of all these words
that seem to mean the same thing but don't quite mean the same thing such
as...
password
passphrase
key
secret
one-time pad
initialization vector
and others that don't readily come to mind at the moment. With all these
terms floating around and sometimes being misused, it's no wonder people
find this stuff confusing.
In this case, I don't think "Security by obscurity" really works. I think
people just get turned off and decide not to deal with it. What do you
think?
Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Sunday, January 01, 2006 11:02 AM
To: 'Tim'; security@groupstudy.com; ccielab@groupstudy.com
Subject: RE: Hoping for Hashing Help
Hehehe... Be careful there, I can drink a lot! :)
It's interesting sometimes! CRC is a good comparison, and that's a nice way
to look at it. You want to make sure that something hasn't been messed with
whether an error (CRC) or intentional. So it's more sophisticated that
people can't hide their tacks very well. Basic parity or FEC is similar,
but more designed to allow error correction in small chunks.
One of the primary differences between MD5/SHA key exchanges and something
like parity checking or CRC's is that often there is a starting "seed" value
as part of the algorithm. This could be your pre-shared key, or your RSA
key, or whatever you choose to use. But that all goes to being part of the
sophistication. Otherwise, like with a CRC, whatever changes I may make to
your packets I can regenerate a new CRC to make things look just fine. So
we need to add to the sophistication and come up with "more stuff" to add in
order to make it less likely that anyone can change things around.
Cryptology is a very interesting science. I just don't have the
inclinication to get my brain too deep into it! I used to work with a guy
who could whiteboard out and generate MD5/SHA outputs. I'm not like that!
(grin)
Scott
-----Original Message-----
From: Tim [mailto:ccie2be@nyc.rr.com]
Sent: Sunday, January 01, 2006 8:32 AM
To: swm@emanon.com; security@groupstudy.com; ccielab@groupstudy.com
Subject: RE: Hoping for Hashing Help
Hey Scott,
First, let me wish you and your family the best possible 2006 imaginable.
And, if we do meet up sometime this year, ALL your drinks are on me. How
much can you drink?
Thanks for the reply on Hashing. I didn't know about that sampling process
and I still don't know exactly what munging is but I get the idea.
Surprisingly, this cryptology topic has turned out to be much more
interesting than I expected.
What I still don't understand is why none of the people that write about
this Hashing stuff don't put this topic in context.
When you think about it, isn't hashing just a more sophisticated form of
parity checking which itself is a less sophisticated type of CRC (cyclic
redundancy check)?
Maybe once I fully understand all this stuff myself, I'll write a pamphlet
geared to normal people.
Thanks again, Tim
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Saturday, December 31, 2005 8:57 PM
To: 'Tim'; security@groupstudy.com; ccielab@groupstudy.com
Subject: RE: Hoping for Hashing Help
MD5 and SHA both take a sampling of the message in question. That's why the
message length doesn't matter much. Although, since sampling isn't a static
thing that's why MD5 has been shown to have "collision weakness" where more
than one input could have the same hash output even though it's not able to
be reverse engineered.
MD5 gathers its samples based on 512-bit blocks of data from the input
message. The one-pass algorithm that takes those samples basically figures
out how much data there is in the message and does it's magic from there!
SHA-1 does a different type of sampling arrangement (different advanced
math) and comes out with a 160-bit fingerprint. MD5 is 128-bit fingerprint.
Both are susceptible to a collision-type attack, but SHA-1 is less affected
by it (or it's more difficult to do), although SHA-2 has already improved
upon the strength.
Simple terms? Magic. :) I'm not sure there's much of an easier way to
look at it. You take a chunk of data of variable size, you apply one
algorithm to pull bits of information out, then you take another algorithm
to munge that information and come up with a fixed-length output string.
Any change in the message (since we go down to bit-level) can make a big
change in the output.
For some examples, wiki search for MD5 and SHA.
It's math way above my brain cell structure, so I just am content to know
the concept and accept the magic. :) I turn the key in my car and the
engine starts. I don't particularly care why or how, it just does, and I'm
cool with that! (grin)
Cheers,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tim
Sent: Saturday, December 31, 2005 3:40 PM
To: security@groupstudy.com; ccielab@groupstudy.com
Subject: Hoping for Hashing Help
Hi guys,
Happy New Year.
I hope everybody a year from now can look back upon 2006 and say, "This was
truly a great year."
Anyway, I've been trying to figure out something that's been bothering me
about hashing. According to lots of sources, a hash function can take as
input an arbitrarily long message and generate a fixed length output which
seems to be 128 bits in length for most Hashing algorithms such as SHA-1,
MD5, etc. commonly used today.
My question is this:
Can someone explain in simple terms how that's done without using advanced
mathematics?
When you think about it, this is very cool. No matter what length the
original message is, the hash is 128 bits. If the message is 100 bytes, the
hash is 128 bits. But, if the message is 1,000,000 bytes, the hash is still
128 bits. How is that possible? I'm hoping someone can illustrate how
that's done with a simple example.
Ok, everyone have a good time this evening.
TIA, Tim
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3