Should I first encode my encrypted text with base64 to store it in a database? It will be larger when I encode it but is better or faster to decrypt it?
(Especially for Rijndael and RSA encrypted data.)
No, you don't need to encode your ciphertext using base64 encoding. You should encode your ciphertext only if your field just accepts text values. Speed is normally not an issue as cryptographic algorithms are much slower than the conversion from or to base64.
If I understood you correctly than you do not need to encode with base64 before storing it in the database. If you use a proper database than you can just store the raw bytes. Base64 is good for transferring binary data over text-only media but, it also enlarges data by roughly 33%. It would not make it faster because you actually need to do two steps now: decode and than decrypt, instead of decrypting it immediately.
Related
for a private research project I wonder if its possible to decrypt SHA256 encrypted strings without having the key and just have Examples of encrypted and decrypted strings.
As an example, I have 1000 Strings as decrypted text and I have the 1000 Strings encrypted. Can't this information be used to decrypt those strings?
I just want to give notice, that I totally do not have any clue about cryptographie and I am sorry if my questions sounds to newbie.
Best regards,
Heini
As an example, I have 1000 Strings as [original] text and I have the 1000 Strings [hash]. Can't this information be used to [identify] those strings?
Sure. Hash each string, and write down "this string went to that hash", or, write it the other direction so you can look up a possible original string from a hash value. You've just created a small rainbow table.
I wonder if its possible to decrypt SHA256 encrypted strings without having the key
SHA-256 is a digest algorithm, not an encryption algorithm (as Ebbe M. Pedersen pointed out in a comment). Digest algorithms don't have keys, and are designed to not be reversible (and even though no collisions are currently known for SHA-256, they're guaranteed to exist by the pigeon-hole principle... so there's no one right answer).
Protocols/processes/algorithms utilizing digest algorithms will often add a salt when hashing, but that's different than a key. The purpose of the salt is to 'defeat' rainbow tables... since you need a new table for every different salt.
well i have a project, but i didn't dive so deep into cryptography, here is my problem:
i want to generate a keystream based on a two input: a string and a 'file-size'
it's like if i have an input with a string = 'abcd' and a file with size of '10kbytes', the generated keystream will have a size of 80 kbytes, but if the file is '5kbytes' then the keystream size is 40kbytes
anyone know if there is some algorithm like this so i can learn more about this, or this is imposible / not exist?
This answer is very basic cryptography, and may not be secure. I assume this is a learning exercise, not for real use. To learn more, read about stream ciphers, which generate a keystream.
First you need a key. Since the key must be unique for each file, you will need to use a counter. Concatenate your filename, file size and counter into a single string: "abcd-10kbytes-count0000001". Keep track of your counter value and increment it each time you encrypt a file.
You now need to hash your concatenated string. Your system may provide a secure hash like SHA256 or SHA3. If it does then use one of them to produce a 256 bit key. If you have to code the hash yourself, then try something much simpler to code, though insecure, such as FNV hash with 256 bit output. The hash output is your encryption key. Save it in a secure place, you will need it later for encrypting and decrypting the file. Each file will have a different key.
For the stream cipher itself you can use AES-CTR (AES in counter mode) if it is available on your system. If not, then code a much simpler stream cipher, like RC4. This is obsolete and insecure but very easy to code.
AES-CTR and RC4 both produce a stream of bytes. To encrypt the file, XOR the file with the keystream, byte by byte. To decrypt the file, use the same key and again XOR the encrypted file with the keystream byte by byte.
If you find problems then ask again, showing your code with the problem.
I'm building a client (C#)/server (PHP) application in which the server signs a message with RSA and the client verifies the message. So far so good.
I'm using HTTPS/JSON as protocol for the communication and therefore I have to encode binary data in the message as base64.
My question here is: What's best practice? To sign the base64 encoded data or the original binary data?
Are there any positives or negatives for doing one of them?
King regards.
My question here is: What's best practice? To sign the base64 encoded data or the original binary data?
At the end - it doesn't matter. The signature ensures integrity of the signed data regardless they are encoded or not.
I'm writing an application that will require the following security features: when launching the CLI version, you should pass some key to it. Some undefined number of chunks of data of the same size will be generated. It needs to be stored remotely. This will be a sensitive data. I want it to be encrypted and accessible only by that one key that was passed to it initially. My question is, which algorithm will suit me? I read about AES but it says that
When you perform an encryption operation you initialize your Encryptor
with this key, then generate a new, unique Initialization Vector for
each record you’re going to encrypt.
which means I'll have to pass a key and an IV, rather than just the key and this IV should be unique for each generated chunk of data (and there is going to be a lot of those).
If the answer is AES, which encryption mode is it?
You can use any modern symmetric algorithm. The amount of data and how to handle your IVs is irrelevant because it applies no matter which symmetric algorithm you pick.
AES-128 is a good choice, as it isn't limited by law in the US and 128 bits is infeasible to brute force. If you aren't in the US, you could use AES-256 if you wanted to, but implementations in Java require additional installations.
You say you are going to generate n many chunks of data (or retrieve, whatever).
You could encrypt them all at once in CBC mode, which keeps AES as a block cipher, and you'll only end up with one IV. You'll need an HMAC here to protect the integrity. This isn't the most modern way, however.
You should use AES in GCM mode as a stream cipher. You'll still have one single IV (nounce) but the ciphertext will also be authenticated.
IVs should be generated randomly and prepended to the ciphertext. You can then retrieve the IV when it is time to decrypt. Remember: IVs aren't secret, they just need to be random!
EDIT: As pointed out below, IVs should be generated using a crypto-secure random number generator. IVs for CTR based modes, like GCM, only need to be unique.
In summary, what you are worried about shouldn't be worried about. One key is fine. More than one IV is fine too, but there are ways to do it with just one. You will have to worry about IVs either way. Don't use ECB mode.
I am new to security issues. I am trying to implement some basic (limited) protection of intellectual property in an android app by encrypting text assets. To do this, I have implemented the SimpleCrypto class described by S.Saurel here http://www.ssaurel.com/blog/how-to-use-cryptography-in-android-applications-2/. I plan to encrypt the data using a separate program and include the encrypted data as assets files, then decrypt them for use in the app. My question is what is the best practice for dealing with the SALT string and SEED string that are needed to decrypt the files? Should they be generated at run time or stored somehow? Should they be included in the crypto class, or generated elsewhere in the app and passed to the crypto class?
Thanks in advance!
In this implementation "seed" is what you would think of as "password", and since you're not going to ask the user to provide a password, you can hardcode it, or store it in a file, or request it from a server at runtime, or whatever else. Be aware that a smart attacker will most likely be able to get at this password and use it to generate their own decryption key for your ciphertexts.
Salt is a non-secret value that acts as an initialization vector for encryption. Best-practice would dictate that you generate a random salt per cleartext, then provide the ciphertext and unencrypted seed to the client. The IV is typically dependent on the block size of your cipher used, and in your example there you're generating a 256-bit key, so you should generate a random 256-bit (64-byte) salt per cleartext and ship it with the ciphertext. You could do something as simple as producing a final string which is:
[2 bytes indicating length of salt][salt][ciphertext]
Then from that you can get your seed and ciphertext for decryption.