javax.crypto.IllegalBlockSizeException
at javax.crypto.Cipher.doFinal(), bci=36
- red.testEncrypt.decrypt(Ready.java:110)
- red.testEncrypt.encrypt(Ready.java:85)
- red.Ready.startApp(Ready.java:22)
at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
at com.sun.midp.midlet.MIDletPeer.startApp(), bci=5
at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=261
at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=144
at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:Richard,
I have read the javadoc but the problem is JME doesn't support getOutputsize method. Only getClass and getIV methods are working the Base64 encoder and decoder works fine. I was wrong previously and I can't get the size from doFinal method, since the error occurs in the same line.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
javax.crypto.IllegalBlockSizeException
at javax.crypto.Cipher.doFinal(), bci=36
- red.testEncrypt.decrypt(Ready.java:116)
- red.testEncrypt.encrypt(Ready.java:88)
- red.Ready.startApp(Ready.java:23)
at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
at com.sun.midp.midlet.MIDletPeer.startApp(), bci=5
at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=261
at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=144
at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:
Oh My God. First, I would like to thank you for taking so much time to explain things to me. I have followed what ever you have said and I got the results![]()
but I still have some doubts. I will ask in the same fashion in which you have suggested things to me.
encrypt() method:
1) You are right I didn't need to do that.
2) cipher.getBlockSize() isn't working in JME
3) Ya I used 1 instead of 0. I recognized it later now I have changed it.
4) (i) The doFinal() method stores a byte[] with encrypted data right? How do i initialize the byte[] ? If I initialize it with null, it throws Null Pointer Exception.
(ii) The doFinal() method actually encrypts and then pads the missing bits right?
so if i extract with 'x' size again all the bytes are copied right?
(iii) I use the Base64 encoder and decoder of Bouncy Castle. Arrays.copyof() works from Bouncy Castle.
5) Ok. Now I get that.
6) I think I have caught exception using try catch block but with general exception. You want me to catch individual exception right?
decrypt() method:
a) OK. I will handle the integer returned.
b) When the length of the encrypted text dilemma is cleared, I think I can make a more clear code.
c) Ya. I have changed them.
d) Ya I got your point and I implemented it.
Can I use the same program for tripleDES encryption?
P.S : I would like to have a clear and correct conversation so I used this method.
Define a static int constant with value 16 and use that. Maybe give it the name BLOCK_SIZE !
I don't really understand what you mean here. On encryption, N bytes of clear text generates 'x' bytes of cipher text and on decryption 'x' bytes of cipher text generates N bytes of clear text.
I would be surprised if j2me did not have AES by default so you might do better with Apache Commons Codec Base64 since you don't need most of the BC library.
One last point. I don't really like to see a key generated from a password in the way that you have done. If you have to use a password then use one of the more standard approaches for converting a password to a key.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:Richard,
Define a static int constant with value 16 and use that. Maybe give it the name BLOCK_SIZE !
If I declare byte[] red = new byte[16], short buffer exception is thrown.
I don't really understand what you mean here. On encryption, N bytes of clear text generates 'x' bytes of cipher text and on decryption 'x' bytes of cipher text generates N bytes of clear text.
The integer x stores the no of bytes which are encrypted and padded right? So if I extract x bytes from the string then same will result right?
I would be surprised if j2me did not have AES by default so you might do better with Apache Commons Codec Base64 since you don't need most of the BC library.
I use Bouncy Castle for Big Integer and Secure Random to do RSA encryption. Now that is a dead end too. Obfuscation ain't working. I got to open a new thread for that next but let me finish this one first.
One last point. I don't really like to see a key generated from a password in the way that you have done. If you have to use a password then use one of the more standard approaches for converting a password to a key.
Actually we are looking for Random key generation. This is just a test code.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:Big Integer and Secure Random classes don't exist in JME. So I googled how to obtain them and the only result I found was to obfuscate the jar file.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:
For JME, its lcrypto-j2me-149. It is the 149 distribution. But it doesn't work.
I have one more doubt about I V here. How can we generate I V which isn't related to our key? i want that to be random too.
You generate a random IV in the same way as you generate a random key! There is a difference in the secrecy requirement. Your key must be kept very very secret and only revealed to the people who must do the decryption. The IV does not have to be kept secret and can be shipped with the ciphertext. One common approach is to prepend the IV to the ciphertext. For security reasons it is best if the IV is different for every message even if the key does not change.
key: javax.crypto.spec.SecretKeySpec@1c950eef
IV: javax.crypto.spec.IvParameterSpec@1d3615ce
java.security.InvalidAlgorithmParameterException
at javax.crypto.Cipher.init(), bci=199
- red.testEncrypt.encrypt(Ready.java:97)
- red.Ready.connect(Ready.java:52)
- red.Ready.startApp(Ready.java:31)
at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
at com.sun.midp.midlet.MIDletPeer.startApp(), bci=5
at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=261
at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=38
at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=5
at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=144
at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Partheban Udayakumar wrote:Richard,
I obfuscated jar file using pro guard obfuscator provided in netbeans. I downloaded pro guard and obfuscated the jar file, still it shows Noclassdeffound error for Secure Random.
You generate a random IV in the same way as you generate a random key! There is a difference in the secrecy requirement. Your key must be kept very very secret and only revealed to the people who must do the decryption. The IV does not have to be kept secret and can be shipped with the ciphertext. One common approach is to prepend the IV to the ciphertext. For security reasons it is best if the IV is different for every message even if the key does not change.
Ok. I have one more doubt, I generated random keys and iv in a servlet and passed it to method. I get the keys and iv fine but the cipher .init method throws InvalidAlgorithmParameter exception now.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
--- Martin Fowler
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |