How would one solve this? One solution seems to be to generate key for each user and store the public keys on the server. If there is need to access the images on the server, encrypt them with a server key and then re-encrypt with the recipients' public key. Are there some problems with this approach (like some functionality of snapchat wouldn't work with this)?
You could improve (but not solve) the problem of raw access to data. But that does nothing wrt solving the "problem" of recipients storing a permanent copy of received snaps -- all they need is a camera.
It's a little like the old (tv series) adage of don't discuss crime in a car -- it's easy to place a bug in a car, so assume that it's bugged, if you have reason to fear someone's bugging you. Even if you're using encrypted phone/voip-chat -- that won't help squat if there's a microphone in the vicinity that can pick up both ends of the conversation...
Comments
How would one solve this? One solution seems to be to generate key for each user and store the public keys on the server. If there is need to access the images on the server, encrypt them with a server key and then re-encrypt with the recipients' public key. Are there some problems with this approach (like some functionality of snapchat wouldn't work with this)?
You could improve (but not solve) the problem of raw access to data. But that does nothing wrt solving the "problem" of recipients storing a permanent copy of received snaps -- all they need is a camera.
It's a little like the old (tv series) adage of don't discuss crime in a car -- it's easy to place a bug in a car, so assume that it's bugged, if you have reason to fear someone's bugging you. Even if you're using encrypted phone/voip-chat -- that won't help squat if there's a microphone in the vicinity that can pick up both ends of the conversation...
More work. Since the users don't care about this breach anyway (which is why it hasn't been solved yet), it's not worth the developers' time.