I have an existing set of Python code that uses the primitive (textbook) RSA encryption mechanism to encrypt small pieces of data. Specifically, the python code loads a public key into variable publickey and then encrypts this data using the following code:
ciphertext = publickey.encrypt(plaintext,None)
Yes I have read the disclaimer that "this function performs the plain, primitive RSA encryption (textbook). In real applications, you always need to use proper cryptographic padding,..." Unfortunately, I cannot change this code at the present time, so I am stuck with using this "textbook" encrypt command.
Note that even though this command does not use any padding scheme, it still seems to be able to encrypt any (appropriately small) amount of plaintext. In other words, the plaintext can be any length up to whatever limit is imposed by RSA.
Now however, I want to use the OPENSSL C library in an IOS app to do an identical RSA encryption. I cannot figure out how to do the exact same thing that the python function is doing. OPENSSL has a method RSA_public_encrypt where you pass in the size of the plaintext, the plaintext itself, an RSA object pointer which contains public key information, and the RSA padding mechanism. To replicate what python is doing in the crypto library, I thought I could use RSA_NO_PADDING as the padding mechanism. The problem is that OPENSSL states in their documentation that if you use RSA_NO_PADDING, then the length of the plaintext to encrypt must be EXACTLY equal to a certain value: RSA_Size(rsa) where rsa is a pointer to the RSA object passed in (the object that contains the public key).
In other words, the python crypto library seems to be able to encrypt variable length plaintext with no padding, but OPENSSL requires plaintext to be fixed length. So what exactly is the python crypto library doing to handle the variable size of the plaintext, and is there any way I can replicate this in OPENSSL?
If you look at the documentation for RSA_NO_PADDING, they explain:
This mode should only be used to implement cryptographically sound
padding modes in the application code. Encrypting user data directly
with RSA is insecure.
In other words, RSA_NO_PADDING is for cases where you're going to handle padding on your own, so OpenSSL expects an input of the proper size. It doesn't mean "textbook RSA".
Is there a compelling reason you can't change the python code? Textbook RSA is insecure and you're taking a great risk by using it.
Related
I have an AES-encrypted string ( out of a user backup of a discontinued App) that I want to decrypt.
What I have:
json file with:
Info that key was created with PBKDF2
salt
encrypted string
I do know the password, with which the backup was created, probably the password also for PBKDF2
Is there a way to find out with what parameters the string was encrypted? i.e, how the key was created
Is there an easy way to decrypt the string?
Fortunately, reverse engineering the encryption method and the way that the ciphertext (and possibly other information necessary for decryption) is stored in the file, is a lot easier than trying to crack the password that was used to derive the encryption key. Being that you know the password that the key was derived from, there may be hope.
Is the encrypted string from the json file encoded using an encoding method that you recognize, such as hexadecimal or base64? If so, then when you decode the encrypted string, is it exactly 128 bits?
If so, then the problem gets significantly simpler, because this means that it's only one block of AES encryption. This means that you don't have to worry about the encryption mode (e.g. CBC, GCM, ECB, CTR, etc), or the IV if it's a block cipher mode such as CBC.
In addition, if there is information in the json file about the inputs to the PBKDF2 function (e.g. number of iterations, and/or hash algorithm), this can be helpful.
In the end, it comes down to trial and error, where different values for the parameters that you don't know are tried, until the correct parameters to the PBKDF2 function are found, which produces the correct key, to decrypt the cipher text. This also requires that you know something about the plaintext, in order to know when the decryption was successful.
Of course, the more parameters that unknown, the more rounds of trial-and-error are necessary. If the number of rounds of trial and error are reasonable given an allotted amount of time and resources, then the process can be automated in a fashion similar to https://security.stackexchange.com/questions/226935/write-a-python-or-c-program-to-guess-the-key/226950#226950.
Hi i have created an RSA encryption using Java that so far only encrypts and decrypts BigIntegers and would like to make it so that it can also do the same for other characters, i have a feeling that i would have to convert everything into Ascii (if this is even possible) to then encrypt but no idea how.
i would have to convert everything into Ascii
consider encryption as converting a byte array to a different byte array (even BigInt is represented as a byte array)
Still I see several issues:
You are implementing your own textbook RSA (no padding, no mitigation for side-channel attacks) and this approach is really really not secure. It's ok to do it for learning purposes (even I'd object) , but not for any real life secure encryption.
RSA is secure (when used properly) to encrypt a fixed block of data. If you want to use RSA to encrypt data of any length, you may use hybrid encryption (use symmetric encryption with a random key to encrypt data and RSA to encrypt the key)
you may have a look at my blog for that
https://gusto77.wordpress.com/2017/10/30/encryption-reference-project/
I have a tcl/tk based tool, which uses network password for authentication. Issue is that, it is saving password in the logs/history. So objective is to encrypt the password.
I tried to use aes package. But at the very beginning aes::init asks for keydata and initialization vector (16 byte). So how to generate IV and keydata. Is is some Random number? I am a novice in encryption algorithms.
If you have the password in the logs/history, why not fix the bug of logging/storing it in the first place?
Otherwise there are distinct things you might want:
A password hashing scheme like PBKDF2, bcrypt, argon2 etc. to store a password in a safe way and compare some user input to it. This is typically the case when you need to implement some kind of authentication with passwords on the server side.
A password encryption and protection scheme like AES. You need a password to authenticate to some service automatically, and it requires some form of cleartext password.
You have some secret data and need to securly store it to in non cleartext form.
If you have case 1, don't use the aespackage, it is the wrong tool for the job. If you have case 2, the aes package might help you, but you just exchanged the problem of keeping the password secret with the other problem of keeping the key secret (not a huge win). So the only viable case where aes is an option might be 3.
Lets assume you need to store some secret data in a reversible way, e.g. case 3 from above.
AES has a few possible modes of operation, common ones you might see are ECB, CBC, OFB, GCM, CTR. The Tcllib package just supports ECB and CBC, and only CBC (which is the default) is really an option to use.
Visit Wikipedia for an example why you should never use ECB mode.
Now back to your actual question:
Initialization Vector (IV)
This is a random value you pick for each encryption, it is not secret, you can just publish it together with the encrypted data. Picking a random IV helps to make two encrypted blocks differ, even if you use the same key and cleartext.
Secret Key
This is also a random value, but you must keep it secret, as it can be used for encryption and decryption. You often have the same key for multiple encryptions.
Where to get good randomness?
If you are on Linux, BSD or other unixoid systems just read bytes from /dev/urandom or use a wrapper for getrandom(). Do NOT use Tcls expr {rand()} or similar pseudorandom number generators (PRNG). On Windows TWAPI and the CryptGenRandom function would be the best idea, but sadly there is no Tcl high level wrapper included.
Is that enough?
Depends. If you just want to hide a bit of plaintext from cursory looks, maybe. If you have attackers manipulating your data or actively trying to hack your system, less so. Plain AES-CBC has a lot of things you can do wrong, and even experts did wrong (read about SSL/TLS 1.0 problems with AES-CBC).
Final words: If you are a novice in encryption algorithms, be sure you understand what you want and need to protect, there are a lot of pitfalls.
If I read the Tcler's Wiki page on aes, I see that I encrypt by doing this:
package require aes
set plaintext "Some super-secret bytes!"
set key "abcd1234dcba4321"; # 16 bytes
set encrypted [aes::aes -dir encrypt -key $key $plaintext]
and I decrypt by doing:
# Assuming the code above was run...
set decrypted [aes::aes -dir decrypt -key $key $encrypted]
Note that the decrypted text has NUL (zero) bytes added on the end (8 of them in this example) because the encryption algorithm always works on blocks of 16 bytes, and if you're working with non-ASCII text then encoding convertto and encoding convertfrom might be necessary.
You don't need to use aes::init directly unless you are doing large-scale streaming encryption. Your use case doesn't sound like it needs that sort of thing. (The key data is your “secret”, and the initialisation vector is something standardised that usually you don't need to set.)
I'm some newbie of data encryption. I goggling data encryption and mostly found md5 and SHA algorithms.Which technology do you consider to be the best for data storage/security and why?
MD5 and SHA are hash functions, they create fingerprint - fixed-length representation - from the bunch of data. For example, they are extensively used as a way to check consistency of your iso image downloads for many open-source products, but this means you can use them to create fingerprints from any selection of bytes. So they do not encrypt.
If you want to encrypt, you should check for encryption algorithms. The most feasible now I believe is AES (Advanced encryption Standard) if you look for symmetric encryption algorithms (eg. where key for encryption and decryption is the same or easily computed one from another) or RSA if you look for asymmetric (where you have 2 keys - public and private, and compute private key from public is hard task).
If you are about to create digital signatures, you may want to check things like DSA (digital signature algorithm) and ECDSA (DSA over elliptic curves.). Note that asymmetric algorithms work over numbers with extended precision - like 512, 1024, 2048 bits and so on. You need special libraries that can handle such numbers. If you use C++ I can recommend you trying Crypto++. Find something similar for other languages.
I hope this was useful for you.
If your data is password and you want to store it some where then Use MD5 or SHA Hash.
There are two advantages of these.
A hash can not be decrypted to recover old value so your password will never ever will be cracked even if you provide MD5/SHA hash of password to some one :)
A hash of particular string will be always same so you can compare passwords based on Hash.
AES :
Symmetric algorithm so faster
Use with PKCS5Padding and CBC mode
Always store IV
Symmetric so you need same key while you are decrypting encrypted text so you can not at all share keys.
RSA
PKI Infrastructure to exchange Keys
Slow
There are other algorithms also Like DES(Not So Secure), 3DES(Often called Tripple DES- Not enough secure compared to DES)
Right now, this is what I am doing:
1. SHA-1 a password like "pass123", use the first 32 characters of the hexadecimal decoding for the key
2. Encrypt with AES-256 with just whatever the default parameters are
^Is that secure enough?
I need my application to encrypt data with a password, and securely. There are too many different things that come up when I google this and some things that I don't understand about it too. I am asking this as a general question, not any specific coding language (though I'm planning on using this with Java and with iOS).
So now that I am trying to do this more properly, please follow what I have in mind:
Input is a password such as "pass123" and the data is
what I want to encrypt such as "The bank account is 038414838 and the pin is 5931"
Use PBKDF2 to derive a key from the password. Parameters:
1000 iterations
length of 256bits
Salt - this one confuses me because I am not sure where to get the salt from, do I just make one up? As in, all my encryptions would always use the salt "F" for example (since apparently salts are 8bits which is just one character)
Now I take this key, and do I hash it?? Should I use something like SHA-256? Is that secure? And what is HMAC? Should I use that?
Note: Do I need to perform both steps 2 and 3 or is just one or the other okay?
Okay now I have the 256-bit key to do the encryption with. So I perform the encryption using AES, but here's yet another confusing part (the parameters).
I'm not really sure what are the different "modes" to use, apparently there's like CBC and EBC and a bunch of others
I also am not sure about the "Initialization Vector," do I just make one up and always use that one?
And then what about other options, what is PKCS7Padding?
For your initial points:
Using hexadecimals clearly splits the key size in half. Basically, you are using AES-128 security wise. Not that that is bad, but you might also go for AES-128 and use 16 bytes.
SHA-1 is relatively safe for key derivation, but it shouldn't be used directly because of the existence/creation of rainbow tables. For this you need a function like PBKDF2 which uses an iteration count and salt.
As for the solution:
You should not encrypt PIN's if that can be avoided. Please make sure your passwords are safe enough, allow pass phrases.
Create a random number per password and save the salt (16 bytes) with the output of PBKDF2. The salt does not have to be secret, although you might want to include a system secret to add some extra security. The salt and password are hashed, so they may have any length to be compatible with PBKDF2.
No, you just save the secret generated by the PBKDF2, let the PBKDF2 generate more data when required.
Never use ECB (not EBC). Use CBC as minimum. Note that CBC encryption does not provide integrity checking (somebody might change the cipher text and you might never know it) or authenticity. For that, you might want to add an additional MAC, HMAC or use an encryption mode such as GCM. PKCS7Padding (identical to PKCS5Padding in most occurences) is a simple method of adding bogus data to get N * [blocksize] bytes, required by block wise encryption.
Don't forget to prepend a (random) IV to your cipher text in case you reuse your encryption keys. An IV is similar to a salt, but should be exactly [blocksize] bytes (16 for AES).