boardix


Post New Topic  New Poll  Post A Reply
my profile | directory login | | search | faq | forum home
  next oldest topic   next newest topic
» boardix   » Groups   » Codecrave   » Encryption Mumbo Jumbo

 - UBBFriend: Email this page to someone!    
Author Topic: Encryption Mumbo Jumbo
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
So I'm not sure if anyone besides mike at this point will know what I am talking about but I wanted to make it public knowledge. I am proposing a slight change in the encryption algorithm that should help stop a man in the middle attack. A man in the middle attack consists of someone snooping in on one's communication. When a two sided commun. is established, one side sends over its public key and the man-in-the-middle lets refer to him as kordik, intercepts that and changes it. Now the other end recieves this new bogus key and sends their own key over. Again, this kordik character intercepts it and changes it, sending something different over to the other end. Mr. Kordik now has the ability to read people's/decrypt people's messages with little effort. My propossed change to this is the following, I read something very similar but vauge and not specific to diffie-hellman while surfing.

The end that wants to send an encrypted msg initiates contact saying hey look, i wanna encrypt. The other end says cool, here is my public key. The sending end takes that public key and then uses that to create its private key. Now here is the most important part, before sending over their public key to the reciever, they send over the encrypted msg first. The recieving side will have no idea what to do with it, however, a man in the middle, not knowing both public keys and not having altered both, will be at a loss to inject his own key into the mix. He cannot fake the second public key because it has not been sent. Now, the second public key is sent to the reciever. If the man in the middle alters this key in ANY way the MSG sent prior will not be decrypted correctly. ***f, you know you got a-kordik-in-the-middle who is snoop'n your ass. My thoughts on this are as follows, a sort of certificate could be generated by one end, encrypted and sent before the second public key is exchanged. Then the second public key is sent and decryption begins. If the certificate does not match or "make sense" to the reciever, they cut communication and the actual sensitive data is not even sent.

Sounds interesting huh? Why don't you let me know if that makes sense and if you see any problems/enhancements that could be made. I have only thought this over in my head and have not attempted a simulation. Put that old noggin to work mr mallio.

