OutofMemory with CMSEnvelopedData from fileInputStream

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

OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

Hi there,

 

I’ve some p7m files which I have to validate, their dimension ranges from 100 Mb to 6Gb.

I’m creating CMSEnvelopedData with a FileInputStream this way:

 

CMSEnvelopedData envelopedData = new CMSEnvelopedData(encEnvelopedData);

 

Doing this I get a  java.lang.OutOfMemoryError: Java heap space

 

As far as it seems the only way I have is to raise the Heap Space.

 

Is there a way to get CMSEnveloped data in chunks ?All I have to do is extract the content stream.

 

Below the full code :

 

[snip]

 

            CMSEnvelopedData envelopedData = new CMSEnvelopedData(encEnvelopedData);

           

            RecipientInformationStore recipients = envelopedData.getRecipientInfos();

            RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

            if (recipient != null) {

                  log.info("recipient!=null getting trans");                                  

                 

                  JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

 

                  trans.setMustProduceEncodableUnwrappedKey(true);

                  trans.setProvider(provider);

                  trans.setContentProvider(provider);

                 

                 

                  log.info("returning content!");

                 

                  CMSTypedStream cmsTs= recipient.getContentStream(trans);

                  return cmsTs.getContentStream();

 

                 

            }

[\snip]

 

 

Thanks a lot…

 

Reply | Threaded
Open this post in threaded view
|

Re: OutofMemory with CMSEnvelopedData from fileInputStream

Massimiliano Ziccardi-2
With such big files you should use CMSEnvelopedDataParser (https://github.com/bcgit/bc-java/blob/master/pkix/src/main/java/org/bouncycastle/cms/CMSEnvelopedDataParser.java)

Cheers,
Massimiliano

Il giorno mar 24 set 2019 alle ore 14:28 Emiliano Latini <[hidden email]> ha scritto:

Hi there,

 

I’ve some p7m files which I have to validate, their dimension ranges from 100 Mb to 6Gb.

I’m creating CMSEnvelopedData with a FileInputStream this way:

 

CMSEnvelopedData envelopedData = new CMSEnvelopedData(encEnvelopedData);

 

Doing this I get a  java.lang.OutOfMemoryError: Java heap space

 

As far as it seems the only way I have is to raise the Heap Space.

 

Is there a way to get CMSEnveloped data in chunks ?All I have to do is extract the content stream.

 

Below the full code :

 

[snip]

 

            CMSEnvelopedData envelopedData = new CMSEnvelopedData(encEnvelopedData);

           

            RecipientInformationStore recipients = envelopedData.getRecipientInfos();

            RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

            if (recipient != null) {

                  log.info("recipient!=null getting trans");                                  

                 

                  JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

 

                  trans.setMustProduceEncodableUnwrappedKey(true);

                  trans.setProvider(provider);

                  trans.setContentProvider(provider);

                 

                 

                  log.info("returning content!");

                 

                  CMSTypedStream cmsTs= recipient.getContentStream(trans);

                  return cmsTs.getContentStream();

 

                 

            }

[\snip]

 

 

Thanks a lot…

 

Reply | Threaded
Open this post in threaded view
|

R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

Thanks Massimo,

 

Now I’ve solved the heap problem but I get an error from the  Luna-HSM backing BC as a provider. The error is: Too much data for a single-part operation

The exception rises here:

 

Caused by: com.safenetinc.luna.exception.LunaException: Too much data for a single-part operation

            at com.safenetinc.luna.provider.cipher.LunaCipher.engineDoFinal(LunaCipher.java:595)

            at com.safenetinc.luna.provider.cipher.LunaCipherRSAPKCS.engineDoFinal(LunaCipherRSAPKCS.java:191)

            at com.safenetinc.luna.provider.cipher.LunaCipher.engineDoFinal(LunaCipher.java:526)

            at javax.crypto.Cipher.doFinal(Cipher.java:2164)

            at org.bouncycastle.operator.jcajce.JceAsymmetricKeyUnwrapper.generateUnwrappedKey(Unknown Source)

            at org.bouncycastle.cms.jcajce.JceKeyTransRecipient.extractSecretKey(Unknown Source)

 

 

It seems a matter of key but if I can’t understand why I don’t have the problem if I use the code posted before which in turn produces a heap out of memory with big files.

 

The new code is this:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData));

                         

                                                  

                       

                                                  

                          RecipientInformationStore recipients = envelopedData.getRecipientInfos();

                       

                          log.info("get recipients size:{}",recipients==null?"null":recipients.size());

                          Collection  c = recipients.getRecipients();

                         

                                                  Iterator    it = c.iterator();

                               

                                if (it.hasNext())

                                {

                                    log.info("recipient!=null getting trans");

                                    RecipientInformation   recipient = (RecipientInformation)it.next();

                                   

                                                           JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                               //         trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider(provider);

 

                                                           log.info("Before getContentStream!");

                                                                                               

                                              

                                    OutputStream os= CryptoUtil.getOutputStreamFromUrl(outPath);

                                   

                                    log.info("before buffered write (copyLarge)");

                                    IOUtils.copyLarge(recipient.getContentStream(trans).getContentStream(), os);

                                    

                                    log.info("after copy large!");

                                     

                                     

                                }

                               

                                throw new IllegalArgumentException("recipient for certificate not found");

            }                                 

 

 

