Develop Reference

Encryption using AES 256 and SHA-2

I have a situation where I need to first encrypt a message using a public key and vector, that is already provided. Also as per requirement I need to use SHA-2 as well. For now, I am assuming that I need to hash the encrypted message and then send to the server. I have two questions related to this
1. Is it wise to hash the encrypted message? Also, will sending the encrypted message and hashed value to the server be a good idea?
2. I have done a lot search on internet, but whenever I try to get some example of using AES 256 and SHA-2 together, I actually land up where the difference between the two is explained. Can any help me with some sample code?
Thanks in Advance!!!

Let's break down the stuff first.
Public Key Cryptography
Allows a given pair (Kpriv, Kpub) to be used on a cipher to encrypt and decrypt data.
Any data encrypted with Kpriv can only be decrypted with Kpub and any data encrypted with Kpub can only be decrypted with Kpriv.
A nice and well known example of a public key cipher is RSA.
Asymmetric cryptography requires extremely large keys in order to be secure, such that it's extremely slow to execute! You should never encrypt large amount of data with Asymetric keys cryptography. You can use it in the beginning of a connecition to exchange a symetric key Ks, though.
Symetric Key Cryptography
Allows a Ks to be used on a cipher to encrypt and decrypt data.
An example of a symetric cipher is AES. AES is in fact so versatile you can change lots of parameters, such as, (as you mention) the Blocksize which can be of 128, 192 or 256 bits. AES256 is the AES cipher configured with a blocksize of 256 bits.
The block size is what's used against the provided Ks to perform the actual encryption. Note that your data can be larger than the block size (the algorithm will still work, It'l simply reuse the same Ks). Simply reusing the key every block is known as ECB mode and can reveal patterns if your data is repetitive. An alternative is to use modes like CBC or CTR which rely on also using previous block data and XORing with the next block data, to eliminate such patterns. What mode should you use depends on your data.
Note that, according to your cipher mode, you eventually will need padding. I'm assuming you are already quite familiar with this terms when you asked that question.
Guarantees By Cryptography
Cryptography does guarantee that the encrypted data is confidential but that's just it. It does not give any other guarantees such as whether the data is authentic or whether it has been tampered with or not.
While tampering data will most likely result in unintelligible text even after decryption, in cryptography, there's no such thing as invalid plaintext. As such, you need some mechanism to know if your data is valid or not.
A secure hash algorithm such as SHA can help you know whether your decrypted data is valid or not.
However, for these purposes, you usually shouldn't directly use a Digest algorithm. Try to instead use a MAC. That MAC can use SHA256 algorithm but MAC's and Hashes are not exactly the same.
How To Do It In Practice
If all you want is confidentiality and tampering detection, you would use the cipher and digest (or hash) algorithm as such:
E ks ( SHA(data) || data )
Where E is a symmetric cipher, ks is the shared symmetric key, SHA(data) is the digest of data using a secure hash algorithm, || means concatenation and data is a byte array.
A more safer approach would be:
E ks ( MAC mk(data) || data )
Where mk is the MAC's secret key.
Now just search how to "java symetric cipher" and "java hash byte array" and use the two as I'm describing above.

Implementing encryption in Java whilst maintaining bitstring length

I'm trying to figure out a way of implementing Blowfish (or any encryption scheme that will work) in a program I am writing in Java for Android.
I have a sentence, like "I am a dog", which I want to encrypt.
However, before encryption, I encode the sentence with my own 5-bit character representations.
This is my own making, and is like a = "00110" and 'the' = "11001"
So now I have an encoding that is divisible by 5, and looks like
"00011101001101011010"
Is there a way to implement Blowfish to encrypt this binary string, whilst maintaining the length of the bit string.
i.e. the bit string above is 20 bits long. I want the encrypted bit string to also be 20 bits long.
Is this possible with Blowfish? Is it possible at all?
Thanks for any help!

