Ian G wrote:
none of the above. Using SSL is the wrong tool
for the job.
For the one task mentioned - transmitting the username/password pair to the
server - TLS is completely appropriate. However, hash based verification would
seem to be more secure, require no encryption overhead on the channel at all,
and really connections and crypto should be primarily P2P (and not server
relayed) anyhow.
> It's a chat message - it should be
encrypted end to end, using either OpenPGP or
something like OTR. And even then, you've only
covered about 10% of the threat model - the
server.
yeah. you have a unencrypted interchange point - the server. There are aspects
to that which make it both a good and bad thing, mostly bad. for example you
allow interception at the server (may be a requirement for an american based
company, but still bad), and you provide a single point of failure for hackers
(very bad)
Most of the good aspects revolve around only having to support one client cert
you can embed in your own client (or make available on your website) and not an
entire PKI infrastructure.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