Could be a buffer size problem in the IOUTILS.copylarge ?

 

Thanks again

Reply | Threaded
Open this post in threaded view
|

OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?

Reply | Threaded
Open this post in threaded view
|

Re: OutofMemory with CMSEnvelopedData from fileInputStream

Massimiliano Ziccardi-2
Is your LunaSA a network attached device or a PCI device?
If it is a network one, bear in mind that the whole file will be sent to the HSM and back, thus slowing you down.

If it is a PCI device, then definitely the HSM shouldn't be a bottleneck.

Il giorno mer 25 set 2019 alle ore 18:14 Emiliano Latini <[hidden email]> ha scritto:

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?

Reply | Threaded
Open this post in threaded view
|

Re: OutofMemory with CMSEnvelopedData from fileInputStream

Eckenfels. Bernd
In reply to this post by cryptoSad

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini <[hidden email]>
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad
Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?


Inviato da TypeApp
Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini <[hidden email]>
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini <[hidden email]>
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 

D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

RE: OutofMemory with CMSEnvelopedData from fileInputStream

Eckenfels. Bernd
Hello,

Looks right, what’s your speed now?

BTW, is,this an exported key in a localkeystore or is this a Keystore implementation from Luna with a key handle?

Gruss
Bernd

--
http://www.seeburger.com
________________________________________
From: Emiliano Latini [[hidden email]]
Sent: Thursday, September 26, 2019 11:15
To: Emiliano Latini; Eckenfels. Bernd
Cc: [hidden email]
Subject: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Guys I’v tried this way:

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));
                                                           trans.setMustProduceEncodableUnwrappedKey(true);
                                                           trans.setProvider(provider);
                                                           trans.setContentProvider("SunJCE");

where provider is “LunaSA” provider and seems I’ve nailed it.
Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?



Da: Emiliano Latini [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp<http://www.typeapp.com/r?b=15620>
Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]<mailto:[hidden email]>> ha scritto:
For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.


Gruss
Bernd


Von: Emiliano Latini <[hidden email]>
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream


I’ve solved the issue extracting directly the recipient :


RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));






The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:


  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));




And with the buffer used in IOUtils.copylarge used for copying the decripted file:


IOUtils.copyLarge(decryptedStream, os, buf);




Below some execution times:


copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024
copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192
copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384
copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288




could be the HSM the bottleneck?











SEEBURGER AG



Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:



Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1



D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim




Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.









SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|

R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad
Now with a 130 mb file I'm down to 15 secs using Luna's keystore implementation with key handle.


 