For any block cipher, the cipher text must be at least as big as the block size. That is 64-bits for Blowfish, which means at least a 64-bit output.
If your plaintext is longer than your block size, then you can get the same cipher text size using cipher text stealing: https://en.m.wikipedia.org/wiki/Ciphertext_stealing
Not sure why you are doing the encoding that way, it certainly does not add to security. Also, Blowfish is a dated algorithm: AES is a better choice, but that has block size 128.
Stream ciphers will allow you to get the exact same cipher text size as plaintext size, but I don't know of any good ones implemented in Java. Whatever you do, stay away from rc4: it has real security problems. See the eSTREAM page for possible stream ciphers that should have adequate security. Also, you must never re-use a key for a stream cipher.
EDIT: #CommonsWare pointed out a clever solution from Maarten Bodewes. It looks correct to me, but I don't think you will find an implementation that does this out-of-the-box. Keep in mind also that every ciphertext has to be paired with the IV, which is the same length as the block size (64-bits for blowfish). You should never repeat an IV. My general feeling is that although a clever solution, you're likely going to be better off if you do not have to implement something like this yourself (implementing crypto is dangerous: it is easy to lose security properties by making the smallest mistake).

ccrypt will not decrypt ccrypt-j encrypted files

I've been trying to fix ccrypt-j, a pure-java implementation of the linux ccrypt command. I found there is some problem with the initialization vector (IV) which makes ccrypt not decrypt anything but its own output.
I modified both libraries so that the same nonce is always fed to both implementations of the Rijndael engine, however, the output IV is always different between implementations, i.e. both libraries always have the same result (because Rijndael is deterministic), but those results are always different.
I know the problem is only the way ccrypt generates the IV since:
ccrypt-j-encrypted can be decrypted from ccrypt-j
If I substitute the IV (first 32 bytes of the encrypted files) with that of a ccrypt-encrypted file, ccrypt will decrypt it just fine.
Ccrypt uses its own implementation of Rijndael coded in C, while ccrypt-j uses Bouncy Castle's implementation.
EDIT: 04/01/2016
Because the IV is constructed before any data is encrypted (actually, any data is even read) I believe the problem has to be in the way Rjindael is initialized in both Bouncy Castle and ccrypt's own implementation. I'll try to do the same sequence in both implementations and see what I get.

One half-answer
if you look at the old ccrypt, there are some explanations about IV. if I resume, 4 bytes are fixed - magic number -, it si c051 for a while. Issues about securities are also discussed:
magic number : see that
http://ccrypt.sourceforge.net/faq.html
ccrypt comes from emacs / jka-compr:
http://www.opensource.apple.com/source/emacs/emacs-51/emacs/lisp/jka-compr.el
In ccrypt, the seed is constructed as follows: first, a nonce is
contructed by hashing a combination of the host name, current time,
process id, and an internal counter into a 28-byte value, using a
cryptographic hash function. The nonce is combined with a fixed
four-byte "magic number", and the resulting 32-byte value is encrypted
by one round of the Rijndael block cipher with the given key. This
encrypted block is used as the seed and appended to the beginning of
the ciphertext. The use of the magic number allows ccrypt to detect
non-matching keys before decryption.
magic number there: http://ccrypt.sourcearchive.com/documentation/1.7-7/ccryptlib_8c-source.html
It seems magic number doesnt change (same from 1.1 to 1.10, before, I dont know).
So what ?
ccrypt is designed to be compatible with precedent versions (emacs , ...). It can crypt and decrypt, and is widely used.
Then problem come from ccrypt-j.
what one can see on sourceforge is 2 important things :
1 compatibility
Encrypting a file using ccrypt-j
TODO
Decrypting a file using ccrypt-j
TODO
so what works really ?
2 in fact, it uses bouncy castle, which is well used, and surely implements standards well.
So conclusion ?
you cant hope ccrypt will change.
then: you can decrypt ccrypt by ccrypt-j
but if you want to decrypt by ccrypt, you have to limit ccrypt-j
I doubt about your assertion, because it would be magical !
If I substitute the IV (first 32 bytes of the encrypted files) with
that of a ccrypt-encrypted file, ccrypt will decrypt it just fine.
But if it works, why not use that ? (ccrypt-j can also decrypt ?)
last advice: contact ccrypt-j support
hope it helps

