[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] RC4Engine issue
|
Hugo,
I took some time to look into what is going on here. Based on that, I
have a few thoughts...
First, in terms of EclipseME -> MTJ project transition, I've always
assumed we would need to create some simple migration tools to make that
happen. I'm not terribly worried about it to be honest. I think we
should just get the first MTJ release out the door and then we can look
to address things like that.
In terms of the RC4Engine stuff... I think this should not be done as it
is now. I think that this keystore password should actually live in the
standard Eclipse keystore/keychain. I know there is work going on in
Eclipse 3.4 around a new "secure storage" facility. That is really where
this password for the keystore should live. The key to making this work
correctly is making sure that it accounts for the fact that each project
can have a different signing keystore and thus a different keystore
password. Thus, I believe the RC4engine stuff should just get thrown
away and the password moved into Eclipse secure storage.
Craig
Raniere Hugo-wha006 wrote:
Hi Craig,
We’ve removed the class RC4Engine that came from BouncyCastle as per
Eclipse IP Team request.
The only class that references it is
org.eclipse.mtj.core.model.impl.MetaData.java from
org.eclipse.mtj.core plug-in. It is used to encrypt and decrypt
keystore and key passwords in a project metadata file .mtj (formerly
.eclipseme).
For a first solution I’ve commited the classes w/out Encryptation /
decryptation, the data is only converted to base64.
Now, I’m working in a replacement for the RC4Engine class.
I was able to use the RC4 implementation that comes with default JCE providers through
javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("RC4");
This algorithm is available since JDK 1.4.2.
However, the key scheme used by JCE is very different from the one you originally used.
According to the latest version in EclipseME SVN
(http://eclipseme.svn.sourceforge.net/viewvc/eclipseme/trunk/eclipseme-src/plugins/eclipseme.core/src/eclipseme/core/model/impl/MetaData.java?view=markup)
you’ve used the UTF-8 converted bytes from the string EclipseME as the
key for RC4 algorithm.
Unfortunately I could not reproduce this same behavior using JCE. The
only way I could get a valid RC4 key was through a KeyGenerator
object, generating a key different from the one you used in EclipseME.
The bad side is that this will break the compatibility from MTJ and
EclipseME (Projects created using EclipseME will not have their
password retrieved correctly when moved to MTJ).
In fact, I’ve just realized that we haven’t thought about this
compatibility, as we’ve changed the project metadata file name from
.eclipseme to .mtj, what implies that after importing projects created
with eclipseme into MTJ, users must convert their projects to J2ME
projects via the J2ME option in projects popup menu. Do you think
breaking this compatibility is a big issue, or are you ok with that,
given that it is a new project? In the future we can implement a
project migration wizard from EclipseME to MTJ if we think is necessary.
Given that this compatibility will be broken, do you have any hints of
how can you handle the encryptation/decryptation of user password?
Looking forward to hear from you,
Hugo
PS. Sorry for this long e-mail, I was just trying to give you (and
other mail-list members) as much information as I can about the
problem. Feel free to contact me if you didn’t understand or need a
better explanation on anything in this mail
------------------------------------------------------------------------
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
