I'm taking a user inputted NSString, converting it to NSData with NSUTF8StringEncoding. I'm then using CCCrypt to encrypt that data using a random salt and IV and a user inputted password.
My question is, how do I convert this encrypted NSData into a format that could be decrypted by a plain text AES decryptor such as http://www.everpassword.com/aes-encryptor?
Furthermore, does CCCrypt automatically add the salt & rounds to the encrypted data? Or do I need to manually add them in some way before the data can be decrypted with access only to the secret password?
Any help on this would be greatly appreciated.
The website you posted uses Gibberish-aes and giberish aes uses an openssl compatible format. CCCrypt will not give you that format by itself, however you don't have to do it yourself. RNCryptor happens to have an OpenSSL format mode RNOpenSSLEncryptor.
Related
If I encrypt a file as file1 using openssl, where is the hash of that password stored?
No matter what I Google, the closest I get are instructions to enable root and navigate to /var/db/dslocal/nodes/Default/users directory. Unless I'm just not recognizing it, I am unable to find anything that looks like what I want in there.
If I understand the question correctly (i.e. that it's about encrypting a file with openssl enc -ciphername or the shorthand openssl ciphername), then the answer is: the hash is not stored anywhere.
What happens is that the password (and salt) are run through a hash function to derive an encryption key, and that key is used to encrypt the contents of the file. The key (i.e. the hash) is then discarded.
When you go to decrypt the file, it runs the password you entered and the salt (stored in the file) through the same hash function, and attempts to use that to decrypt the file's contents. If the password is the same as that used to encrypt, you get your original file back. If the password is different, you get back gibberish. openssl might be able to tell it's gibberish if the padding doesn't make sense, but it might not. As the man page says:
All the block ciphers normally use PKCS#5 padding also known as
standard block padding: this allows a rudimentary integrity or
password check to be performed. However since the chance of random
data passing the test is better than 1 in 256 it isn't a very good
test.
How to decrypt a string with unknown encryption algorithm?
There is a string:
5aaC5p6c5L2g5a+55oiR5Lus5Zyo5YGa55qE5LqL5oOF5pyJ5YW06Laj77yM5bm25LiU5a+5cmFpbHMv5YmN56uv5byA5Y+R5pyJ6Ieq5L+h77yM5qyi6L+O5Y+R6YCB6YKu5Lu25YiwZ2hvc3RtNTVAZ2l0Y2FmZS5jb23pooTnuqbkuqTmtYHml7bpl7TvvIznoa7lrprkuYvlkI7lj6/ku6Xnm7TmjqXmnaXliLDmiJHku6znmoTlt6XkvZzlrqTlj4Lop4LkuqTmtYHvvIzosKLosKIK
I don't know the encryption algorithm. How to decrypt it?
To analyze and solve this problem, what should I learn?
It's not an encryption algorithm, it's base64. You can tell because of the +s.
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
Try running it through this page, it'll turn into this:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
NOTE: If it was actually encrypted and you actually had no clue what it was encrypted with, you would be screwed, because any good encryption algorithm turns the output into meaningless gibberish, unusable without the key. Base64 has no key, you can just reverse it the same way every time.
This string appears to be a Base64 encoded string.
The decoded value is: 如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
Well, the string is likely Base64 encoded. If you decode it, you should get an effectively random piece of binary data if its encrypted (EDIT: As others have shown, it isn't encrypted, but the following would still apply if it were)
By checking the length, you can determine the block-size of the cipher. If its not an even block size, it likely could be a stream cipher (or a block cipher operated in stream mode).
However, any more information will need to be gleamed from other sources - as the point of good encryption is to make the data truly opaque.
Its Base 64 encryption.The above code is translated as:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
"If you are doing things we are interested in, and on the rails / front-end developers are confident, please send e-mail to communicate ghostm55#gitcafe.com appointment time, after determining the direct exchange of visits to our studio, thank you"
We can't for the life of us figure this out. We need to make ColdFusion encrypt data which ruby will decrypt. We've tried so many different settings on the ColdFusion side, looked through SO posts, looked through Adobe docs, and cannot make it work. ColdFusion needs to encrypt it so ruby can do this:
aes = OpenSSL::Cipher::Cipher.new('aes-256-cbc').encrypt
aes.key = Digest::MD5.hexdigest("#{password}#{salt}")
aes.iv = Digest::MD5.hexdigest("#{salt}#{password}")[0,16]
encrypted = aes.update(data) + aes.final
ColdFusion pseudo code
key = tobase64(binaryDecode(lcase(hash(password & salt, "md5")), "hex"))
iv = lcase(left(hash(salt & password, "md5"), 16))
encrypt(data, key, "AES/CBC/PKCS5Padding", "Base64", iv)
Tried with/without the tobase64/binaryDecode (saw somebody mention that it would handle conversion back internally or something stupid). lcase is to make it generate MD5s that look like what ruby builds.
What are we doing wrong? Endless bad decrypt on the ruby side
What are we doing wrong?
You are not being careful with encodings.
You must take encodings into account.
In ColdFusion, you must only use a byte-array as key or IV, and you must only encrypt byte-arrays.
Do not deal with keys, IVs, or cleartexts in any form other than byte-array. Do not deal with them as base64-encoded strings, UTF-16 strings (what Java does by default), or any other form. You must always deal only with byte-arrays, and you must always know the encoding and use the same encoding between ColdFusion and Ruby.
You can get a byte-array from a string using an encoding. I would tend to use the UTF-8 encoding. Look at the CharsetEncode and CharsetDecode functions.
You are also using keys and IVs wrong. Keys may be generated from passwords using an algorithm such as PBKDF2, but only if you don't have a good way of generating with a cryptorandom PRNG and storing them. IVs should be generated with a cryptorandom PRNG, and may be prepended to the ciphertext when you store or transmit it as a convenient method of storing/transmitting the IV too.
So I have implemented salts and IVs, but the decryption is now a bit buggy. Of course, I need both the salt and IV for decryption as well, but the user can't enter that... I need to be able to store both the salt and IV in the encrypted file, then retrieve the salt and IV when the user is decrypting the file. How would I go about doing this? How would I go about storing and retrieving that data?
As Peter said, the initialization vector and the salt for key derivation should be stored together with the encrypted file, in a header or such.
Instead of creating your own ad-hoc file format for encrypted storage, have a look at the OpenPGP message format (as used by both PGP and GnuPG, and maybe other programs). It is specified in RFC 4880. You will likely not have to implement all of it, but grab the portions that you need for your application.
As an added bonus, the user can then use PGP/GPG (with the right options and the password/key) to decrypt the data, if your program should somehow cease to work.
Store them along with the ciphertext. You'll need to come up with a suitable file format in which to do it; a keyed archiver will make it easy.
Recently I came across this word in a basic authentication article. What it meant by base64 clear text usrname and password on the network?
Thanks
In HTTP Basic authentication, the "password:username" is encoded in Base64. Since it's not encrypted, it's cleartext.
Here is a sample Authorization header,
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Where dXNlcm5hbWU6cGFzc3dvcmQ= is Base64-encoded "username:password" (literally).
It means encoding the username and password using base 64. The result won't look too much like your username and password but it's pretty easy to reverse the operation to get the plain text.
See here for details on base 64 encoding
http://en.wikipedia.org/wiki/Base64
For example the string password encoded in base 64 is cGFzc3dvcmQ=
This online tool can encode/decode base 64 for you http://www.motobit.com/util/base64-decoder-encoder.asp
Base 64 encoding (Wikipedia article) turns "This is my password." into:
VGhpcyBpcyBteSBwYXNzd29yZC4=
It's easily recognizable and entirely reversible, so its entirely insecure.
This means that the username and password is not encrypted (ie clear text) The text is just base 64 encoded for transporting and can easily be decoded.
Base64 is a way to deliver binary data through a connection (or file) that limits what characters are allowed to be included. For example, e-mail attachments are encoded in base64 because the e-mail protocol only allows for plain text in an e-mail message.
See the wikipedia page for more http://en.wikipedia.org/wiki/Base64