Cryptanalysis: XOR of two plaintext files

I have a file which contains the result of two XORed plaintext files. How do I attack this file in order to decrypt either of the plaintext files? I have searched quite a bit, but could not find any answers. Thanks!
EDIT:
Well, I also have the two ciphertexts which i XORed to get the XOR of the two plaintexts. The reason I ask this question, is because, according to Bruce Schneier, pg. 198, Applied Cryptography, 1996 "...she can XOR them together and get two plaintext messages XORed with each other. This is easy to break, and then she can XOR one of the plaintexts with the ciphertext to get the keystream." (This is in relation to a simple stream cipher) But beyond that he provided no explanation. Which is why I asked here. Forgive my ignorance.
Also, the algorithm used is a simple one, and a symmetric key is used whose length is 3.
FURTHER EDIT:
I forgot to add: Im assuming that a simple stream cipher was used for encryption.

I'm no cryptanalyst, but if you know something about the characteristics of the files you might have a chance.
For example, lets assume that you know that both original plaintexts:
contain plain ASCII English text
are articles about sports (or whatever)
Given those 2 pieces of information, one approach you might take is to scan through the ciphertext 'decrypting' using words that you might expect to be in them, such as "football", "player", "score", etc. Perform the decryption using "football" at position 0 of the ciphertext, then at position 1, then 2 and so on.
If the result of decrypting a sequence of bytes appears to be a word or word fragment, then you have a good chance that you've found plaintext from both files. That may give you a clue as to some surrounding plaintext, and you can see if that results in a sensible decryption. And so on.
Repeat this process with other words/phrases/fragments that you might expect to be in the plaintexts.
In response to your question's edit: what Schneier is talking about is that if someone has 2 ciphertexts that have been XOR encrypted using the same key, XORing those ciphertexts will 'cancel out' the keystream, since:
(A ^ k) - ciphertext of A
(B ^ k) - ciphertext of B
(A ^ k) ^ (B ^ k) - the two ciphertexts XOR'ed together which simplifies to:
A ^ B ^ k ^ k - which continues to simplify to
A ^ B ^ 0
A ^ B
So now, the attacker has a new ciphertext that's composed only of the two plaintexts. If the attacker knows one of the plaintexts (say the attacker has legitimate access to A, but not B), that can be used to recover the other plaintext:
A ^ (A ^ B)
(A ^ A) ^ B
0 ^ B
B
Now the attacker has the plaintext for B.
It's actually worse than this - if the attacker has A and the ciphertext for A then he can recover the keystream already.
But, the guessing approach I gave above is a variant of the above with the attacker using (hopefully good) guesses instead of a known plaintext. Obviously it's not as easy, but it's the same concept, and it can be done without starting with known plaintext. Now the attacker has a ciphertext that 'tells' him when he's correctly guessed some plaintext (because it results in other plaintext from the decryption). So even if the key used in the original XOR operation is random gibberish, an attacker can use the file that has that random gibberish 'removed' to gain information when he's making educated guesses.

You need to take advantage of the fact that both files are plain text. There is a lot of implications which can be derived from that fact. Assuming that both texts are English texts, you can use fact that some letters are much more popular than the others. See this article.
Another hint is to note the structure of correct English text. For example, every time one statements ends, and next begins you there is a (dot, space, capital letter) sequence.
Note that in ASCII code, space is binary "0010 0000" and changing that bit in a letter will change the letter case (lower to upper and vice versa). There will be a lot of XORing using space, if both files are plain text, right?
Analyse printable characters table on this page.
Also, at the end you can use spell checker.
I know I didn't provide a solution for your question.
I just gave you some hints. Have fun, and please share your findings.
It's really an interesting task.

