Encryption on Android is not fundamentally different than on any other Java SE platform. And as all the answers below are insecure, for either you have to understand cryptography before you start implementing or borrowing cryptography examples.
– Maarten BodewesJun 10 '14 at 20:47

Hey this not works for me, I am getting Badpadding exception while decrypting the same.
– Sanat PandeyNov 18 '11 at 13:40

34

WARNING This code is using known bad code from Android snippets for key derivation. Don't use it unless you want to loose your data. A seeded RNG is not a good Key Derivation Function (KDF).
– Maarten BodewesJun 9 '14 at 16:42

WARNING This code is using known bad code from Android Snippets for key derivation. Don't use it unless you want to loose your data. A seeded RNG is not a good Key Derivation Function (KDF).
– Maarten BodewesJun 9 '14 at 16:42

True this derivation is much better. But now you're using a static IV, a static salt and a way too low iteration count. So withou warnings the result is still insecure. Crypto is a pain to get right...
– Maarten BodewesMar 30 '18 at 13:00

Rather than using the Apache Commons Codec library, is there any disadvantage using android.util.Base64.encode(bytes, Base64.DEFAULT) and android.util.Base64.decode(decryptedData, Base64.DEFAULT)?
– ban-geoengineeringJun 29 '16 at 15:36

1

WARNING This code is using known bad code from Android Snippets for key derivation. Don't use it unless you want to loose your data. A seeded RNG is not a good Key Derivation Function (KDF). (sigh).
– Maarten BodewesOct 13 '17 at 8:11

WARNING This code is using a key derivation mechanism that uses the default character decoding. Don't use this unless you want to have problems decrypting your data.
– Maarten BodewesJun 9 '14 at 16:44

3

@owlstead, good observation, it would have been nice if you had suggested the fix. The example above has now been updated to specify a character encoding in getKey(). Further corrections are welcome...
– SoloPilotJun 10 '14 at 19:43

9

Sorry, I was mainly burning answers here, because they used SecureRandom for key derivation. If you want to know how to instantiate a cipher, check ericksons's answer here. Don't use a static IV (for the same key), and use PBKDF2 for password -> key conversion. Note that a non-authenticated cipher only provides confidentiality, and only if it is not used in a transport protocol. If you want to help, you can burn the other answers too (and vote up my comments there) :)
– Maarten BodewesJun 10 '14 at 19:51

@MaartenBodewes you "burned" many answer, but you dont propose an answer. If you have correct answer, why dont you write one here?
– DikaApr 25 at 4:23

@Dika I think I pointed an answer out above. Please do keep in mind that I'm with a very large margin the guy that posts the most answers on both cryptography and encryption. Also keep in mind that I'm rather opposed against generic wrapper libraries that simply lead people to copy code rather than write code themselves for a specific use case. The Java crypto API is rather well thought out, if a bit cumbersome. Use that! There is nothing special about image encryption; it's basic file encryption.
– Maarten BodewesApr 25 at 10:50

Could you expand a bit how this library can be used to solve the problem ? Just copying the GitHub description and adding a link to it is not all that helpful, and your answer could be a lot better with some explanation.
– JonasCzMar 29 '16 at 17:36

I don't think you need Bouncy for this; it will only make sure that you cannot use hardware acceleration and kill performance for large files (such as images). Encoding the key in base 64 is bad idea; storing it in a key store is much better.
– Maarten BodewesMar 30 '18 at 13:03

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).