I am developing App for Android and IOS
For android I am using "AES/CBC/NoPadding" Cipher and for IOS am using CommonCrypto with same algo/mode/padding as Android
I am initializing the ciphers with common key, for getting same result in both platforms
In Android , am using cipher.update(inpBuf, inpOffset, inpLen, outBuf, outOffset) for encrypting/decryption purpose, same way I want to do it in IOS.
I Have tried CCCryptorUpdate in IOS , but the result array was [0,0,0......0]
Please guide me, where am gone wrong?
AES is a block cipher that encrypts data in chunks of 16 bytes. When calling update() all blocks of 16 bytes will be encrypted and any excessive bytes will wait around until the next update() call. When no more data needs encryption you finishes of the encryption with a doFinal() that flushes the last block + and applies any padding needed. Why are you using NoPadding? Are you ensuring you data matches the block size of AES yourself?
When decrypting in IOS you use the corosponding CCCryptorUpdate() and CCCryptorFinal(). Only after the CCCryptorFinal() you would have the full decrypted message. CCCryptorUpdate() might or might not return data, depending on how much is stuck in the buffer etc.
Related
I'm decrypting some data using Java and Apache's most recent WSS4J library with 128-bit AES decryption.
I setup the the cipher which appears to be correct with the right padding, decryption algorithm, and cipher block mode.
I then make a call to doFinal() on the encrypted data bytes and it successfully returns a value.
My question is would it ever return a value that is only partially decrypted?
For example, let's say the first 16 bytes are still jumbled up after decryption, but the remainder of the data returned has been successfully decrypted, and is human-readable with the expected data there.
Would this mean that there could be an issue with my decryption process? Or would it not even be able to return a value from the doFinal() step if something was even slightly off with the decryption setup?
If I get a value returned from doFinal() would that mean that 100% the data returned is the original data before it was encrypted?
I'm decrypting data from a web service call and the owners of the web service are claiming that I must be doing something wrong during my decryption process and that they are sending the data correctly.
Yes, that is possible. A prime example would be if you try to decrypt something in CBC mode with the wrong Initialization Vector (IV). That would result in the first part decrypted to be invalid.
This is due to how the IV is XORed to the first block of plaintext in CBC mode.
I have a big text file (100MB or more) and I want to use AES algorithm to encrypt the content of the text file using Hadoop and Java (Map/Reduce functions), but as I am new to Hadoop, I am not really sure how to start this. I found JCE (a Java library) where AES is already implemented but I have to provide 16 bytes text along with a key to generate a 16 bytes cipher text (encrypted output). My question is how to use this JCE/AES method to get my purpose done? How should I split my big input text file and What should I pass to the map method of Mapper class? what should be the key and value? What should be passed to the Reduce method? Any kind of starting point or code example would be greatly appreciated. (P.S. I am new to Hadoop and I just ran the wordcount problem on my machine, that's it.)
EDIT 1:
Actually, I have to do the following things:
split the input file in 16 bytes chunks.
for each chunk, I have to apply the AES algorithm to get 16 bytes cipher text and write the 16 bytes cipher text in the output file.
continue the process until the input file ends.
My question now is, how to parallelize it using Hadoop's Map and Reduce methods? what should be the key and how to accumulate the output cipher texts in the output file?
Encrypting a large stream with a block cipher requires you to resolve a fundamental issue, completely irrelevant of how you actually split the work (M/R or whatever). The problem is the cipher-block chaining. Because each block is dependent on the output of the previous block, you cannot encrypt (or decrypt) block N w/o first encrypting (or decrypting) block N-1. This implies that you can only encrypt the file one block at a time, starting with block 1, then block 2, then 3 and so on.
To work around the problem all encryption solutions do the same: they split the stream in chunks of adequate size (the right size is always a trade-off) and use some out-of-band storage where they associate each chunk with a startup nonce (initialization vector). This way chunks can be ecnrypted and decrypted independently.
HDFS has a natural chunk (the block) and the access patterns on blocks are single threaded and sequential, lending itself to be the natural choice for encryption chunks. Adding the extra metadata on the namenode for the nonce on each block is relatively straightforward to do. If you do this for your own education, this is a fun project to tackle. Key management is a separate issue, and of course, as with any encryption scheme, key management is the actually important part while implementing the cipher is the trivial part.
If you are thinking at this for real world use, stop right now. Use an off-the-shelf encryption solution for Hadoop, of which there are several
I need to decrypt an AES ciphertext, for which I have the key. The problem is that on decryption in Java, an error occurs:
javax.crypto.BadPaddingException: Given final block not properly padded
I suppose it was a problem on data persisting in the database and that some part of the the data is corrupt (because there was no problems so far, it can't be the key). The length of the ciphertext is a multiple of 16.
Two questions:
If I would I delete the last 16-byte block, would it be possible to decrypt the data?
Do you have any other suggestions?
You can omit padding using NOPADDING for padding spec when encrypting if you can guarantee that your message length will always be a multiple of the AES block size which is 16 bytes. You can also omit padding if you use AES in a mode that doesn't require padding (i.e. CTR mode).
Also, you can always attempt to decrypt a padded message with NOPADDING but you'll have to deal with the padding in the plaintext at some point.
Overall you're probably better off trying to figure out why your message is not decrypting properly instead of trying workarounds. Workarounds when dealing with crypto are generally not a good idea.
I have some issues regarding BlowFish encryption. I'm developing a portlet in Java deployed under weblogic. I receive from an internet usb device a string encrypted with BlowFish - nCFB mode and i need to obtain the original string from it. I implemented blowfish decryption, but i don't know how can i decrypt using the nCFB mode. It's very few documentation on the internet but i was able to find a tool that does it at:
http://www.tools4noobs.com/online_tools/decrypt/
Giving my input string and password, it retrieves the result. But on java i can't do
Cipher cipher = Cipher.getInstance("Blowfish/NCFB/NoPadding");
Because the NCFB is not recognized. I did my implementation with
Cipher cipher = Cipher.getInstance("Blowfish/CFB/NoPadding");
But it only decodes the first 3 characters. How can i decrypt using the NCFB mode instead of CFB ?
I was able to found a little something about nCFB at http://mcrypt.hellug.gr/lib/mcrypt.3.html , but it belongs to mcrypt php library.
Is there a java API able to do this ? Or how can i get the CFB mode to work as NCFB ?
Best regards
CFB (Cypher Feed Back) mode feeds back part or all of the cyphertext when decrypting. the "n" in nCFB tells you how much to feed back. The default is the entire block. You will need to read the documentation to find out what value of n is being used to encrypt, and how to add that parameter to your decryption algorithm. Given that the first three characters are decrypting correctly, it might be that n is 24 bits, though I am not sure of that.
Normally CTR mode is less trouble than CFB.
I want to do AES CBC encryption in Java. I'm using javax.crypto. After I have the Cipher initialized, do I only need to call doFinal on the clear bytes to properly encrypt it? Or do I need to do something with update?
Documentation says update:
Continues a multiple-part encryption
or decryption operation
and doFinal
Encrypts or decrypts data in a
single-part operation, or finishes a
multiple-part operation
what exactly do they mean by multiple-part encryption?
doFinal adds the PKCS7 padding in the last block. So you can call update zero to many times, but last call should be an doFinal. Multipart encryption is when the data is not contiguous in memory. Typical example being buffers received from a socket. You set up the cipher and then start calling update to encrypt or decrypt the data, block by block, and build up the encrypted/decrypted data, by appending the blocks returned by update. On last input block you call doFinal and the returned block is the last one to be appended to the output data. On ecnrypting, doFinal will add the padding. On decrypting doFinal will validate and remove the padding.