| RE: [dsdp-mtj-dev] RC4Engine issue |
Hi Craig, Thanks for you feedback and promptly reply. So we agree that there will be a compatibility break between MTJ and EclipseME. I'll update plans to include the creation of migration wizards. Reg. RC4, I've removed the UI and all the respective code to store password in user's project, leaving only the options to store them in workspace keyring or prompt when necessary. :) Hugo -----Original Message----- From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera Sent: Saturday, April 26, 2008 2:17 PM To: Mobile Tools for The Java Platform mailing list Subject: 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-s rc/plugins/eclipseme.core/src/eclipseme/core/model/impl/MetaData.java?vi ew=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 > _______________________________________________ dsdp-mtj-dev mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
Attachment:
before.JPG
Description: before.JPG
Attachment:
after.JPG
Description: after.JPG
