wood burning stoves 2.0*
The moose likes Java in General and the fly likes Is cast5 128 supported by default sun JCE provider? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Is cast5 128 supported by default sun JCE provider?" Watch "Is cast5 128 supported by default sun JCE provider?" New topic
Author

Is cast5 128 supported by default sun JCE provider?

Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
I have intent to avoid using Bouncy Castle provider. I want to know if RSA(Asymmetric Algorithm) CAST5 cipher supported?


SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Amandeep Singh wrote:I have intent to avoid using Bouncy Castle provider. I want to know if RSA(Asymmetric Algorithm) CAST5 cipher supported?


RCA - yes. CAST5 - no. What makes CAST5 a requirement?


Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
The vendor has given us public key and told us to import using default options in gpg. The default says Rsa cast5. So let me confirm this, we can encrypt file using public key with any cipher want. And they can decrypt the file with any rsa cipher. Is this correct?
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Amandeep Singh wrote:The vendor has given us public key and told us to import using default options in gpg. The default says Rsa cast5. So let me confirm this, we can encrypt file using public key with any cipher want. And they can decrypt the file with any rsa cipher. Is this correct?


There is no explicit GPG/PGP functionality in the JCE. Given a lot of time and effort you could implement GPG/PGP on top of the JCE though you would end up duplicating the effort of Bouncy Castle. I would most definitely not recommend this approach.

Importing the vendors public key into GPG is trivial. You could do it using the Bouncy Castle PGP API but it is a one liner using the 'gpg' command line program.

Once you have imported the public key, you can encrypt a file using the public key and any one of the symmetric algorithms available in your PGP/GPG implementation. Again this can be done using the Bouncy Castle PGP API but it is a one liner using the 'gpg' command line program.

Be aware that not all implementations of PGP implement ALL the symmetric algorithms so you need to establish what algorithms are available to your vendor though you can pretty much rely on CAST5 being available.

I would recommend that whenever you encrypt a file for you vendor using his public key that you also encrypt it with your own encryption public key and that you sign it using a separate signing private key. This way you can always recover the original file and you can prove that you signed it. You should not use the same key pair for both encryption and signing; it is considered insecure.

I don't know the context in which you are doing this work so I can't recommend whether you should go with Bouncy Castle or 'gpg'.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Thanks for reply.

I can let you know our setup plan, they have provided instructions for gpg only. They accept *.pgp, *.gpg, *.asc.
1) gpg --gen-key (Generate key pair using the default options, this i realized myself the default options are RSA-CAST5. So they don't say specifically which algorithm to use.)
2) gpg --import-key <vendor's key file>
3) gpg --sign-key <vendor's key user id> When prompted password, use the secret pass phrase from step 1. Basically we are signing the vendor key with our key phrase.
4) gpg --out <output file name> -r <vendor's key user id> -q --batch --encrypt <full path to file to encrypt>

Do you think this setup addresses your concern-

I would recommend that whenever you encrypt a file for you vendor using his public key that you also encrypt it with your own encryption public key and that you sign it using a separate signing private key. This way you can always recover the original file and you can prove that you signed it. You should not use the same key pair for both encryption and signing; it is considered insecure.


To recover the original file, we can have original file saved with us on disk. Even then, encrypted file sent to them using their public key could never be cross checked with our public key encrypted file.


Questions:

1) I'm confused here vendor told us to use gpg, is it possible we can still encrypt the file using SunJCE or Bouncy Castle?
2) Is it possible I do the above 4 steps in gpg, after signing the vendor's key with our pass phrase. Then I export the signed key to be used in SunJCE or Bouncy Castle?
3) Is there any way to figure out from their public key, what pubkey and algorithm is being used?
4) Does extensions really matter *.pgp, *.gpg, *.asc? Can I give arbitrary name to extensions.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Amandeep Singh wrote:Thanks for reply.

<snip/>

4) gpg --out <output file name> -r <vendor's key user id> -q --batch --encrypt <full path to file to encrypt>

Do you think this setup addresses your concern-


No - you are relying on having the original file. In step 4 you are allowed to encrypt with more than one public key. Encrypt with your vendors public key and your own public key (generate another key for this purpose).

