From: Scott Morris (swm@emanon.com)
Date: Tue Jan 03 2006 - 18:01:09 GMT-3
That would be osmosis (there's more beer in the keg than is in me,
therefore...) and I haven't got that to work yet.  ;) 
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
joshua lauer
Sent: Sunday, January 01, 2006 12:39 PM
To: Tim; 'Scott Morris'; security@groupstudy.com; ccielab@groupstudy.com
Subject: Re: Hoping for Hashing Help
can you drink the beer without taking it out of the keg, that would really
be something :)
JL
----- Original Message -----
From: "Tim" <ccie2be@nyc.rr.com>
To: "'Scott Morris'" <swm@emanon.com>; <security@groupstudy.com>;
<ccielab@groupstudy.com>
Sent: Sunday, January 01, 2006 12:22 PM
Subject: RE: Hoping for Hashing Help
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3