Hi, > could have sworn I attached it (also, finally fixed it this morning, > found a javascript version, so I compared our variables each > iteration).
Ah! Perhaps I didn't get it because I'm set up for digest rather than individual mails. > (originally planning on md5, but sha2 sounded like a more secure > solution. ) Yeah. With SHA the hash is unlikely to be the weakest part of your solution as a whole. > I wanted to use it for client/server login's between 2 C programs. > Looks like doing some research on hmac-sha256 would have some benefit. Perhaps you might enjoy reading up on some of the other worse or better designed password negotiation algorithms such as CRAM-MD5 / LOGIN / PLAIN / LANMAN, etc. Cyrus SASL (whilst a complete pain to actually install and use) has implementations and documentation around almost all of the common ones. > Fingerprints on files, sha256 should serve this fine. Agreed. Tiger is also a good one for this. > also tossing around the idea of doing a hash on each packet (something > quick & simple). A way to identify it was most likely something I > should process. [or put some pattern into the packet...]. That way, > if some random program like firefox connected to the server, then It > is aware of it. Not sure if a hash is good, or if I should just toss > in a pattern like 0xa8e2 in the packet as a fingerprint. Magic numbers (such as 0xa8e2) are often used to signal proposed validity so that's a good approach to the problem of initially filtering packets. Once you've received your packet you might want to determine whether it's corrupt. A CRC is more suited to that task than a cryptographic hash. They don't have non-reversible cryptographic properties but they're designed to be fast and their outputs small. http://en.wikipedia.org/wiki/Cyclic_redundancy_check The FNV (non cryptographic) hash may also be worth a look http://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function > wonder if there is a way around sending the key from the server to the > client... (This key would be unique for each client, discarded when > logged out). My main concern is that the password cannot be generated > from the data sent from the client to the server. See the note about regarding password negotiation algorithms. Regards, @ndy -- [email protected] http://www.ashurst.eu.org/ 0x7EBA75FF -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