-----Messaggio originale-----
Da: Eckenfels. Bernd [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 11:42
A: Emiliano Latini
Cc: [hidden email]
Oggetto: RE: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Hello,

Looks right, what's your speed now?

BTW, is,this an exported key in a localkeystore or is this a Keystore implementation from Luna with a key handle?

Gruss
Bernd

--
http://www.seeburger.com
________________________________________
From: Emiliano Latini [[hidden email]]
Sent: Thursday, September 26, 2019 11:15
To: Emiliano Latini; Eckenfels. Bernd
Cc: [hidden email]
Subject: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Guys I'v tried this way:

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));
                                                           trans.setMustProduceEncodableUnwrappedKey(true);
                                                           trans.setProvider(provider);
                                                           trans.setContentProvider("SunJCE");

where provider is "LunaSA" provider and seems I've nailed it.
Is it right to assume I've getted the key from the HSM and decrypted the content with local software implementation?



Da: Emiliano Latini [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp<http://www.typeapp.com/r?b=15620>
Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]<mailto:[hidden email]>> ha scritto:
For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.


Gruss
Bernd


Von: Emiliano Latini <[hidden email]>
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream


I've solved the issue extracting directly the recipient :


RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));






The problem is the operation is very slow even with a 130mb file. I've tried with the size of inputstream used for the CMSEnvelopedDataParser:


  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));




And with the buffer used in IOUtils.copylarge used for copying the decripted file:


IOUtils.copyLarge(decryptedStream, os, buf);




Below some execution times:


copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024
copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192
copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384
copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288




could be the HSM the bottleneck?











SEEBURGER AG



Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:



Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1



D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim




Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.









SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.


Reply | Threaded
Open this post in threaded view
|

Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Arshad Noor-2
In reply to this post by cryptoSad

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 


D-75015 Bretten


Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0


Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222



Internet: http://www.seeburger.de


Registergericht/Commercial Register:

e-mail: [hidden email]


HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

R: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

Hello Arshad,

thanks for the clarification. It was clear to me the key is exposed, but this happens only for this particular use case when we receive this key from trusted actors in secure ways.The Application servers are also part of the security boundary.

 

cheers

 

 

 

