After studying CryptoChefs homepage about "fullbit encryption" (Vollbit Verschlüsselung), I just wondered if there has already been an analysis on how this algorithm works.
I believe he just xors some file with another file, maybe multiple times, but maybe someone still knows what he really does.
I think its no that easy as chefin says, because he claims it works with a passphrase to generate the keyfile.
So, if the software exists, it will be flawed, because a keyfile for XOR generated by a passphrase will contain redundancies. just think of the easiest way to generate a keyfile from a password:
passwordpasswordpassword
Now you can just split the ciphertext in three blocks (each with the length of the password) and XOR two of them together to get the password.
Of course, there are more sophisticated algorithms for generating keyfiles from a password, but none of them will have the OTP-Feature of "nobody can decrypt it without the pad", because the pad depends on the passphrase and cannot have more entropy than the passphrase itself.
Sorry, but it works "perfect". But thats normal, as he only create a onetimepad encryption. If you use random numbers (and thats why he speak about 256bit key) and generate a file as big as the file you want to encrypt, simple xor multiple times is enough.
But this is old and everyone know it is not usefull. How do you store a 2Mbyte File you need to decrypt your 2Mbyte Dokument. Use a Stick? Why not put the file on the stick itself? It is just a little harder for decrypting, as you need 2 components you have to find first.
Related
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.)
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).
I need to save the password to database.I get confused in encryption,hash using sha-256 ,salt generation method .If any one explains the basic concept behind this then it will be helpful
The follow is a very basic explanation, anyway...
Encryption is a reversible method to crypt the data. So if you have "password" a encryption method convert it into (for example) "ufmehlejw" and then you are able to get again "password".
An hash function (one of them is the sha-256) is a function that once it's used on a string you have no way to recover the original string.
A salt is a string which usually prorammers (and not only, of course) use to mix the given password. It's usually randomly generated. A salt is used to extend the original data before using an hash function. The goal of the salt is to avoid attackers to discover the original password of a user from a stolen hash using rainbow tables.
In short:
Encryption is a process with an inverse. In other words: If I encrypt some text, there is a process which is able to convert the new text back to the original, called decryption.
Hashing is fundamentally different from encryption, because it does not have such a process. What a hash is meant to do is provide you with a result, which is unique for that given input text (well, almost unique, let's keep it at unique). This way, people can verify if two input texts were equal, without knowing what the actual input text was. So, if people get their hands on your hashed password, they still cannot decrypt it. SHA is a family of methods which provide hashing.
Salts and Peppers are merely additional techniques to hashing, which describe the process of adding something before and after the input text before hashing. This improves the difficulty of brute-force cracking of hashes back to text.
Brute force cracking means simply trying all possible inputs (aa, ab, ac, etc...) and see if you can generate a hash which matches the hash you have gotten via hacking some website or whatever. You can find more on that here: https://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough
I'm learning to do proper crytographic implementations, and I thought as an exercise I would create an encrypted text editor.
My first attempt used a SHA-512 hash of a user-provided password as the key, and it functioned just fine. Though I was storing the IV in the header of the file, unprotected and that had me worried.
Then I read on stackoverflow that I should be using SecretKeyFactory (I'm using Java) to do PBE, and now I additionally need to provide a salt. So now I'm storing the salt in the header as well, but that would seem to ruin the whole purpose of having a salt. So how is this supposed to work? When I have Alice pick a password for her file when she saves, am I supposed to say "Here, memorize this random number along with your password."? I would like for the resulting file to be able to be e-mailed to Bob, so the salt can't be stored locally.
As my app stands, the IV and salt are out in the open. I would like for my user to only have to know the password when they send their file to Bob while remaining cryptographically secure, but I can't find any examples of how this is done.
Thanks for any help!
It is safe to store an IV along with the data, that is how IVs are used. Your method is ok, pick a block cipher, use cipher block chaining and an IV, and you're away.
There are many ways to create a key and iv from a passphrase, but one of the more common ones involves HMAC with SHA-1, in an algorithm that takes some salt and other things into account, to build a sufficiently bit-mixed key and iv.
The technical standard is the PKCS#5 v2.0 PBKDF2 algorithm, to which OpenSSL implements a C interface to a method that can do this, but as far as I know, no command line method.
What is the best way to encrypt a value in INI file?
Using Encryption/Decryption key??
For what purpose? Security?
If you are trying to (e.g.) encrypt a plaintext password you should probably use some implementation of PKI. Remember though, that then key management becomes your problem. Just encrypting the value is not a panacea because the ini file is most likely on the local host's file system, presumably the same place you'll have to store your key pair. You've simply abstracted the problem down a layer. They won't be able to read your encrypted password directly, but if they can find the place you store your key pair they can decrypt it themselves.
To what effect? What are you trying to protect or obfuscate?
You could use one of the many two-way key encryption algorithms available for all platforms... But ask yourself why you're doing it in the first place. If you're trying to make something hack-proof, encrypting ini strings probably isn't going to get you that far because as soon as you decrypt the ini, the string is in memory. And the key to decrypt will be in your program. Childsplay to hack out.
If you just want to stop people editing a setting easily, don't put it in an ini. Choose a binary format that the user will have a hard time editing.
For personal scripts where I have an email password, I use
TinyEncryption.
I will put the passkey in the code itself. This prevents a casual snooper from just browsing through and picking up an email password.
The code is pretty simple too. Here it is in Python.
import random
import base64
def tinycode(key, text, reverse=False):
"(de)crypt stuff"
rand = random.Random(key).randrange
if reverse:
text = base64.b64decode(text)
text = ''.join([chr(ord(elem)^rand(256)) for elem in text])
if not reverse:
text = base64.b64encode(text)
return text
For more enhanced security, I use PGP, but you then have to prompt for a passkey. There's no setup that's perfect, it depends on what your needs are.
You could use any standard encryption algorithm with a key, and perhaps prefix the value with some random padding before encrypting.
However where do you plan to store that key then? Or are you going to get the user to enter a password and derive a key from that? If not then it would be fairly pointless to encrypt the value.
Do you need to decrypt it too? If not you can just salt and hash it.
If you do want to decrypt it, then Id say you should specify the language as well perhaps.
MD5 hash
Then you compare hash("password") with the ini_file.password hash