AniDB

Talk:UDP API DEV: Difference between revisions

Page Discussion

Talk:UDP API DEV (view source)

Revision as of 13:50, 25 December 2007

1,047 bytes added ,  25 December 2007
no edit summary
No edit summary
No edit summary
Line 9: Line 9:
:: I have posted something in the forum now: http://www.anidb.net/forum/viewtopic.php?t=2328&start=45. You can use that if you want. --[[User:Epoximator|Epoximator]] 13:58, 28 Oct 2005 (CEST)
:: I have posted something in the forum now: http://www.anidb.net/forum/viewtopic.php?t=2328&start=45. You can use that if you want. --[[User:Epoximator|Epoximator]] 13:58, 28 Oct 2005 (CEST)


== Encodings  ==
== Encryption ==
Protocol 2 says that the current character encoding is “unknown.” Shouldn't this be defined, preferably to some Unicode, like UTF-8? Considering AniDB maintains data in several languages, isn't having an agreed-upon encoding important? [[User:Derobert|Derobert]] 01:35, 14 November 2005 (CET)
 
: I guess it's ok to set this to ASCII now. All non ASCII chars should be html escaped. --[[User:Epoximator|Epoximator]] 11:40, 27 January 2006 (CET)
"encryption pass must be set in profile settings on the website"
 
for this to be really useful for all the paranoid ppl out there, you should really change the website to https. luckily for me, I'm not paranoid about this, but I thought it should be pointed out. --[[User:Suppy|Suppy]] 06:41, 27 January 2006 (CET)
 
: https is concidered a possible performance issue and is therefore currently not supported by anidb. if I have too much time I might write something up which allows only the signup, login and profile pages to be transmitted via https and everything else via http. does anyone know if there is a good howto somewhere on how to best set this up? (i could always hardcode these limitations, but there should be a better way)
: And the main reason for this feature is the usage of clients over untrusted connections. Which is possible once you configured your client password via a trusted connection.
:--[[User:Exp|Exp]] 06:58, 27 January 2006 (CET)
 
=== 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)
 
: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)
 
:Well, the actual implementation by epoximator will define the exact encryption type and the API documentation will be updated to reflect this. I agree with pelican to a certain extend. The security needs of AniDB can be viewed as being rather limited. As such TLS seems like an overkill (especially since it brings quite some additional performance and bandwidth overhead). And even the very basic AES encryption will be disabled by default. And yes, replay attacks will be possible, but the damage an attacker can do with those should be limited. I'll add a small change to the protocol which will make replay attacks slightly more complicated, but still not impossible. The encryption should be kept as simple as possible in order to minimize the additional overhead.
:And even a very basic AES encryption will be enough to prevent the password from being snooped while it is transmitted. I.e. in unsecured wireless network environments.
:--[[User:Exp|Exp]] 04:55, 30 January 2006 (CET)
 
::If TLS really is too much overhead, I'd suggest using ESP (from IPSec) with static keying (so you don't need the additional complexity of IKE). You can encapsulate that in a UDP packet, instead of IP proto 50.
::I think, if you're going to give users a "secure" checkbox, it really ought to be secure. The best way to accomplish that is to use a well-understood, well-studied security protocol instead of inventing yet another. The "invent yet another" security protocols all too often turn out to be completely insecure.
::BTW: If you're just trying to prevent password sniffing, there are already several well-studied HMAC-based protocols which do that, and do it with minimal overhead. Low enough that you could probably just use it by default.
::—[[User:Derobert|Derobert]] 14:56, 30 January 2006 (CET)


== Done ==
=== ANIME ===
=== ANIME ===
I'd like this command to cope with a couple of different encodings when passed a title, and be explicit over whether it finds only one result or does a best-match guess. --[[User:Rar|Rar]] 04:51, 30 Oct 2005 (CET)
I'd like this command to cope with a couple of different encodings when passed a title, and be explicit over whether it finds only one result or does a best-match guess. --[[User:Rar|Rar]] 04:51, 30 Oct 2005 (CET)
Line 25: Line 48:


