Status of my upgrades and so on

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Status of my upgrades and so on

Werner Dittmann
All,

after we received the cert to sign the JuiCE JCE jar I was able
to produce a signed jar and to use it in a standard J2SDK 1.4.2_xx.

Not to magle around with existing modules I put all new modules
in ad new package: org.apache.security.juice and appropriate
subpackages (the existing package is org.apache.security.jce).

I've used the implementation I did for a test with BouncyCastle,
thus I modeled the new package (roughly) according to the BC structure.
Also I use some BC Java sources, others are heavily modified and
are now sources on their own. These new ones contain the Apache
Licence info. BC files do not contain any licence info (even not
in the original distribution). The BC license explicitly allows
to use sources in the way I did. I'll put the BC license file
in a LICENSES directory anyway.

The native sources are in the directory native/srcNew.

And this is available:

* Ciphers *

AES, DES, DESEDE in ECB and CBC mode, not yet: CFB and OFB
available paddings are: none, PKCS5/PKCS7, ISO10126

RSA RAW, RSA PKCS1padding, RSA OAEP padding

* Digests *

MD2, MD4, MD5, SHA1 (and other SHA up to 512 if the openSSL
library is built to include those), RIPEMD160

* Signatures *

MD5WithRSAEncryption, SHA1WithRSAEncryption (other SHA also
if supported by openSSL, see remark for digests)

standard DSA with SHA1 (EC DSA somewhat prepared, but not fully
implemented)

Unit tests for all implemented algorithms are available.

The native code is standard C, prepared to compile/run also
with X86_64 architecture (not yet fully tested), 32 bit works
ok. Because I'm not familiar with all this autconf and autogen
stuff, I use a simple shell script to run the libtool to
create the shared lib. The native code does not yet include
the openSSL thread lock callbacks (is next on the ToDo list).
If somebody has some more experience with autoconf, autogen etc.
I would appreciate support here.

Last but not least: can some kind soul start a VOTE to give me
checkin authorization - but only in case you would like to have
this new, ultrafast, super-duper, etc etc native openSSL binding :-)

Regards,
Werner





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Status of my upgrades and so on

dims
Am on it :) was waiting for some feedback from incubator pmc since
this is all new code.

thanks,
dims

On 1/18/06, Werner Dittmann <[hidden email]> wrote:

> All,
>
> after we received the cert to sign the JuiCE JCE jar I was able
> to produce a signed jar and to use it in a standard J2SDK 1.4.2_xx.
>
> Not to magle around with existing modules I put all new modules
> in ad new package: org.apache.security.juice and appropriate
> subpackages (the existing package is org.apache.security.jce).
>
> I've used the implementation I did for a test with BouncyCastle,
> thus I modeled the new package (roughly) according to the BC structure.
> Also I use some BC Java sources, others are heavily modified and
> are now sources on their own. These new ones contain the Apache
> Licence info. BC files do not contain any licence info (even not
> in the original distribution). The BC license explicitly allows
> to use sources in the way I did. I'll put the BC license file
> in a LICENSES directory anyway.
>
> The native sources are in the directory native/srcNew.
>
> And this is available:
>
> * Ciphers *
>
> AES, DES, DESEDE in ECB and CBC mode, not yet: CFB and OFB
> available paddings are: none, PKCS5/PKCS7, ISO10126
>
> RSA RAW, RSA PKCS1padding, RSA OAEP padding
>
> * Digests *
>
> MD2, MD4, MD5, SHA1 (and other SHA up to 512 if the openSSL
> library is built to include those), RIPEMD160
>
> * Signatures *
>
> MD5WithRSAEncryption, SHA1WithRSAEncryption (other SHA also
> if supported by openSSL, see remark for digests)
>
> standard DSA with SHA1 (EC DSA somewhat prepared, but not fully
> implemented)
>
> Unit tests for all implemented algorithms are available.
>
> The native code is standard C, prepared to compile/run also
> with X86_64 architecture (not yet fully tested), 32 bit works
> ok. Because I'm not familiar with all this autconf and autogen
> stuff, I use a simple shell script to run the libtool to
> create the shared lib. The native code does not yet include
> the openSSL thread lock callbacks (is next on the ToDo list).
> If somebody has some more experience with autoconf, autogen etc.
> I would appreciate support here.
>
> Last but not least: can some kind soul start a VOTE to give me
> checkin authorization - but only in case you would like to have
> this new, ultrafast, super-duper, etc etc native openSSL binding :-)
>
> Regards,
> Werner
>
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]