That is interesting. The Schneier book does indeed say that it is easy to break this. And then he kind of leaves it hanging at that. I guess you have to leave some exercises up to the reader!
There is an article by Dawson and Nielson that apparently describes an automated process for this task for text files. It's a bit on the $$ side to buy the single article. However, a second paper titled A Natural Language Approach to Automated Cryptanalysis
of Two-time Pads references the Dawson and Nielsen work and describes some assumptions they made (primarily that the text was limited to 27 characters). But this second paper appears to be freely available and describes their own system. I don't know for sure that it is free, but it is openly available on a Johns Hopkins University server.
That paper is about 10 pages long and looks interesting. I don't have time to read it at the moment but may later. I find it interesting (and telling) that it takes a 10 page paper to describe a task that another cryptographer describes as "easy".

I don't think you can - not without knowing anything about the structure of the two files.

Unless you have one of the plaintext files, you can't get the original information of the other. Mathematically expressed:
p1 XOR p2 = en
You have one equation with two unknowns, you can't possibly get something meaningful out of it.

How to use the RIM crypto api for TripleDES encryption with NO Padding

It seems the RIM Crypto API provides for only PKCS5 Padding mode for symmetric encryption (3Des) - as far as I know. I'm working with the JDE 4.6.0.
I'm trying to provide cryptography for a blackbery app which needs to be compatible with existing services which already use NoPadding with the standard Java security API.
Is there a way to extend the API to provide for the lacking PADDING modes, or some other hack, to achieve this?

Based on what you've told me, I would use the encrypt function of TripleDESCBCEncryptorEngine to encrypt your blocks.
There is a version of the function that can encrypt multiple blocks at once by specifying the number of blocks.
Here is a reference to that function.
It looks very straightforward, you just pass the key and the IV into the constructor and then proceed to make calls to .encrypt to encrypt the data.
Similarly there is a TripleDESCBCDecryptorEngine here.

I admit to not being familiar at all with the RIM crypto API, but just from reading the documentation it appears just using the the BlockEncryptorEngine.encrypt() method gives you the same functionality as the JCE NoPadding tranformations for block ciphers. So in your example that would be TripleDESEncryptorEngine.

If you are using CBC chaining mode and can arrange for your input data to have a length multiple of the block size (i.e. multiple of eight, when expressed in bytes, if the block cipher is 3DES) then you just have to remove the last block of the encrypted output.
In CBC encryption, input data (m) is first padded into a message which has a length multiple of the block size (with PKCS#5, by adding between 1 and b bytes, where b is the block length, b=8 for 3DES); then it is split into successive b-bytes blocks. Each of those blocks yields an encrypted block of the same size: the encrypted block for message block i is the result of 3DES applied on the bitwise XOR of message block i and encrypted block i-1. Consequently, if the original message m has a length multiple of b, then PKCS#5 padding adds b bytes, i.e. a full block. By removing the last encrypted block, you obtain what you would have got with no padding at all.
Decryption might be trickier. If the RIM API is stream-oriented (if it can gives you some plaintext bytes before having the whole message) then you can feed it with null trailing bytes until it returned you all your message (the extra null bytes will decrypt into pure random-looking junk, just discard it). If the RIM API is message-oriented, then you will have to use your knowledge of the secret key to rebuild a valid "last block" (the one which was you removed during encryption). Namely, with 3DES, this would mean the following: if z is the last encrypted block of the message (the one with "no padding"), then you encrypt an empty message (of no byte at all) with the same key, using z as "initial value" (IV). This should result in a single b-byte block, which you just append to the encrypted message. The effect of that extra block is that the decryption engine will "see" a proper PKCS#5 padding, and transparently remove it, yielding the data you expect.
All of the above assumes that you are using CBC, which is the most common chaining mode, among those which require padding.