PGP encrypts in two stages. First it creates a random symmetric algorithm key and then encrypts that with each of the specified public keys and writes each encrypted session key to the output file together with information identifying the owner of the key. It then uses the random session key using the symmetric algorithm of choice to encrypt the input file and writes that to the output file. In this way all the recipients receive an identical copy of the encrypted file which any one of them can decrypt. You would then have an identical copy of the encrypted file to that sent to your vendor and you could get rid of the original file.



I would recommend that whenever you encrypt a file for you vendor using his public key that you also encrypt it with your own encryption public key and that you sign it using a separate signing private key. This way you can always recover the original file and you can prove that you signed it. You should not use the same key pair for both encryption and signing; it is considered insecure.


To recover the original file, we can have original file saved with us on disk. Even then, encrypted file sent to them using their public key could never be cross checked with our public key encrypted file.


Questions:

1) I'm confused here vendor told us to use gpg, is it possible we can still encrypt the file using SunJCE or Bouncy Castle?

I thought I had covered that - there is no PGP API in the JCE.

2) Is it possible I do the above 4 steps in gpg, after signing the vendor's key with our pass phrase. Then I export the signed key to be used in SunJCE or Bouncy Castle?

The Bouncy Castle PGP API can directly use the 'gpg' public key and private key file; no export is required. There is no PGP API in the JCE SunJCE.


3) Is there any way to figure out from their public key, what pubkey and algorithm is being used?


The Bouncy Castle API and 'gpg' can both supply information about what type of public key (RSA,DSA etc) is being provided but I'm pretty sure, but not certain, the the symmetric algorithm is not part of the key file. I can see little reason for it to be part of the key file except as to possibly indicate which symmetric algorithm(s) is/are supported by the key owner. Check the PGP specification.


4) Does extensions really matter *.pgp, *.gpg, *.asc? Can I give arbitrary name to extensions.


No - though it might confuse your vendor if you use a non-standard extension..
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Thanks. So I got you, using out of box SunJCE won't be sufficient since it does not provides PGP functionality.

I'm using below class from Bouncy Castle. It works for me. I'm using -a -i as the arguments.

1) Does below code means I'm using RSA/CAST5? It doesn't says we are using RSA or not.
2) Is below code equivalent to following command- gpg --out input.csv.asc –r <user name is not shown here> -q --batch --encrypt input.csv ?

James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Amandeep Singh wrote:

I'm using below class from Bouncy Castle. It works for me. I'm using -a -i as the arguments.

1) Does below code means I'm using RSA/CAST5? It doesn't says we are using RSA or not.
2) Is below code equivalent to following command- gpg --out input.csv.asc –r <user name is not shown here> -q --batch --encrypt input.csv ?


By the time I have trawled though all of that code looking for conformance with your 'gpg' command line you could have tested it 50 times! If your public key is an RSA public key then it will use RSA (I'm pretty sure that DSA key do not at this time support encryption, just signing). As to whether it user CASTE5 - I don't know since I have not gone into that sort of detail with the Bouncy Castle PGP API but I' pretty sure that I can easily find out by looking at the source.

Seems a bit pointless just creating a Java 'gpg' equivalent command line tool when you have 'gpg' in all it's glory with 20 odd years of development and bug fiixing behind it.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Thanks for help.

James Sabre wrote:
By the time I have trawled though all of that code looking for conformance with your 'gpg' command line you could have tested it 50 times! If your public key is an RSA public key then it will use RSA (I'm pretty sure that DSA key do not at this time support encryption, just signing). As to whether it user CASTE5 - I don't know since I have not gone into that sort of detail with the Bouncy Castle PGP API but I' pretty sure that I can easily find out by looking at the source.

Seems a bit pointless just creating a Java 'gpg' equivalent command line tool when you have 'gpg' in all it's glory with 20 odd years of development and bug fiixing behind it.


Inside the code it is using CAST5, this I am sure. So you confirmed me very well, if my public key is RSA, then it would use RSA.
I'm not creating equivalent gpg tool, I am just adhering to vendors requirement so what they asked for, I am doing the same thing using Bouncy Castle.
 
 
subject: Is cast5 128 supported by default sun JCE provider?