[ May 16, 2003, 03:41 PM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
rather than a certificate... why don't you just check to make sure that where the message is coming from is where it should be coming from?

Also... the message could still be listened to using this method... the listener would just have to modify the code to do it backwards than before.

It really seems to me the only way to be sure that it is being correctly sent and recieved is to make sure that the correct computer is getting the data... but even that could be forged very easily if it was checked by data sent. Some sort of "fake IP address" detection would have to ensue... unless there is some way to remotely check the serial number of a computer....

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
getting this in my head will wor better with a diagram:

code:
[b]old way[/b]

Sender: Receiver:
------- ---------
-Send flag and public
key -Recieve flag
-Send public key
-Receive key
-Create private key -Create private key
-Send encrypted messg
-Receive messg
-Decrypt

[b]proposed way[/b]

Sender: Receiver:
------- ---------
-Send flag only
-Receive flag
-Send public key
-Receive key
-Create private key
-Send encrypted messg
-Receive message
-Send private key
-Receive key
-Decrypt

Well whats to stop this situation:
code:
 
Sender: kordik: Receiver:
------- ------- ---------
-Send flag only --------> flag
flag ---------------> -Receive flag
key <--------------- -Send public key
-Receive key <----------- key
-Create private key
-Send encrypted messg---> msg
msg ---------------> -Receive message
-Send private key-------> key
key ---------------> -Receive key
-Decrypt

Kordik seems to have all the info he needs as long as he knows the protocol, in which cas we are only adding an extra send/recv, which is time consuming.

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
To my knowledge the man in the middle attack only works because the man in the middle sends fake public keys that make the private key mathematically easier to get. What I posted would disallow the man in the middle from using bogus public keys because the certificate would not decrypt correctly. And as for knowing that the packets you are recieving came from the actual person, thats almost impossible. Any part of a packet can be forged/sp00fed (p00 is censored). You can create your own custom packets and fill in what ever bogus data you want. Just check out ettercap. You can "insert" a bogus packet for whatever floats your boat.

Its not that both public keys cannot be known, they are in fact allowed to be known, hence the name "public" its that they both need to be made correctly and not tampered with.

[ May 16, 2003, 10:20 PM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
if the public keys can be known... how could anything possibly stop the middle man from knowing what is going on? what about the message being sent, and then the private key from the opposite machine is sent to the sender, and then sent immediatly back... basically with no time for the middle man to do anything whatsoever because it just goes bang-boom-boom right after another, and if it doesn't then boom... error

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
Nope, timing cant really work either. The man-in-the-middle does have to do the work of both parties (needs to generate 2 private keys and decrypt and reencrypt the message to stop suspicion). Well, things such as the speed of your processor, AMD vs. Pentium, and apparently using linux, can make a HUGE difference in the amount of time the process takes. As of right now, it takes about 10 seconds for me to send an encrypted message. Dave can do it immediately. You people using VB will have aLOT more trouble. So if i'm sending to kordik, dave could easily act as a man in the middle without really screwing up the timing.

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
basically what it looks like, is that the man in the middle can get it no matter what... all he has to do is, well, get in the middle and get what he wants then send it where it is supposed to go.

But, what if he couldn't connect to both guys... here's what I'm saying: As far as I know (at least from my experience) he can't be conencted to both computers on the same port... so if a common port is established, he would have to connect and disconnect from the sender and reciever to get and send info back and forth... and if a connection is broken... then the IM should just not be sent, and pop up an error message. ????

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
What can the man in the middle do? He is allowed to know BOTH public keys. The only thing he does that actually allows him to crack the encryption is to forge public keys (from my understanding of reading). Now if we used some sort of certificate or authentication system so that we could tell if there was someone in the middle catching and changing public keys the man in the middle would be out of luck. Hence the sending of an encrypted msg that the man in the middle would not be able to do anything to since he has not seen both public keys. By that time it would be too late for him to stop the process and insert two faulty keys. Meaning that he would be at the mercy of the key length to try and brute force the key (which is very good, meaning years of computer guessing) I have seen a couple websites that have what they call a different version of the diffie hellman method that subverts a man in the middle from ever being successful. I'll try and read up on it tonight after I watch the Matrix Reloaded.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
Well, how bout this: (Sender = Mike, Receiver = Dave)

kordik sees the flag, realizes there is an encypted message to be sent
kordik then sets himself to receive the other public key and store it.
kordik generates his own public key and sends it to Mike.
kordik receives Mike's message and stores it.
kordik receives Mike's key and decrypts the message.
kordik reencrypts the message with his own key and stored key
kordik sends the message to Dave
kordik sends his own key to Dave

this almost seems to make it easier to crack, as he has time after the flag to get into the middle if he is just sniffing for the flag.

I haven't yet found a good explaination of the diffie-hellman variaition called Station-to-Station. but I have found shtuff on the other method you mention, the certificate method, which would require we use the same public key everyt time, as a certificate is associated with a certain key.

However, there is a variation of the certificate method that i kinda came up with from my knowlege of certificates and my readings: each person generates a private certificate unique to them (like some random number or something). The very first time you talk to the person, there is a very low chance that there will be a man-in-the-middle, since he won't have discovered you yet.

If you ever ssh into a computer from putty, the very first time you should get a message telling you that its certificate is new and not stored, and asks you if you trust it and want to continue connecting and store the certificate. We could do a similar thing, if the certificate is different or not stored, pop up a message asking if you trust your connection. then if the certificate ever changes, you will be notified, and you can close the connection before any sensitive data is transferred.

we would generate the certificate in the same way we generate the key, so in effect we'd be sending 2 keys, one for verification and another for encryptio/decryption.

here's how i think it would work...

my proposal:
-each party generates a permanent certificate
-you create a public version of that certificate by using your private value in place of the given value in the public key creator. This will randomize your certificate so its not the same every time you send.
-each party exchanges both their public keys and certificates, and checks each others certificates against their database
-if both sides feel it is safe, the message is encrypted and sent.

if anyone needs any more explaination or sees any possible flaws (besides a man in the middle who is alway sin the middle for some reason) let me know.

-------------------------------

okay i already found a problem:
decrypting the certificate. I'll think about this later. i gotta go.

[ May 17, 2003, 08:18 PM: Message edited by: MalliO ]

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Um, the certificate could not be decrypted by the man in the middle mike. He has but one public key, how can he decrypt the certificate that was encrypted by the private key?

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
http://cm.bell-labs.com/who/philmac/pak_view/node1.html

This link is almost exactly what I was trying to say.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
holy crap that seems complicated....

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
No, thats not really at all what you were trying to say...The reason that link's method is effective is because it hashes the password using the private key, so you'd have to know the password to to authenticate, since hasing is irreversible. However, hashing is vulnerable to dictionary attacks and the birthday attack (the birthday paradox says that in a room of 23 peopple there is a 50% chance that 2 will have the same birthday). Its not hard to just plug words/numbers till you find a word that hashes to the same hash table. However, while thinking last nite (*****en internet got busted) i was thinking that hashing the certificate might not be too bad an idea, but there is more that would need to be done, due to the birthday attack.

But we could do a hash function. Or we could devise a system of public and private certificates in which you send a "public" certificate that can be related to the private key and the recipient's certificate so your certificate is never made public...thats my thought...

Either way, there needs to be a first authenticating step, be it an exchange of passwords or certificates. But i think that would be okay since there is low likelyhood anyone would get into the middle of the first message.

so i think one good way would be to exchange encrypted certificates at the first communication, store those, and send a public certificate with every message that is encrypted and some mathematical combination of both certificates...Nothing i can think of is flawless...

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
by the way, tat websit uses this as the fully secure version: http://cm.bell-labs.com/who/philmac/pak_view/node3.html

if you thought the first one was hard to understand, check that. I guess this is point where cs225 and cs173 start truly paying off. speaking of cs173, i should look at that book again...

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
that is the page i was talking about... and i repeat... holy crap that seems complicated

i'm sure i could figure it out... but it would serve me no purpose

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
The general idea and algorithm behind that link is exactly what I was trying to say. The only difference is I wasn't saying hash the certificate but encrypt it using the private key. I'm am not seeing how this is completely different.

edit:
its true a hash being irriversible would only be vulnerable to a dictionary attack and given a large enough encryption key, the computing time would be similar. By the time any of the two methods were broken the encryption session would be long over or teminated.

[ May 18, 2003, 11:52 PM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
After reading over more papers and such online I think a meeting would be in order. Its hard to understand/communicate or explain things of such complexity by leaving msgs. I seem to be getting lost understanding even myself when I type what I am thinking.

So lets do a meeting sometime soon. **We will try and record the conversation for you Dan, since you live such a large distance away. Tues night is best for me this week because of work. How about mike/kordik?

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
i totally missed you talking about encrypting the certificate somehow...but yeah, a meeting on tuesday, because what you seem to be hinting at is that both of us are trying to say the same thing but aren't getting it out clearly enough...

anyway, i'm kindof a fan of the hashing method, since i just learned about that *****, and it would take less time and space (though would still be effective)

[ May 19, 2003, 03:03 AM: Message edited by: MalliO ]

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Hash/encrypt its all good. Cept you'll have to give a brief example of hashing.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Proposed digital signature method:

The Improved Diffie Hellman method helps assure that a man-in-the middle cannot intercept the keys and tamper with them (by changing the key to a mathematically weak number) and then continue to send them on to the recipient and vice versa because the encrypted message is sent prior to any public key exchanges. However, we still cannot trust that the person we are talking to is who we expect. Ala a spoofer pretending to be our "buddy". We could carry on a whole conversation with someone without knowing that we really aren't talking to isu224188.ilstu.edu So this is where a digital signature comes into play. Similar to SSH, when we connect to another computer whom we assume to be the person we actually want to talk to, we need to verify this person is who they say they are, by a key or hash of some sort. My proposal/idea is this. When an encrypted session begins, the message is the first thing sent. The recieving side would then be expected to "watermark" the entcypted message with their personal secret key and then take a hash of this new watermarked message. This would then be returned to the original message sender who knows from an earlier trusted session what the secret key of the reciever is. The sender would then watermark the original message the same way as the reciever and take the hash of this. If the hashes are equally, we can with enough certainty (2^64 random documents for MD5 share the same hash) believe that our message was delivered to the correct recipient and we can proceed with our prublic key swap. If even this wasn't enough, the reciever could watermark EVERYTHING the sender sent and everything they send (public keys and all) and send them back to the sender to be verified. This would with almost 100% certainty verify that the reciever is who we expected and that they have recieved everything we have sent to them and that everything we have recieved is from them.

Anyone have comments ideas??? I was thinking MD5 would be nice to try for the hash and the trusted session would be something similar to ssh1/2 where the first interaction you have with another user you exchange "finger prints" via a weaker encytped protocol (aka the improved diffie hellman without watermarking). It makes for a slight doubt but that is why you need to believe for some reason or another that your session was secure.

[ October 06, 2003, 05:19 PM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
You know i'm down, I said i would be down with ssh-like certificates like 8 years ago. Or 8 posts ago.

anyway, doesn't 2^64 seem like a lot? how many are possible total? the fewer the better...is MD5 the best? is that what SSH uses?

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
MD5 easy and plentiful. RSA released their own MD5 source code and it can be used free of charge and even modified if you state that you modified it. So soon certs will be done and encryption will be 100 thousand percent done for good to be the bestest ever for any chat program.

Here is the easiest md5 source files to use. They be crossplatform and all that jazz. BTW, little important peice of advice, include the source file not the header in your code b/c of linking/object problems.

md5.c
code:
 /*
* This code implements the MD5 message-digest algorithm.
* The algorithm is due to Ron Rivest. This code was
* written by Colin Plumb in 1993, no copyright is claimed.
* This code is in the public domain; do with it what you wish.
*
* Equivalent code is available from RSA Data Security, Inc.
* This code has been tested against that, and is equivalent,
* except that you don't need to include two pages of legalese
* with every copy.
*
* To compute the message digest of a chunk of bytes, declare an
* MD5Context structure, pass it to MD5Init, call MD5Update as
* needed on buffers full of bytes, and then call MD5Final, which
* will fill a supplied 16-byte array with the digest.
*/
#include <string.h> /* for memcpy() */
#include "md5.h"

#ifndef HIGHFIRST
#define byteReverse(buf, len) /* Nothing */
#else
void byteReverse(unsigned char *buf, unsigned longs);

#ifndef ASM_MD5
/*
* Note: this code is harmless on little-endian machines.
*/
void byteReverse(unsigned char *buf, unsigned longs)
{
uint32 t;
do {
t = (uint32) ((unsigned) buf[3] << 8 | buf[2]) << 16 |
((unsigned) buf[1] << 8 | buf[0]);
*(uint32 *) buf = t;
buf += 4;
} while (--longs);
}
#endif
#endif

/*
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
void MD5Init(struct MD5Context *ctx)
{
ctx->buf[0] = 0x67452301;
ctx->buf[1] = 0xefcdab89;
ctx->buf[2] = 0x98badcfe;
ctx->buf[3] = 0x10325476;

ctx->bits[0] = 0;
ctx->bits[1] = 0;
}

/*
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
{
uint32 t;

/* Update bitcount */

t = ctx->bits[0];
if ((ctx->bits[0] = t + ((uint32) len << 3)) < t)
ctx->bits[1]++; /* Carry from low to high */
ctx->bits[1] += len >> 29;

t = (t >> 3) & 0x3f; /* Bytes already in shsInfo->data */

/* Handle any leading odd-sized chunks */

if (t) {
unsigned char *p = (unsigned char *) ctx->in + t;

t = 64 - t;
if (len < t) {
memcpy(p, buf, len);
return;
}
memcpy(p, buf, t);
byteReverse(ctx->in, 16);
MD5Transform(ctx->buf, (uint32 *) ctx->in);
buf += t;
len -= t;
}
/* Process data in 64-byte chunks */

while (len >= 64) {
memcpy(ctx->in, buf, 64);
byteReverse(ctx->in, 16);
MD5Transform(ctx->buf, (uint32 *) ctx->in);
buf += 64;
len -= 64;
}

/* Handle any remaining bytes of data. */

memcpy(ctx->in, buf, len);
}

/*
* Final wrapup - pad to 64-byte boundary with the bit pattern
* 1 0* (64-bit count of bits processed, MSB-first)
*/
void MD5Final(unsigned char digest[16], struct MD5Context *ctx)
{
unsigned count;
unsigned char *p;

/* Compute number of bytes mod 64 */
count = (ctx->bits[0] >> 3) & 0x3F;

/* Set the first char of padding to 0x80. This is safe since there is
always at least one byte free */
p = ctx->in + count;
*p++ = 0x80;

/* Bytes of padding needed to make 64 bytes */
count = 64 - 1 - count;

/* Pad out to 56 mod 64 */
if (count < 8) {
/* Two lots of padding: Pad the first block to 64 bytes */
memset(p, 0, count);
byteReverse(ctx->in, 16);
MD5Transform(ctx->buf, (uint32 *) ctx->in);

/* Now fill the next block with 56 bytes */
memset(ctx->in, 0, 56);
} else {
/* Pad block to 56 bytes */
memset(p, 0, count - 8);
}
byteReverse(ctx->in, 14);

/* Append length in bits and transform */
((uint32 *) ctx->in)[14] = ctx->bits[0];
((uint32 *) ctx->in)[15] = ctx->bits[1];

MD5Transform(ctx->buf, (uint32 *) ctx->in);
byteReverse((unsigned char *) ctx->buf, 4);
memcpy(digest, ctx->buf, 16);
memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */
}

#ifndef ASM_MD5

/* The four core functions - F1 is optimized somewhat */

/* #define F1(x, y, z) (x & y | ~x & z) */
#define F1(x, y, z) (z ^ (x & (y ^ z)))
#define F2(x, y, z) F1(z, x, y)
#define F3(x, y, z) (x ^ y ^ z)
#define F4(x, y, z) (y ^ (x | ~z))

/* This is the central step in the MD5 algorithm. */
#ifdef __PUREC__
#define MD5STEP(f, w, x, y, z, data, s) \
( w += f /*(x, y, z)*/ + data, w = w<<s | w>>(32-s), w += x )
#else
#define MD5STEP(f, w, x, y, z, data, s) \
( w += f(x, y, z) + data, w = w<<s | w>>(32-s), w += x )
#endif

/*
* The core of the MD5 algorithm, this alters an existing MD5 hash to
* reflect the addition of 16 longwords of new data. MD5Update blocks
* the data and converts bytes into longwords for this routine.
*/
void MD5Transform(uint32 buf[4], uint32 const in[16])
{
register uint32 a, b, c, d;

a = buf[0];
b = buf[1];
c = buf[2];
d = buf[3];

#ifdef __PUREC__ /* PureC Weirdness... (GG) */
MD5STEP(F1(b,c,d), a, b, c, d, in[0] + 0xd76aa478L, 7);
MD5STEP(F1(a,b,c), d, a, b, c, in[1] + 0xe8c7b756L, 12);
MD5STEP(F1(d,a,b), c, d, a, b, in[2] + 0x242070dbL, 17);
MD5STEP(F1(c,d,a), b, c, d, a, in[3] + 0xc1bdceeeL, 22);
MD5STEP(F1(b,c,d), a, b, c, d, in[4] + 0xf57c0fafL, 7);
MD5STEP(F1(a,b,c), d, a, b, c, in[5] + 0x4787c62aL, 12);
MD5STEP(F1(d,a,b), c, d, a, b, in[6] + 0xa8304613L, 17);
MD5STEP(F1(c,d,a), b, c, d, a, in[7] + 0xfd469501L, 22);
MD5STEP(F1(b,c,d), a, b, c, d, in[8] + 0x698098d8L, 7);
MD5STEP(F1(a,b,c), d, a, b, c, in[9] + 0x8b44f7afL, 12);
MD5STEP(F1(d,a,b), c, d, a, b, in[10] + 0xffff5bb1L, 17);
MD5STEP(F1(c,d,a), b, c, d, a, in[11] + 0x895cd7beL, 22);
MD5STEP(F1(b,c,d), a, b, c, d, in[12] + 0x6b901122L, 7);
MD5STEP(F1(a,b,c), d, a, b, c, in[13] + 0xfd987193L, 12);
MD5STEP(F1(d,a,b), c, d, a, b, in[14] + 0xa679438eL, 17);
MD5STEP(F1(c,d,a), b, c, d, a, in[15] + 0x49b40821L, 22);

MD5STEP(F2(b,c,d), a, b, c, d, in[1] + 0xf61e2562L, 5);
MD5STEP(F2(a,b,c), d, a, b, c, in[6] + 0xc040b340L, 9);
MD5STEP(F2(d,a,b), c, d, a, b, in[11] + 0x265e5a51L, 14);
MD5STEP(F2(c,d,a), b, c, d, a, in[0] + 0xe9b6c7aaL, 20);
MD5STEP(F2(b,c,d), a, b, c, d, in[5] + 0xd62f105dL, 5);
MD5STEP(F2(a,b,c), d, a, b, c, in[10] + 0x02441453L, 9);
MD5STEP(F2(d,a,b), c, d, a, b, in[15] + 0xd8a1e681L, 14);
MD5STEP(F2(c,d,a), b, c, d, a, in[4] + 0xe7d3fbc8L, 20);
MD5STEP(F2(b,c,d), a, b, c, d, in[9] + 0x21e1cde6L, 5);
MD5STEP(F2(a,b,c), d, a, b, c, in[14] + 0xc33707d6L, 9);
MD5STEP(F2(d,a,b), c, d, a, b, in[3] + 0xf4d50d87L, 14);
MD5STEP(F2(c,d,a), b, c, d, a, in[8] + 0x455a14edL, 20);
MD5STEP(F2(b,c,d), a, b, c, d, in[13] + 0xa9e3e905L, 5);
MD5STEP(F2(a,b,c), d, a, b, c, in[2] + 0xfcefa3f8L, 9);
MD5STEP(F2(d,a,b), c, d, a, b, in[7] + 0x676f02d9L, 14);
MD5STEP(F2(c,d,a), b, c, d, a, in[12] + 0x8d2a4c8aL, 20);

MD5STEP(F3(b,c,d), a, b, c, d, in[5] + 0xfffa3942L, 4);
MD5STEP(F3(a,b,c), d, a, b, c, in[8] + 0x8771f681L, 11);
MD5STEP(F3(d,a,b), c, d, a, b, in[11] + 0x6d9d6122L, 16);
MD5STEP(F3(c,d,a), b, c, d, a, in[14] + 0xfde5380cL, 23);
MD5STEP(F3(b,c,d), a, b, c, d, in[1] + 0xa4beea44L, 4);
MD5STEP(F3(a,b,c), d, a, b, c, in[4] + 0x4bdecfa9L, 11);
MD5STEP(F3(d,a,b), c, d, a, b, in[7] + 0xf6bb4b60L, 16);
MD5STEP(F3(c,d,a), b, c, d, a, in[10] + 0xbebfbc70L, 23);
MD5STEP(F3(b,c,d), a, b, c, d, in[13] + 0x289b7ec6L, 4);
MD5STEP(F3(a,b,c), d, a, b, c, in[0] + 0xeaa127faL, 11);
MD5STEP(F3(d,a,b), c, d, a, b, in[3] + 0xd4ef3085L, 16);
MD5STEP(F3(c,d,a), b, c, d, a, in[6] + 0x04881d05L, 23);
MD5STEP(F3(b,c,d), a, b, c, d, in[9] + 0xd9d4d039L, 4);
MD5STEP(F3(a,b,c), d, a, b, c, in[12] + 0xe6db99e5L, 11);
MD5STEP(F3(d,a,b), c, d, a, b, in[15] + 0x1fa27cf8L, 16);
MD5STEP(F3(c,d,a), b, c, d, a, in[2] + 0xc4ac5665L, 23);

MD5STEP(F4(b,c,d), a, b, c, d, in[0] + 0xf4292244L, 6);
MD5STEP(F4(a,b,c), d, a, b, c, in[7] + 0x432aff97L, 10);
MD5STEP(F4(d,a,b), c, d, a, b, in[14] + 0xab9423a7L, 15);
MD5STEP(F4(c,d,a), b, c, d, a, in[5] + 0xfc93a039L, 21);
MD5STEP(F4(b,c,d), a, b, c, d, in[12] + 0x655b59c3L, 6);
MD5STEP(F4(a,b,c), d, a, b, c, in[3] + 0x8f0ccc92L, 10);
MD5STEP(F4(d,a,b), c, d, a, b, in[10] + 0xffeff47dL, 15);
MD5STEP(F4(c,d,a), b, c, d, a, in[1] + 0x85845dd1L, 21);
MD5STEP(F4(b,c,d), a, b, c, d, in[8] + 0x6fa87e4fL, 6);
MD5STEP(F4(a,b,c), d, a, b, c, in[15] + 0xfe2ce6e0L, 10);
MD5STEP(F4(d,a,b), c, d, a, b, in[6] + 0xa3014314L, 15);
MD5STEP(F4(c,d,a), b, c, d, a, in[13] + 0x4e0811a1L, 21);
MD5STEP(F4(b,c,d), a, b, c, d, in[4] + 0xf7537e82L, 6);
MD5STEP(F4(a,b,c), d, a, b, c, in[11] + 0xbd3af235L, 10);
MD5STEP(F4(d,a,b), c, d, a, b, in[2] + 0x2ad7d2bbL, 15);
MD5STEP(F4(c,d,a), b, c, d, a, in[9] + 0xeb86d391L, 21);
#else
MD5STEP(F1, a, b, c, d, in[0] + 0xd76aa478, 7);
MD5STEP(F1, d, a, b, c, in[1] + 0xe8c7b756, 12);
MD5STEP(F1, c, d, a, b, in[2] + 0x242070db, 17);
MD5STEP(F1, b, c, d, a, in[3] + 0xc1bdceee, 22);
MD5STEP(F1, a, b, c, d, in[4] + 0xf57c0faf, 7);
MD5STEP(F1, d, a, b, c, in[5] + 0x4787c62a, 12);
MD5STEP(F1, c, d, a, b, in[6] + 0xa8304613, 17);
MD5STEP(F1, b, c, d, a, in[7] + 0xfd469501, 22);
MD5STEP(F1, a, b, c, d, in[8] + 0x698098d8, 7);
MD5STEP(F1, d, a, b, c, in[9] + 0x8b44f7af, 12);
MD5STEP(F1, c, d, a, b, in[10] + 0xffff5bb1, 17);
MD5STEP(F1, b, c, d, a, in[11] + 0x895cd7be, 22);
MD5STEP(F1, a, b, c, d, in[12] + 0x6b901122, 7);
MD5STEP(F1, d, a, b, c, in[13] + 0xfd987193, 12);
MD5STEP(F1, c, d, a, b, in[14] + 0xa679438e, 17);
MD5STEP(F1, b, c, d, a, in[15] + 0x49b40821, 22);

MD5STEP(F2, a, b, c, d, in[1] + 0xf61e2562, 5);
MD5STEP(F2, d, a, b, c, in[6] + 0xc040b340, 9);
MD5STEP(F2, c, d, a, b, in[11] + 0x265e5a51, 14);
MD5STEP(F2, b, c, d, a, in[0] + 0xe9b6c7aa, 20);
MD5STEP(F2, a, b, c, d, in[5] + 0xd62f105d, 5);
MD5STEP(F2, d, a, b, c, in[10] + 0x02441453, 9);
MD5STEP(F2, c, d, a, b, in[15] + 0xd8a1e681, 14);
MD5STEP(F2, b, c, d, a, in[4] + 0xe7d3fbc8, 20);
MD5STEP(F2, a, b, c, d, in[9] + 0x21e1cde6, 5);
MD5STEP(F2, d, a, b, c, in[14] + 0xc33707d6, 9);
MD5STEP(F2, c, d, a, b, in[3] + 0xf4d50d87, 14);
MD5STEP(F2, b, c, d, a, in[8] + 0x455a14ed, 20);
MD5STEP(F2, a, b, c, d, in[13] + 0xa9e3e905, 5);
MD5STEP(F2, d, a, b, c, in[2] + 0xfcefa3f8, 9);
MD5STEP(F2, c, d, a, b, in[7] + 0x676f02d9, 14);
MD5STEP(F2, b, c, d, a, in[12] + 0x8d2a4c8a, 20);

MD5STEP(F3, a, b, c, d, in[5] + 0xfffa3942, 4);
MD5STEP(F3, d, a, b, c, in[8] + 0x8771f681, 11);
MD5STEP(F3, c, d, a, b, in[11] + 0x6d9d6122, 16);
MD5STEP(F3, b, c, d, a, in[14] + 0xfde5380c, 23);
MD5STEP(F3, a, b, c, d, in[1] + 0xa4beea44, 4);
MD5STEP(F3, d, a, b, c, in[4] + 0x4bdecfa9, 11);
MD5STEP(F3, c, d, a, b, in[7] + 0xf6bb4b60, 16);
MD5STEP(F3, b, c, d, a, in[10] + 0xbebfbc70, 23);
MD5STEP(F3, a, b, c, d, in[13] + 0x289b7ec6, 4);
MD5STEP(F3, d, a, b, c, in[0] + 0xeaa127fa, 11);
MD5STEP(F3, c, d, a, b, in[3] + 0xd4ef3085, 16);
MD5STEP(F3, b, c, d, a, in[6] + 0x04881d05, 23);
MD5STEP(F3, a, b, c, d, in[9] + 0xd9d4d039, 4);
MD5STEP(F3, d, a, b, c, in[12] + 0xe6db99e5, 11);
MD5STEP(F3, c, d, a, b, in[15] + 0x1fa27cf8, 16);
MD5STEP(F3, b, c, d, a, in[2] + 0xc4ac5665, 23);

MD5STEP(F4, a, b, c, d, in[0] + 0xf4292244, 6);
MD5STEP(F4, d, a, b, c, in[7] + 0x432aff97, 10);
MD5STEP(F4, c, d, a, b, in[14] + 0xab9423a7, 15);
MD5STEP(F4, b, c, d, a, in[5] + 0xfc93a039, 21);
MD5STEP(F4, a, b, c, d, in[12] + 0x655b59c3, 6);
MD5STEP(F4, d, a, b, c, in[3] + 0x8f0ccc92, 10);
MD5STEP(F4, c, d, a, b, in[10] + 0xffeff47d, 15);
MD5STEP(F4, b, c, d, a, in[1] + 0x85845dd1, 21);
MD5STEP(F4, a, b, c, d, in[8] + 0x6fa87e4f, 6);
MD5STEP(F4, d, a, b, c, in[15] + 0xfe2ce6e0, 10);
MD5STEP(F4, c, d, a, b, in[6] + 0xa3014314, 15);
MD5STEP(F4, b, c, d, a, in[13] + 0x4e0811a1, 21);
MD5STEP(F4, a, b, c, d, in[4] + 0xf7537e82, 6);
MD5STEP(F4, d, a, b, c, in[11] + 0xbd3af235, 10);
MD5STEP(F4, c, d, a, b, in[2] + 0x2ad7d2bb, 15);
MD5STEP(F4, b, c, d, a, in[9] + 0xeb86d391, 21);
#endif

buf[0] += a;
buf[1] += b;
buf[2] += c;
buf[3] += d;
}

#endif

md5.h
code:
#ifndef MD5_H
#define MD5_H

#ifdef __alpha
typedef unsigned int uint32;
#else
typedef unsigned long uint32;
#endif

struct MD5Context {
uint32 buf[4];
uint32 bits[2];
unsigned char in[64];
};

void MD5Init(struct MD5Context *context);
void MD5Update(struct MD5Context *context, unsigned char const *buf,
unsigned len);
void MD5Final(unsigned char digest[16], struct MD5Context *context);
void MD5Transform(uint32 buf[4], uint32 const in[16]);

/*
* This is needed to make RSAREF happy on some MS-DOS compilers.
*/
typedef struct MD5Context MD5_CTX;

#endif /* !MD5_H */

Curts of your encryption whore, the privacy man himself. Now data man will have his slice of work to share wit me.

BTW, anyone notice kordik STILL hasn't posted that txt file I asked him to? Even if he lost/deleted it wouldn't you think he would let me know?

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Oh yeah, forgot to add, the output comes in the form of Little Endian format, which is really crazy and wack and it you try to look at it via the console or write it to a file it will look very cracked out and wrong. Open it in your fav hex editor and you'll see some actual base 16 numbers.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Ok, it ain't 100% done but most of the relevant code and algorithm is there with the MD5 checking. You can check it out on the CCC webspace (shouldn't we put something snazzy there?). I am wondering how/when to do the cert exchange (digital signature if you will) and what sort of format the digital signature should be. So I think a powow of some sort is in order. All are welcome to voice their input, not just mike and I.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
wow.... looking at that md5 source code makes my head hurt

(thats me voicing my input)

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Yeah, the actually hashing part is beyond me for the time being because I don't care to learn it if someone already has done it for me =)

Isn't that the mind of a programmer? NEVER do something that someone has already done, just borrow it.

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
Hey mike, when you finish up with the diffie hellman stuff, let me know how long it takes with the new prime and such. Between my desktop and laptop talking to eachother it is very quick and I have a sleep in the mix too. Seems quicker than before.

[ October 22, 2003, 04:40 PM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
What Huh Studios
Member
Member # 100

 - posted      Profile for What Huh Studios     Send New Private Message       Edit/Delete Post   Reply With Quote 
ya know... that is the mind of any programmer. i guess thats why we don't use assembly anymore... even if it is about 10 times faster than C

--------------------
http://www.whathuhstudios.com

Posts: 1687 | From: Villa park | Registered: Feb 2003  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
I thought it might interest people if I posted a type up that gives an overview of our encryption method. So here is what I whipped up: (note that the math operations in the first paragraph did not show up correctly on the boardix font)

CCC Encryption Overview
-----------------------

The encryption scheme is based around three main ideas. These are Diffie-Hellman, Cubix, and MD5 hashes.

-The Diffie-Hellman key agreement system is based upon the fact that cracking a Diffie-Hellman secret key is the equivalent of solving a discrete logarithm problem, which today there have been no shortcuts found. For all intents and purposes, with great minds having looked at discrete logarithmic problems, its safe to bet that an easy way does not exit. Quoted from RSA’s website “It assumes that it is computationally infeasible to calculate the shared secret key k = gab mod p given the two public values ga mod p and gb mod p when the prime p is sufficiently large.” So far this “assumption” has stood for longer than thirty years. Given this fact, Diffie-Hellman allows us to generate safe private keys to be used by the Cubix symmetric encryption algorithm.
-The Cubix symmetric encryption algorithm is unique and was created by Mike and I after staring at a Rubik’s cube during senior year in Highschool. We looked how hard it is to randomly solve a Rubik’s cube and to put it the best way I refer to a quote, “Sir Fred Hoyle, still an evolutionist, likens this (brute forcing a Rubik’s cube) to a blindfolded subject trying to solve the Rubik's cube. The blindfolded man has no way of knowing whether he is getting closer to the solution or actually farther away. According to Hoyle, if the blindfolded subject were to make one random move every second, it would take him on the average three hundred times the supposed age of the earth, 1.35 trillion years, to solve the cube.” That’s a huge amount of time and it looks like a low-ball estimate to me. Kordik had some numbers about the average number of turns, and it was something like 10^10^1000000000 which is enormous. So, given that the person trying to brute force crack the cube will not know if they are going in the right direction solving the cube would be almost impossible. Also, to add to the difficulty, the “cubix rube” as we so designated in our algorithm is actually a 3 dimensional array of the characters of the message being sent, with characters in the middle of the cube too, not just on the “skin”. This adds another level of difficulty, essentially having more small Rubik’s cubes in the middle. The data in the cube is also randomized in value by the private key so character analysis is not possible.
-To top it all off, in order to prevent identity theft a digital signature scheme was created. Using the “improved” or “extended” Diffie-Hellman key agreement method we have essentially done away with the man-in-the-middle problem, for this middle man would not be able to intercept the data, change it or insert mathematically weak keys, and pass it on in both directions. It is impossible. However, someone could simply impersonate another user for an entire session and this person would essentially be able to steal the message by spoofing the intended recipient. So to combat this, a digital signature method was derived using MD5 hashes. Simply put, when the encryption sequence begins, the encrypted message if the first thing sent to the recipient. He/She has no way to decrypt it, not even a public key. From this point, the recipient must take the encrypted message, “sign” it with his digital signature using the rubix method on top of the already encrypted message, and then take the hash of that output. This hash is then sent back to the sender and it is perfectly fine if anyone sees this hash because the digital signature is still hidden because of the fact that hashing is a one-way function, essentially, it cannot be reversed. So the sender receives this hash and he compares it to the hash of what he got when he signed his message with the digital signature of who he sent the message to. If these hashes do not meet, it can be assumed that the message was signed with an incorrect digital signature and the recipient was an imposter. From this, it is apparent that in order to communicate, the sender must know the digital signature of the receiver, and it also must be kept secret. This is similar to SSH in a sense.

The only weakness in the system that I see is having sides exchange digital signatures. This is the most key point to not allowing impersonation, the cracking part that is computationally easy. So, it must be assumed by each party that when they exchange digital signatures, they must be certain of the security of their link. The Diffie-Hellman and cubix algorithm by themselves is a suitable means to exchange digital signatures as long as each side is confident the link it not being tampered with.

[ October 23, 2003, 12:18 AM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged
bigO
He Who Knows All
Member # 7

 - posted      Profile for bigO     Send New Private Message       Edit/Delete Post   Reply With Quote 
oo time for lots of quoting...

quote:
Isn't that the mind of a programmer? NEVER do something that someone has already done, just borrow it.
Thank God that that is the mind of a programmer. Without that mindset, the STL wouldn't exist, and you'd be stuck doing string operations and stuff by hand. Pain.

There are cases where you should do something yourself, but that's called a learning experience. If you loves strings and wanna know all about them, code your own string class.

quote:
Hey mike, when you finish up with the diffie hellman stuff, let me know how long it takes with the new prime and such
A LONG FRICKEN TIME. Oddly, the LONG FREAKIN TIME is mostly ont ht receiving end, so there is a possibility that I could fix that. The sender only works for about 3 seconds, the receiver works for roundabouts 30 seconds.

quote:
The encryption scheme is based around three main ideas. These are Diffie-Hellman, Cubix, and MD5 hashes.
I love how you made up a nice little story about how we came up with the scheme. Hoyle. Priceless.

But we really should give Matt and Jared a little credit...they were there to initially propose a 3 dimensional ecryption system, which me and you then turned into the cubix rube.

quote:
The only weakness in the system that I see is having sides exchange digital signatures.
Not difficult that. We may as well do it like good ol SSH. If it's your first time talking to a guy, pop up a little thing saying, "Do you trust this connection?" Store it, and if it changes ever, give a warning. I reccommend having three options: Accept, Deny, and accept temporarily. That way if you aren't sure whether you can trust your "buddy", you can temporarily go into a session with him and ask security questions.
--On second thought, that defeats the purpose of even having a certificate...so lets discuss that...

--------------------
Anybody can be cool, but AWESOME takes practice.

Posts: 4522 | From: VP luv | Registered: Apr 2002  |  IP: Logged
SkyRat
Resident Director of Personal
Member # 10

 - posted      Profile for SkyRat     Send New Private Message       Edit/Delete Post   Reply With Quote 
I'll give credit to Matt, but Jared, pft thats out of the question. I'm positive Jared wouldn't even know a 3-dimensional cube if it bit him in the arse. Besides, he ain't ever going to read this so we would turn this thread into the thread about encryption and the thread about how much a dingbat Jared is =P

[ October 23, 2003, 09:55 AM: Message edited by: SkyRat[] ]

--------------------
 -  -
quote:
With the stupid limit on sigs my googlism won't fit!!


Posts: 2518 | From: BFH | Registered: Apr 2002  |  IP: Logged


 
Post New Topic  New Poll  Post A Reply Close Topic   Feature Topic   Move Topic   Delete Topic next oldest topic   next newest topic
 - Printer-friendly view of this topic
Hop To:

kordix.com

(C)2000-2011 The Boardix Community

Powered by Infopop Corporation
UBB.classicTM 6.5.0