[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] RC4Engine issue
|
Hi Craig,
I'll work to enable this feature again. Assuming that we don't want to
keep compatibility to EclipseME metadata, we don't need to mimic the
same behavior we had with Bounce Castle, we can implement this feature
using any cipher available in JavaSE.
In fact, my first thought is to reuse the same encrypt/decrypt mechanism
used by eclipse to save in system keyring. I'll evaluate if we can do
that, and if not, I will take a look at other options to encrypt the
password in project metadata file.
The bad side is that any migration wizard from eclipseME to MTJ projects
that we can come with, will not be able to migrate the passwords, as
we've removed BC and could not mimic its behavior.
Hugo
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Saturday, May 03, 2008 8:52 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] RC4Engine issue
Now that I've had a chance to think this through, I think I made the
wrong statement. There actually is a valid use for storing the password
in the project. By only placing it into the system keyring, it is no
longer possible to move a project from machine to machine without having
to get the password into the keyring. With that said, there is a bit of
a security issue with having it in the project.
I think we should consider whether this function should be restored
(using the underlying JavaSE RC4 engine). Thoughts?
Craig
Raniere Hugo-wha006 wrote:
> 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
>
>
>
------------------------------------------------------------------------
>
>
>
------------------------------------------------------------------------
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> 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
