Re: lfs-chat Digest, Vol 1200, Issue 1

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