524
edits
Talk:UDP API DEV: Difference between revisions
→Crypto Protocol
m (→Encryption: add sub-heading to clarify the two parts are talking about different things) |
|||
| Line 27: | Line 27: | ||
=== Crypto Protocol === | === Crypto Protocol === | ||
The encryption specified in the protocol is poorly defined. AES is just a cipher, not a protocol; there are critical details missing, like the type of chaining being done; if its being used in stream or block mode; how replay prevention and other Mallory attacks are to be prevented; etc. Consider using an existing, well-understood crypto protocol. TLS comes to mind. [[User:Derobert|Derobert]] 02:22, 28 January 2006 (CET) | The encryption specified in the protocol is poorly defined. AES is just a cipher, not a protocol; there are critical details missing, like the type of chaining being done; if its being used in stream or block mode; how replay prevention and other Mallory attacks are to be prevented; etc. Consider using an existing, well-understood crypto protocol. TLS comes to mind. [[User:Derobert|Derobert]] 02:22, 28 January 2006 (CET) | ||
:Technically the suggested (this page is not the actual specification, it's for proposals) encryption sceheme is, in fact, perfectly well defined if you presume that messages can be padded beyond the end of the one line they are allowed to contain to a multiple of the block length (128 bits). However, it isn't very useful as a security measure because of the obvious vulnerability you point out: replay attacks. (This means that you can just parrot encrypted packets and they'll decrypt to the same plaintext. So while you can't get the user's password, you can authenticate yourself as a user whose traffic you've monitored.) | |||
:...but in reality, there's no need for AniDB to be a secure application. Best to just forget about encryption altogether; it's far more trouble than it's worth in this case. | |||
:--[[User:Pelican|Pelican]] 20:45, 28 January 2006 (CET) | |||