Da: Arshad Noor [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 14:19
A: Emiliano
Latini
Cc: [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?


Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?






 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 

D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

AW: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Eckenfels. Bernd
In reply to this post by Arshad Noor-2

Hello Arschad,

 

it is (if i understood it correct) a signature, the hash can be calculated outside without compromising the key. But for encryption it is also possible you can generate a session key, encrypt with it and then wrap it in the HSM. That does not endanger the data since the component who sees the session key also sees the plaintext data.

 

(But I was also suspicious not all keystores behave sane. Its always a good test to really lock the HSM in fips mode and make the key nonexportable just to be sure a wrong config fails in the test)

 

Gruss

Bernd

 

Von: Arshad Noor <[hidden email]>
Gesendet: Donnerstag, 26. September 2019 14:19
An: [hidden email]
Cc: [hidden email]
Betreff: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?


Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?






 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 

D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

Massimiliano Ziccardi-2
In reply to this post by cryptoSad
The private key should be used only to verify the signature, so only the hash need to be sent to the HSM to verify the signature. 
What need to be exported is the symmetric key used to encrypt and, if I'm not wrong, that is what is happening here and that would explain the speed improvement.

I don't know what restrictions you have to oblige, but as far as I remember Italian laws wanted the HSM to be FIPS3, and if I remember correct with FIPS3 private keys are never exportable

Il giorno gio 26 set 2019 alle ore 14:33 Emiliano Latini <[hidden email]> ha scritto:

Hello Arshad,

thanks for the clarification. It was clear to me the key is exposed, but this happens only for this particular use case when we receive this key from trusted actors in secure ways.The Application servers are also part of the security boundary.

 

cheers

 

 

 

Da: Arshad Noor [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 14:19
A: Emiliano
Latini
Cc: [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?


Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?






 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 

D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

R: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

cryptoSad

I receive an encrypted p7m file which I have to decrypt and extract the content. Given that the symmetric key used for encryption, is contained within the p7m file (encrypted with RSA encryption), what is coming out from the HSM to the local JceSun content provider should be only the decrypted symmetric key.

So no key is coming out from the HSM.

 

Emiliano Latini

Engineering's Software Laboratory

Direct:                     +39 06 87594577      
Mobile:                    +39 347  7906590 
                       
E-mail :                    [hidden email]

Engineering Ingegneria Informatica spa
Piazzale dell’Agricoltura, 24 - 00144 Roma

Segui Engineering su Twitter! (@EngineeringSpA)

www.eng.it

 

 

Da: Massimiliano Ziccardi [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 14:49
A: Emiliano Latini
Cc: Arshad Noor; [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

The private key should be used only to verify the signature, so only the hash need to be sent to the HSM to verify the signature. 

What need to be exported is the symmetric key used to encrypt and, if I'm not wrong, that is what is happening here and that would explain the speed improvement.

 

I don't know what restrictions you have to oblige, but as far as I remember Italian laws wanted the HSM to be FIPS3, and if I remember correct with FIPS3 private keys are never exportable

 

Il giorno gio 26 set 2019 alle ore 14:33 Emiliano Latini <[hidden email]> ha scritto:

Hello Arshad,

thanks for the clarification. It was clear to me the key is exposed, but this happens only for this particular use case when we receive this key from trusted actors in secure ways.The Application servers are also part of the security boundary.

 

cheers

 

 

 

Da: Arshad Noor [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 14:19
A: Emiliano
Latini
Cc: [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 

D-75015 Bretten

Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0

Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222

Internet: http://www.seeburger.de

Registergericht/Commercial Register:

e-mail: [hidden email]

HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: R: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

David Hook-3
This is correct, it will just be the symmetric session key that's come out of the HSM, the private key used to wrap it is still locked in the HSM assuming LunaSA is the provider for the HSM.

As described, the speed issue would have been due to the shuffling of data between the HSM and the computer on decryption. It might be possible to speed that up by providing a custom operator implementation for the content decryption. It's normally pretty expensive to do bulk decryption via a HSM though and as the session keys are single use and protecting data that is already been fully exposed on the computer itself this is usually acceptable - it's the main reason the setContentProvider() method was added.

Regards,

David

On 26/9/19 11:01 pm, Emiliano Latini wrote:

I receive an encrypted p7m file which I have to decrypt and extract the content. Given that the symmetric key used for encryption, is contained within the p7m file (encrypted with RSA encryption), what is coming out from the HSM to the local JceSun content provider should be only the decrypted symmetric key.

So no key is coming out from the HSM.

 

Emiliano Latini

Engineering's Software Laboratory

Direct:                     +39 06 87594577      
Mobile:                    +39 347  7906590 
                       
E-mail :                    [hidden email]

Engineering Ingegneria Informatica spa
Piazzale dell’Agricoltura, 24 - 00144 Roma

Segui Engineering su Twitter! (@EngineeringSpA)

www.eng.it

 

 

Da: Massimiliano Ziccardi [[hidden email]]
Inviato: giovedì 26 settembre 2019 14:49
A: Emiliano Latini
Cc: Arshad Noor; [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

The private key should be used only to verify the signature, so only the hash need to be sent to the HSM to verify the signature. 

What need to be exported is the symmetric key used to encrypt and, if I'm not wrong, that is what is happening here and that would explain the speed improvement.

 

I don't know what restrictions you have to oblige, but as far as I remember Italian laws wanted the HSM to be FIPS3, and if I remember correct with FIPS3 private keys are never exportable

 

Il giorno gio 26 set 2019 alle ore 14:33 Emiliano Latini <[hidden email]> ha scritto:

Hello Arshad,

thanks for the clarification. It was clear to me the key is exposed, but this happens only for this particular use case when we receive this key from trusted actors in secure ways.The Application servers are also part of the security boundary.

 

cheers

 

 

 

Da: Arshad Noor [mailto:[hidden email]]
Inviato: giovedì 26 settembre 2019 14:19
A: Emiliano
Latini
Cc: [hidden email]
Oggetto: Re: R: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I haven't worked with the Luna HSM in nearly 20 years - but looking at this code it seems to me that the private-key has come out of the HSM and is now under the control of the SunJCE (software) provider to perform the cryptographic operation.

Going from 6+ minutes to 15 seconds for a 130MB file indicates that the local computer + software provider is performing the cryptographic operation - not the HSM. This may be acceptable to your business, but given that the point of using an HSM is to protect cryptographic keys, unless the local computer is part of your security boundary, the key has just been exposed. You might want to check with your Security people if that is an acceptable risk for your business use-case.

Arshad Noor
StrongKey

On 9/26/19 2:15 AM, Emiliano Latini wrote:

Guys I’v tried this way:

 

JceKeyTransEnvelopedRecipient trans=new JceKeyTransEnvelopedRecipient((PrivateKey)jcaProvider.getKeystore().getKey(alias,jcaProvider.getPwd().toCharArray()));

                                                           trans.setMustProduceEncodableUnwrappedKey(true);

                                                           trans.setProvider(provider);

                                                           trans.setContentProvider("SunJCE");

 

where provider is “LunaSA” provider and seems I’ve nailed it.

Is it right to assume I’ve getted the key from the HSM and decrypted the content with local software implementation?

 

 

 

Da: Emiliano Latini [[hidden email]]
Inviato: giovedì 26 settembre 2019 09:27
A: Eckenfels. Bernd
Cc: [hidden email]
Oggetto: Re: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

Since the Hsm is a network attached one could make sense to use the hsm provider and BC ad content provider?

Inviato da TypeApp

Il giorno 25 set 2019, alle ore 19:02, "Eckenfels. Bernd" <[hidden email]> ha scritto:

For such a scenario it seems to make sense to fall back to a software hash implementation and do only the signature in the HSM. Thats a bit tricky in terms of compliance and might require some infrastructure to have two providers, but even though HSMs claim ridiculous speeds I would just not use them for hashing large payloads.

 

Gruss

Bernd

 

Von: Emiliano Latini [hidden email]
Gesendet: Mittwoch, 25. September 2019 18:14
An: [hidden email]
Betreff: [dev-crypto] OutofMemory with CMSEnvelopedData from fileInputStream

 

I’ve solved the issue extracting directly the recipient :

 

RecipientInformation recipient = recipients.get(new JceKeyTransRecipientId((java.security.cert.X509Certificate)jcaProvider.getKeystore().getCertificate(alias)));

 

 

 

The problem is the operation is very slow even with a 130mb file. I’ve tried with the size of inputstream used for the CMSEnvelopedDataParser:

 

  CMSEnvelopedDataParser     envelopedData = new CMSEnvelopedDataParser(new BufferedInputStream(encEnvelopedData,parsBuf));

 

 

And with the buffer used in IOUtils.copylarge used for copying the decripted file:

 

IOUtils.copyLarge(decryptedStream, os, buf);

 

 

Below some execution times:

 

copytime:00:06:24.178 With parsebuf:8192 and copybuf:1024

copytime:00:06:46.668 With parsebuf:8192 and copybuf:8192

copytime:00:06:45.187 With parsebuf:16384 and copybuf:16384

copytime:00:06:39.961 With parsebuf:524288 and copybuf:524288

 

 

could be the HSM the bottleneck?





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Axel Haas, Michael Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker

Edisonstr. 1

 


D-75015 Bretten


Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:

Tel.: 07252 / 96 - 0


Prof. Dr. Simone Zeuchner

Fax: 07252 / 96 - 2222



Internet: http://www.seeburger.de


Registergericht/Commercial Register:

e-mail: [hidden email]


HRB 240708 Mannheim

 

Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.