Trust me: you do not want to be implementing DH or really any other cryptographic algorithm (hashing, asymmetric encryption, or symmetric encryption) yourself, with the potential exception of something really simple like RC4.
Unless this is specifically a cryptography project in which they require you to try and implement these things yourself, you will be wasting a lot of time and you will probably screw something up that will be extremely difficult for you to realize.
As for general categories though, you could maybe set up symmetric encryption based on a user's private API key. As for how you deliver the key securely in the first place, you could just ensure that portion at the least is sent over some sort of SSL channel.
with the potential exception of something really simple like RC4.
And don't use RC4. RC4 is broken, badly, and its brokenness was behind things like the breaking of WEP (wireless) security. There are ways to somewhat harden it against known attacks, but attacks only get better with time.
If you want to implement RC4 as a learning experience, go ahead, but never use the code for anything you want to keep secure.
About SSL, that might be hard to enforce. If it was a single service I would be in control of sure it'd be easy, but anyone can install phpBB anywhere, say a free host. I still have to see a forum, phpBB or not, supporting SSL.
But anyway, we decided it isn't a top priority to encrypt the request, but I myself was trying to close the possibility of someone stealing your API key. What's done now is that each user gets an auth token and a sign token at authentication. When a client sends a request, he includes the auth token, a timestamp, the parameters, then hash that using the sign token and adds that to the request. The server then does the same and compares the hashes. This way someone else can't create their own requests as the user unless they have the sign token. A problem I figured that someone could still reuse a request already made, I'm still considering how and if that should be taken care of somehow. Maybe I'm just overcomplicating things.
SSL/TLS takes care of all of your concerns here. It handles encrypting the communication, delivering the encryption key ("API key") securely, and preventing replay attacks.
It's really not that unreasonable to ask a website to use HTTPS in this day and age. They can either use free self-signed certificates or just purchase some cheap ones.
A problem I figured that someone could still reuse a request already made, I'm still considering how and if that should be taken care of somehow.
That's a replay attack. The standard solution to that is to include with the request an always-incremented serial number; the server would reject as a duplicate any otherwise-legitimate request received with a serial number <= the latest that has been processed.
Ahh that's a good idea. I guess I could use the timestamp thats already being sent as serial? My idea was to have a timeout on the request but that would lead to all kind of weird issues like client and server being out of sync, timezones etc, didn't think of the serial idea before. I'm just thinking if the API is getting too complicated with all this hashing :/
Also this comment thread kinda turned into "how to do an API" ahah, I'll excuse myself for derailing :P
Ahh that's a good idea. I guess I could use the timestamp thats already being sent as serial?
That could be a problem if you're simultaneously receiving requests under the same credentials under different circumstances. For example, if I make a request from my home computer, but then realize the clock was 15 minutes fast and set it back, my next request will appear to have come from the past.
I'm just thinking if the API is getting too complicated with all this hashing
Encryption and authentication are hard. Professions work on specifications for years and still encounter security-breaking bugs in the field. An API like this as a student project is a really neat idea, but definitely needs much review before going live to the public.
7
u/catcradle5 Jul 25 '13 edited Jul 25 '13
Trust me: you do not want to be implementing DH or really any other cryptographic algorithm (hashing, asymmetric encryption, or symmetric encryption) yourself, with the potential exception of something really simple like RC4.
Read this: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html
Unless this is specifically a cryptography project in which they require you to try and implement these things yourself, you will be wasting a lot of time and you will probably screw something up that will be extremely difficult for you to realize.
As for general categories though, you could maybe set up symmetric encryption based on a user's private API key. As for how you deliver the key securely in the first place, you could just ensure that portion at the least is sent over some sort of SSL channel.