When the client authenticates with our service, he is issued an opaque "token". This token includes the information, that identifies the client and some other information about the client ("payload"). The payload is used by the service, when the client passes the token back to the service on subsequent requests. The payload should not be disclosed to the client, so not only integrity must be maintained, but confidentiality too.
Here's what I was going to use for generating this token: - HMAC-SHA256 for integrity - AES in CBC mode for confidentiality
So, given payload P, keys K1 and K2 to generate the "token" I
- pad P to a multiple of 16
- generate IV of length 16
- encrypt P using AES with K1 and IV
- concatenate IV and encrypted P
- get a digest of the result (IV + encrypted P) using HMAC-SHA256 with K2 as a key
- concatenate digest with the result
Since IV and digest are of known length, no separators are needed. The padding will probably be done with spaces, since the format used for payload does not give significance to trailing spaces.
I must say, that I am not very much into security, so I might be missing some very obvious things. Anyway, the questions:
- Doing this seems very much like "rolling my own crypto". Am I reinventing the wheel here?
- Is there any added security in using separate K1 and K2, given that they will be stored "side-by-side"? If not, it will certainly be more convenient for me to use the same key
- ... well, did I miss anything?