In CryptoJS's wiki, it states that:
CryptoJS supports AES-128, AES-192, and AES-256. It will pick the
variant by the size of the key you pass in. If you use a passphrase,
then it will generate a 256-bit key.
That last sentence says if I use a passphrase, "it" will generate a 256-bit key. So my question is: how does the AES function generate the key from the passphrase? Does it use a standard KDF like PBKDF2? Or does it use a custom KDF that only exists in the AES function?
Related
I'm trying to reverse engineering an app and I'm seeing that it encrypt an string using RSA/ECB/PKCS1Padding method
before this it's loading something similar to a private key from another string with a method called "1.2.840.113549.1.12.1.3" I googled this and found out that it's a PKCS12 key
I don't have access to the codes and I'm reading this data using frida so I don't understand what’s being done actually.
What I need to do is to be able to do the same rsa encryption so I need the key for rsa
I have a sample input and output to try and test if the key is right or not. I also have a hex string which I'm guessing it’s from a pfx file, another hex string generated from the previous one which looks like a private key and another smaller hex string which might be the password for pfx (I'm not sure about this)
On further investigation I found out that class name for the key is : com.android.org.bouncycastle.jcajce.PKCS12Key
This is also the second hex string (replaced part of it with X) that I think is kind of a private key but I wasn't able to verify it :
3082035f3082035b060b2a864886f70d010c0a0103a082031430820310060a2a864886f70d01091601a0820300048202fc308202f8308201e0a00302010202106fb86aeca71187a94a49a31d57f64795300d06092a864886f70d01010b05003018311630140603550403130d524e4430382e7365702e6e6574301e170d3230303331353038353030325XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9d4d602c133addaa58422e3af20ee97c8a9936b3134301306092a864886f70d0109153106040401000000301d06092a864886f70d01091431101e0e003700320034004e006500770000
what I tried until now :
converted the first hex string to binary and saved it into a file and then used openssl pkcs12 -in -out command to get pem formatted file, but it failed with error 4630589100:error:0DFFF0A8:asn1 encoding routines:CRYPTO_internal:wrong tag
If encrypt the plain text with its hash is it correct??
Where Can I find a paper that speak about it?
Is it possible Known-plaintext attack?
What would this be useful for? You would have the know the plain text to get back the plain text. If there is no need to remember the key (key is stored separately), you could as well generate a random key instead of a hash.
Use AES/Rijndael or any symmetric encryption.
Encrypt the hidden value using itself as the key and a random IV.
Store the ciphertext + IV. Discard everything else.
To check the hash: try to decrypt using provided plaintext. If provided == decrypted, then it's OK.
Ignore ciphertext length problems.
Is this secure?
There is an existing method of generating a hash or MAC using an block cipher like AES. It's called CBC-MAC. It's operation is pretty simple. Just encrypt the data to be hashed using AES in CBC mode and output the last block of the ciphertext, discarding all prior blocks of the ciphertext. The IV for CBC would normally be left as zero, and the AES key can be used to produce a MAC.
CBC-MAC does have some limitations. Do not encrypt and MAC your data using the same key and IV, or the MAC will simply be equal to the last block of the ciphertext. Also, the size of the hash/MAC is limited to the size of block cipher. Using AES with CBC-MAC produces a 128 bit MAC, and MACs are usually expected to be at least this size.
Something worth noting is that CBC-MAC is a very inefficient way to produce a MAC. A better way to go would be to use SHA2-256 or SHA2-512 in HMAC. In my recent tests, using SHA256 in HMAC produces a result approximately as fast as AES in CBC-MAC, and the HMAC in this case is twice as wide. However, new CPUs will be produced with hardware acceleration for AES, allowing AES in CBC-MAC mode to be used to very quickly produce a 128 bit MAC.
As described, it has a problem in that it reveals information about the length of the data being hashed. That in itself would be some kind of weakness.
Secondly ... it is not clear that you would be able to check the hash. It would be necessary to store the randomly generated IV with the hash.
I was thinking about this while bicycling home, and one other possible issue came to mind. With a typical hashing scheme to store a password, it is best to run the hash a bunch of iterations (e.g., PBKDF2). This makes it much more expensive to run a brute force attack. One possibility to introduce that idea into your scheme might be to repeatedly loop over the encrypted data (e.g., feed back the encrypted block back into itself).
I want to use AES encryption in my application. I have come across some open source implementations of aes algorithm. By looking at them, I am confused about the following parameters:
AES key length. It is mentioned that key length should be 128, 192 or 256 bytes. What if my key is simply five digits i.e. 23467
AES plain-text length : is there any restriction on the aes plain-text length ?
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
Can anyone help me?
AES key length. It is mentioned that key length should be 128, 192 or 256 bits. What if my key is simply five digits i.e. 23467
It seems you're thinking of the key as a password of sorts. It isn't. A cryptographic key isn't meant to be memorized. It is a long string of randomly generated bytes that should be stored somewhere safe.
You can derivate a cryptographic key from a password, though, for instance using a hash function. In that case you input 234567 and use the resulting digest as the key. This has some security implications, however, as it makes your key vulnerable to dictionary and rainbow table attacks. Look up "password based encryption" for details on how to approach this securely; in particular, have a look at PBKDF2, described in RFC2898.
AES plain-text length : is there any restriction on the aes plain-text length ?
AES is the block cipher, the underlying building block of an encryption system. By itself it can only encrypt a single block of data (16 bytes), so cryptographers have created several "modes of operation" that enable us to encrypt a plaintext of arbitrary length. CTR is a fine example of a mode of operation that does not require any padding and can be parallelized.
AES output: What would be the minimum size of aes output string if my key length is say 5 digits and plain-text is say 10 characters.
That's entirely dependent on the mode of operation. In your case it will probably be either 10 (when no padding is required, for example with CTR) or 16 (for block-based modes such as CBC).
I think you mean 128 and 256. (Not 198.)
That's not a key. That's a password. You use an algorithm like PBKDF1 (google it) to derive a key from a password.
No. AES is a block cipher. It works on input blocks that are the same size as the key. You can use as many blocks as you like, chopping up your input into (say) 128-bit blocks. Make sure you use CBC or a similar mode for AES.
Your key is 128 or 256 bits. Your input would be 80 bits (10*8), padded to 128 or 256. Your output length is the same as the key size.
Try to find a crypto library that does most of the work for you. You don't want to mess around with just a basic AES function. You also need to handle IVs, AES modes, possibly a MAC, etc. I can't recommend anything because you don't say what language you're trying to use.
Which symmetrical encryption algorithm to use to encrypt e-mail address(short message)? I would like to have ciphertext to be comparable in length to paintext.
According to Little known features: Symmetric encryption with PGP/GPG:
A little known feature of both PGP and
GPG is that they can also do symmetric
encryption. Just a passphrase is
needed- no public or private keys are
involved. It’s a quick and dirty way
to get strong encryption that even a
novice can use.
To encrypt a file with symmetric
encryption, the syntax is:
pgp --symmetric filename
gpg --symmetric filename
The result is a binary file with the
same name as the original and ".pgp"
or ".gpg" appended.
If the encrypted file must be pasted
into the body of an e-mail message
(instead of added as an attachment),
you’ll want to use the plain ASCII
form of output:
pgp --symmetric --armor filename
gpg --symmetric --armor filename
The result is a plain text file ending
in ".asc"
Decryption is performed using the
usual "-d" switch:
pgp -d filename
gpg -d filename
But I'm not sure this is what you're looking for. Maybe you can clarify your question.
If you really want to have the cipher text comparable in length to the email address, you can use a block cipher in a mode like CFB or OFB that allows encryption of one byte at a time.
However, I don't recommend it, because that gives an attacker a little information about what the message is (how long is the message?). Using an algorithm like 3DES or AES with 16-byte blocks in CBC mode with PKCS #5 padding, most email addresses will be encrypted in two blocks.
I see there is a bit of confusion about lengths of plaintext/ciphertext. Actually, those lengths are quite similar if you use a symmetric encryption algorithm.
Consider a block cipher (e.g. AES). It encrypts 128-bit blocks into 128-bit blocks. So if your plaintext is exactly 128 bits (or its multiple), AES in any mode of operation will produce the ciphertext with the same length. If your plaintext length is not a multiple of 128 bits, then it will get padded to the full block and the ciphertext will be slightly longer (by at most 127 bits). You still can avoid that by using some tricks like ciphertext stealing.
If you use a stream cipher, the encryption process is just XOR-ing bits (or bytes) of the plaintext with bits (or bytes) of the keystream and then the length of the ciphertext is by definition equal to the length of the plaintext.
To answer directly your question, if you don't need any specific format of the encrypted email, just use AES.
If you want the encrypted email to be also in the format of an email, you may want to check how Format-Preserving Encryption works.
#Bobby: ROT13 is NOT an encryption algorithm.
Symmetric block ciphers produce the same length as the input, in multiples of block size (usually 8 bytes or 16 bytes for AES). Because the output is always multiple of block sizes (in fact the output is always the same size as the input and the input must be multiple of block sizes) then you cannot know the original size of the plain text. Common encryption schemes solve this by adding a padding scheme, like PKCS, ISO 10126 or ANSI X923. These schemes place information about the original clear text length in the last block.
If the clear text size is multiple of 8 (16 for AES) then one more block is added to the encrypted text. If the original size is not multiple of block size, then the encrypted size will be rounded up to the next multiple block size.
To this you should add a salt value for each record. A salt (or initialization vector, to be correct) has the same size as a block. Usually is stored in front of the encrypted block.
And finaly you should sign the encrypted value for validation, so you should add a SHA digest, another 20 bytes, otherwise you cannot know for sure if the decrypted value is correct.
So the overall size is (considering AES): 16 bytes (salt) + (clear text size + 20(hash) ) + (16 - (clear text size + 20)%16).
So for john.doe#anydomain.com (lenght 22) the encrypted size will be 16+22+20+(16-10)=64. To decrypt you take the first 16 bytes as salt, decrypt the remaininf 48, the output is lenght 42, you digest SHA the 42-20 = 22 bytes and compare the digets with the last 20 bytes of the decrypted text for validation.
I know is maybe more than you bargained for, but every step in this scheme has a justification.
I would suggest looking into PGP.
To have cypher results comparable with plain text is not a good idea, having differents lenghts is a part of what encryption is about.
I will suggest you one of the most secure encryption algorithms today: AES
But forget about having comparable sizes!
ROT13 or a substitution cypher might work (keys can be changed or exchanged). Encryption with keeping the original text length is...not really that good.
Bobby