I am creating an application which uses a steganography algorithm. Now I can encrypt and decrypt text. But I want my application to ask for password after encrypting the text into the image, so that whenever someone will decrypt the image it would ask for the password for authentication. Is this even possible? If yes, how?
Decrypt the text with a symmetric cypher like AES. To get the encryption key use a password based key derivation function (such as PBKDF2) on the password the user entered.
Then hide the encrypted text in your image using steganography.
strictly speaking, steganography isn't encryption, it's simply an encoding. If you want the encoded message to be truly encrypted, then use a trusted algorithm (don't be tempted to invent one!). as Andre suggests in another answer, AES would be fine.
Yes, it's possible. You can use any symmetric key algorithm, e.g. AES. But be sure the encoding/decoding isn't losing any bit.
I've used digital signature with QR codes before and it was changing some bits because it encoded them as ISO-8859-1. My solution was use Base64 before embed into the code. It required more space, but was safer.
Related
I'm making custom EncryptedSharedPreferences implementation, and I want to encrypt alias (key) in key/value store so the attacker has a hard time figuring out the values that are stored.
I'm Base64-encoding encrypted bytearray, and when I want to save it, it says that key is too long to have it stored.
Is there a way to shorten Base64 encoding, or to use some other way to make it work? Maybe something like the new EncryptedSharedPreferences from jetpack security library uses, it saves the alias (key) in shorter form, using Tink's deterministic crypto primitives, but how can I achieve that shorter encoding?
Thanks in advance!
Is it hard or easy to find a hard-coded encryption algorithm and password in a compiled delphi iOS and Android app? On Windows we have plenty of tool to disassemble Win32/Win64 compiled exe, but what about iOS and Android?
I want the app to perform some operations and send me the results, but I want to be (more or less) sure that the client will not alter the result himself. This why I think about let the app encrypt the result in such way that only the server app knows how to decrypt it. But if the client can be decompiled easily then off course he can send me anything he wants, if he know how to encrypt the data
On iOS obtaining an embedded password is difficult but not impossible. iOS can not be decompiled but a debugger can be attached to a loaded app and the executing object code examined.
The encryption algorithm does not need to be secret and making it secret does not provide additional security.
RSA is not suitable for data encryption because the data size is limited to less than the key size and it is very slow. For data encryption AES is the preferred method with no size limitation and it is fast.
I am new to android development ,My question is can i search encrypted string in encrypted file .In brief when i give a search term first it is encrypted and searches for the required term in encrypted file.I searched google but find nothing in java or android one related what i found is:
Encrypted Search
If you can I would suggest decrypting the data, storing it in memory, and disposing of it when finished. If that option isn't available I would suggest looking into Homomorphic encryption. The algorithm was developed by some IBM guys but is still highly experimental and only advised for research. Hope this helps!
It definitely depends on the encryption you are using. As Zack Matthews mentioned, there is Homomorphic encryption designed to make this and other operations on encrypted information possible. But for simpler, more common types of encryption, it is not that simple. Even in ECB mode (which is not secure precisely because it has the property you are looking for in a limited sense) block ciphers like AES, Twofish, and Serpent, which usually have 128 bit blocks, but sometimes 64 bit, will have the same plain text yield the same cipher text only if every byte in that 16 byte block is identical to the bytes you are looking for. Flip one bit in the plain text, and the cipher text will be different throughout the entire block.
It gets worse with CBC mode. This mode has an XOR feedback which virtually guarantees the same plain text will never yield the same cipher text, even if that plain text appears repeatedly in the same document.
I want to develop a simple encryption application for android. Which algorithm should I use to encrypt all data types such as images, office documents, multimedia, etc and why its a good one?
Does AES covers all types of data ?
AES can encrypt any data that can be represented as a sequence of bytes, so it can encrypt all types of data.
AES has been through a great deal of testing, and nobody has broken it yet. Pretty much every encryption library will include AES, including both Bouncy Castle and Spongy Castle for Android. AES is the standard and is your first choice, unless you have specific reasons for not using it.
Use it in either CBC mode with PKCS7 padding or CTR mode. Yes, if you don't know you will need to learn a bit about block cypher modes and cryptographic padding.
For authentication, if you require it, either use HMAC-SHA256 or GCM mode, which includes authentication.
Yes, I believe you can encrypt everything you want with AES. Just treat all data types as a stream of bytes. No problem here.
I have to encrypt a list containing three fields for each record (a tag, a username and a password).
Those will be saved in a JSON structure and then written to storage.
My question is, should I encrypt the whole file or should I encrypt the single fields, convert the encrypted strings to Base64 and put those encrypted fields in the JSON file?
Considering I don't expect the file to become very big (say, less then a MB), that I'll always be reading it as a whole and that the target platform is Android, what is the best approach in terms of performance and security?
Encryption is significantly weakened if you're encrypting less than an entire block at once. So encrypt the whole file.
I recommend encrypting the entire file. If you encrypt field by field, then an attacker will see that the data is an array of (tag, username, password). That already exposes part of your data structure and weakens the encryption. Encrypting and decrypting the entire file might even be faster than doing each field separately, although for the sizes you are talking about I don't think that's an issue.
In general you should encrypt the entire file. However if you are using a poor implementation then this can work against you. For instance if you use a stream cipher like RC4 and you reuse the key, then the file structure can be used against you by revealing sections of the prng stream. This was used in the WEP attack. But the problem here is the weak implementation.
In short use CBC or CMAC mode with a random IV and Blowfish or AES-256 with an s2k function or random key. Also keep in mind that there is no place to hide a secret key on the android or iphone without the user being able to access it.