=== ENCODING ===
=== ENCODING ===
Protocol 2 says that the current character encoding is “unknown.” Shouldn't this be defined, preferably to some Unicode, like UTF-8? Considering AniDB maintains data in several languages, isn't having an agreed-upon encoding important? [[User:Derobert|Derobert]] 01:35, 14 November 2005 (CET)
: I guess it's ok to set this to ASCII now. All non ASCII chars should be html escaped. --[[User:Epoximator|Epoximator]] 11:40, 27 January 2006 (CET)
This could be included in the AUTH command or an environment command that includes options for encryption, encoding and compression. (In response to rar's request.) --[[User:Epoximator|Epoximator]] 11:48, 31 January 2006 (CET)
This could be included in the AUTH command or an environment command that includes options for encryption, encoding and compression. (In response to rar's request.) --[[User:Epoximator|Epoximator]] 11:48, 31 January 2006 (CET)
: This should definetly become an additional, optional parameter of the AUTH command. There is really no reason why this should be an extra command. It just means two more UDP packets overhead on each client connection. --[[User:Exp|Exp]] 05:28, 8 February 2006 (CET)
: This should definetly become an additional, optional parameter of the AUTH command. There is really no reason why this should be an extra command. It just means two more UDP packets overhead on each client connection. --[[User:Exp|Exp]] 05:28, 8 February 2006 (CET)
:: I think epoxi was more thinking of this command as setting a session state flag, like a parameter in AUTH would, rather than being sent prior to *every* command, which would of course be silly. I see no reason not to have both. --[[User:Rar|Rar]] 16:21, 10 February 2006 (CET)
:: I think epoxi was more thinking of this command as setting a session state flag, like a parameter in AUTH would, rather than being sent prior to *every* command, which would of course be silly. I see no reason not to have both. --[[User:Rar|Rar]] 16:21, 10 February 2006 (CET)


== FILE ==
=== GROUP ===
I obtain: '41|851|665|109|1004|Zhentarim DivX|zx|#zhentarim|irc.chatsociety.net|http://www.zhentarim.net/'
The irc channel and irc server are on two fields, and this is not documented. --[[User:Darsh|Darsh]] 12:14, 28 April 2006 (CEST)
: Updated doc --[[User:Epoximator|Epoximator]] 20:52, 28 April 2006 (CEST)
 
=== FILE ===
Pass a list of fields (limit e.g. 10 entries)
Pass a list of fields (limit e.g. 10 entries)
and return content. This makes it possible to request new fields in the database without
and return content. This makes it possible to request new fields in the database without
Line 43: Line 74:
Add {str anidbfilename} to fcode?  --[[User:Darsh|Darsh]] 10:56, 25 April 2006 (CEST)
Add {str anidbfilename} to fcode?  --[[User:Darsh|Darsh]] 10:56, 25 April 2006 (CEST)
: ok. bit 30 @ fcode --[[User:Epoximator|Epoximator]] 21:34, 28 April 2006 (CEST)
: ok. bit 30 @ fcode --[[User:Epoximator|Epoximator]] 21:34, 28 April 2006 (CEST)
== Encryption ==


"encryption pass must be set in profile settings on the website"
=== EP ===
Also return airdate --[[User:Tesiph|Tesiph]] 11:27, 17 December 2007 (CET)
: done. --[[User:Epoximator|Epoximator]] 14:50, 25 December 2007 (CET)


for this to be really useful for all the paranoid ppl out there, you should really change the website to https. luckily for me, I'm not paranoid about this, but I thought it should be pointed out. --[[User:Suppy|Suppy]] 06:41, 27 January 2006 (CET)
=== MYLIST ===
Add support for the 'type' field (original/corrupt/self edited/other) --[[User:Tesiph|Tesiph]] 11:33, 17 December 2007 (CET)
: done. --[[User:Epoximator|Epoximator]]


: https is concidered a possible performance issue and is therefore currently not supported by anidb. if I have too much time I might write something up which allows only the signup, login and profile pages to be transmitted via https and everything else via http. does anyone know if there is a good howto somewhere on how to best set this up? (i could always hardcode these limitations, but there should be a better way)
=== MYLISTDEL: Delete file from mylist ===
: And the main reason for this feature is the usage of clients over untrusted connections. Which is possible once you configured your client password via a trusted connection.
Feature request: It'd would be neat if i could delete files from MYLIST using the file's hash and size like the MYLISTADD command. I'm writing a client that doesn't use lid or fid, only size and ed2k hash for all files. I could use the FILE function to obtain the fid, but that would be an unwanted extra step.
:--[[User:Exp|Exp]] 06:58, 27 January 2006 (CET)


=== Crypto Protocol ===
'''Command String:'''<br />
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)
by size+ed2k hash:
* MYLISTDEL size={int4 size}&ed2k={str ed2khash}


: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.)
'''Possible Replies:'''
:...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.
* 211 MYLIST ENTRY DELETED
:--[[User:Pelican|Pelican]] 20:45, 28 January 2006 (CET)
: {int4 number of entries}
 
* 411 NO SUCH MYLIST ENTRY
:Well, the actual implementation by epoximator will define the exact encryption type and the API documentation will be updated to reflect this. I agree with pelican to a certain extend. The security needs of AniDB can be viewed as being rather limited. As such TLS seems like an overkill (especially since it brings quite some additional performance and bandwidth overhead). And even the very basic AES encryption will be disabled by default. And yes, replay attacks will be possible, but the damage an attacker can do with those should be limited. I'll add a small change to the protocol which will make replay attacks slightly more complicated, but still not impossible. The encryption should be kept as simple as possible in order to minimize the additional overhead.
:And even a very basic AES encryption will be enough to prevent the password from being snooped while it is transmitted. I.e. in unsecured wireless network environments.
:--[[User:Exp|Exp]] 04:55, 30 January 2006 (CET)
 
::If TLS really is too much overhead, I'd suggest using ESP (from IPSec) with static keying (so you don't need the additional complexity of IKE). You can encapsulate that in a UDP packet, instead of IP proto 50.
::I think, if you're going to give users a "secure" checkbox, it really ought to be secure. The best way to accomplish that is to use a well-understood, well-studied security protocol instead of inventing yet another. The "invent yet another" security protocols all too often turn out to be completely insecure.
::BTW: If you're just trying to prevent password sniffing, there are already several well-studied HMAC-based protocols which do that, and do it with minimal overhead. Low enough that you could probably just use it by default.
::—[[User:Derobert|Derobert]] 14:56, 30 January 2006 (CET)


== Errors / bugs ==
--[[User:Antennen|Antennen]] 15:16, 9 August 2007 (UTC)<br />
=== GROUP ===
: done a long time ago, just not documented.. --[[User:Epoximator|Epoximator]] 14:50, 25 December 2007 (CET)
I obtain: '41|851|665|109|1004|Zhentarim DivX|zx|#zhentarim|irc.chatsociety.net|http://www.zhentarim.net/'
The irc channel and irc server are on two fields, and this is not documented. --[[User:Darsh|Darsh]] 12:14, 28 April 2006 (CEST)
: Updated doc --[[User:Epoximator|Epoximator]] 20:52, 28 April 2006 (CEST)
Epoximator
546

edits

Retrieved from "https://wiki.anidb.net/Special:MobileDiff/8721"
MediaWiki spam blocked by CleanTalk.
MediaWiki spam blocked by CleanTalk.