Hmac-SHA256 vs SHA256

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

Hmac-SHA256 vs SHA256

Bidewell, Mark

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.
Reply | Threaded
Open this post in threaded view
|

Re: Hmac-SHA256 vs SHA256

David Hook

Either a HMAC or a digest can be used as a PRF (pseudo random function...) for password based encryption.

These days it appears everyone has settled on PBKDF2 (from PKCS#5) - so I'd recommend using SecretKeyFactory and " PBKDF2". I think the regular BC API only supports SHA-1 and GOST-3411 at the moment. SHA-2 support is on it's way, it's working in the FIPS API but we'll probably wait till we've finished testing before migrating it across.

Regards,

David

On 24/07/15 05:45, Bidewell, Mark wrote:

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Bidewell, Mark

So something along the lines of:

 

SecretKeyFactory.getInstance(“PBKDF2”);

.

.

.

Cipher.getInstance(“AES/CBC/PKCS5Padding”);

 

?

 

What controls the strength of the AES encryption in this case?

 

Thanks.

 

From: David Hook [mailto:[hidden email]]
Sent: Thursday, July 23, 2015 4:18 PM
To: [hidden email]
Subject: Re: [dev-crypto] Hmac-SHA256 vs SHA256

 


Either a HMAC or a digest can be used as a PRF (pseudo random function...) for password based encryption.

These days it appears everyone has settled on PBKDF2 (from PKCS#5) - so I'd recommend using SecretKeyFactory and " PBKDF2". I think the regular BC API only supports SHA-1 and GOST-3411 at the moment. SHA-2 support is on it's way, it's working in the FIPS API but we'll probably wait till we've finished testing before migrating it across.

Regards,

David

On 24/07/15 05:45, Bidewell, Mark wrote:

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

 

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.
Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Eckenfels. Bernd
In reply to this post by Bidewell, Mark
What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd


From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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: Hmac-SHA256 vs SHA256

David Hook
In reply to this post by Bidewell, Mark

PBEKeySpec

Regards,

David

On 24/07/15 06:23, Bidewell, Mark wrote:

So something along the lines of:

 

SecretKeyFactory.getInstance(“PBKDF2”);

.

.

.

Cipher.getInstance(“AES/CBC/PKCS5Padding”);

 

?

 

What controls the strength of the AES encryption in this case?

 

Thanks.

 

From: David Hook [[hidden email]]
Sent: Thursday, July 23, 2015 4:18 PM
To: [hidden email]
Subject: Re: [dev-crypto] Hmac-SHA256 vs SHA256

 


Either a HMAC or a digest can be used as a PRF (pseudo random function...) for password based encryption.

These days it appears everyone has settled on PBKDF2 (from PKCS#5) - so I'd recommend using SecretKeyFactory and " PBKDF2". I think the regular BC API only supports SHA-1 and GOST-3411 at the moment. SHA-2 support is on it's way, it's working in the FIPS API but we'll probably wait till we've finished testing before migrating it across.

Regards,

David

On 24/07/15 05:45, Bidewell, Mark wrote:

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

 

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Bidewell, Mark
In reply to this post by Eckenfels. Bernd

I am working on a solution for secure archival of files potentially containing personally-identifiable information.  It seems to me the issue is two-fold. 

1.       Obviously a secure algorithm with cannot be readily cracked.

2.       A key created in a secure enough manner that the key cannot be easily replicated.

Am I thinking about this correctly?  Also when you say integrity protection do you mean insurance that the encrypted data has not been altered?

 

Thanks

 

From: Eckenfels. Bernd [mailto:[hidden email]]
Sent: Thursday, July 23, 2015 4:32 PM
To: Bidewell, Mark; [hidden email]
Subject: RE: Hmac-SHA256 vs SHA256

 

What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd

From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.
Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Bidewell, Mark
Yes, that was my plan

From: David Hook [[hidden email]]
Sent: Thursday, July 23, 2015 5:14 PM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


Hmmm. Are you thinking of using PBE for encrypting the files?

On 24/07/15 06:41, Bidewell, Mark wrote:

I am working on a solution for secure archival of files potentially containing personally-identifiable information.  It seems to me the issue is two-fold. 

1.       Obviously a secure algorithm with cannot be readily cracked.

2.       A key created in a secure enough manner that the key cannot be easily replicated.

Am I thinking about this correctly?  Also when you say integrity protection do you mean insurance that the encrypted data has not been altered?

 

Thanks

 

From: Eckenfels. Bernd [[hidden email]]
Sent: Thursday, July 23, 2015 4:32 PM
To: Bidewell, Mark; [hidden email]
Subject: RE: Hmac-SHA256 vs SHA256

 

What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey
();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd

From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.
Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Bidewell, Mark
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David

PS. I guess I should mention that in addition to be being directly involved in the Bouncy Castle project, the company I work for provides commercial support for it. I'm not actually sure if you need or not at this stage, but it does sound like it would help.

On 24/07/15 10:26, Bidewell, Mark wrote:
Yes, that was my plan

From: David Hook [[hidden email]]
Sent: Thursday, July 23, 2015 5:14 PM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


Hmmm. Are you thinking of using PBE for encrypting the files?

On 24/07/15 06:41, Bidewell, Mark wrote:

I am working on a solution for secure archival of files potentially containing personally-identifiable information.  It seems to me the issue is two-fold. 

1.       Obviously a secure algorithm with cannot be readily cracked.

2.       A key created in a secure enough manner that the key cannot be easily replicated.

Am I thinking about this correctly?  Also when you say integrity protection do you mean insurance that the encrypted data has not been altered?

 

Thanks

 

From: Eckenfels. Bernd [[hidden email]]
Sent: Thursday, July 23, 2015 4:32 PM
To: Bidewell, Mark; [hidden email]
Subject: RE: Hmac-SHA256 vs SHA256

 

What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey
();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd

From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.
Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

David Hook

Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David

PS. I guess I should mention that in addition to be being directly involved in the Bouncy Castle project, the company I work for provides commercial support for it. I'm not actually sure if you need or not at this stage, but it does sound like it would help.

On 24/07/15 10:26, Bidewell, Mark wrote:
Yes, that was my plan

From: David Hook [[hidden email]]
Sent: Thursday, July 23, 2015 5:14 PM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


Hmmm. Are you thinking of using PBE for encrypting the files?

On 24/07/15 06:41, Bidewell, Mark wrote:

I am working on a solution for secure archival of files potentially containing personally-identifiable information.  It seems to me the issue is two-fold. 

1.       Obviously a secure algorithm with cannot be readily cracked.

2.       A key created in a secure enough manner that the key cannot be easily replicated.

Am I thinking about this correctly?  Also when you say integrity protection do you mean insurance that the encrypted data has not been altered?

 

Thanks

 

From: Eckenfels. Bernd [[hidden email]]
Sent: Thursday, July 23, 2015 4:32 PM
To: Bidewell, Mark; [hidden email]
Subject: RE: Hmac-SHA256 vs SHA256

 

What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey
();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd

From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Uri Blumenthal
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David

PS. I guess I should mention that in addition to be being directly involved in the Bouncy Castle project, the company I work for provides commercial support for it. I'm not actually sure if you need or not at this stage, but it does sound like it would help.

On 24/07/15 10:26, Bidewell, Mark wrote:
Yes, that was my plan

From: David Hook [[hidden email]]
Sent: Thursday, July 23, 2015 5:14 PM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


Hmmm. Are you thinking of using PBE for encrypting the files?

On 24/07/15 06:41, Bidewell, Mark wrote:

I am working on a solution for secure archival of files potentially containing personally-identifiable information.  It seems to me the issue is two-fold. 

1.       Obviously a secure algorithm with cannot be readily cracked.

2.       A key created in a secure enough manner that the key cannot be easily replicated.

Am I thinking about this correctly?  Also when you say integrity protection do you mean insurance that the encrypted data has not been altered?

 

Thanks

 

From: Eckenfels. Bernd [[hidden email]]
Sent: Thursday, July 23, 2015 4:32 PM
To: Bidewell, Mark; [hidden email]
Subject: RE: Hmac-SHA256 vs SHA256

 

What are you planning to do? Encrypt some data with a symmetric cipher where you derive the key from a password, or do you want to "only" hash your password to make sure it cannot be recovered?

If you do encryption, do also need integrity protection? (In that case I would not use the PBE ciphers but only use the Key Derivation Function).

If you want to do a password hashing for the purpose of protection, then you should use the Key Factory, it allows better configuration of all aspects of the key derivation (including the method to get the password bytes).

PKCS#5v2 with HMAC-SHA256 would be:

PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
gen.init("password".getBytes("UTF-8"), "salt".getBytes(), 4096);
byte[] dk = ((KeyParameter) gen.generateDerivedParameters(256)).getKey!
 
();

(PKCS5S2 Parameter Generator of BC implicitely uses HMAC construct with the given digest. Its quite confusing and not very well documented:
http://grepcode.com/file/repo1.maven.org/maven2/org.bouncycastle/bcprov-ext-jdk14/1.51/org/bouncycastle/crypto/generators/PKCS5S2ParametersGenerator.java/#36)

Here is some more sample code and discussion (including a JCE version):

http://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java

Gruss
Bernd

From: Bidewell, Mark [[hidden email]]
Sent: Thursday, July 23, 2015 21:45
To: [hidden email]
Subject: [dev-crypto] Hmac-SHA256 vs SHA256

I’m a newbie to the world of encryption and am getting confused on Password digests.  I am considering using the: pbewithsha256and128bitaes-cbc-bc algorithm, but it seems from reading that Hmac-SHA256 should be used over plain SHA256.  Does pbewithsha256and128bitaes-cbc-bc use Hmac or is there a way to use Hmac-SHA256 with 128 bit AES?  Alternatively, is Hmac important for password digests?

 

Thanks.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.





 

 

 

 

SEEBURGER AG

 

Vorstand/SEEBURGER Executive Board:

Sitz der Gesellschaft/Registered Office:

 

Bernd Seeburger, Axel Haas, Michael Kleeberg, Friedemann Heinz, 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.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

This message, including any attachments, is intended only for the recipient(s) named above. It may contain confidential and privileged information. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message. Also, please be aware that if you are not the intended recipient, any review, disclosure, copying, distribution or any action or reliance based on this message is prohibited by law.

Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

David Hook

It kind of depends on what the files are and what "protecting them" means.

In a situation with multiple files, there's two immediate outcomes if you the architecture says "use PBE", you either have every file getting encrypted with the same password, or you end up with many many passwords, so PBE as the immediate solution is highly problematic, it's either unsafe due to key overuse, or it's unmanageable. For the files, they get the best odds if they are encrypted using quality random keys, the question then is how you protect the random keys, not to mention what "quality random key" actually means.

Regards,

David

On 26/07/15 22:19, Uri Blumenthal wrote:
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David


Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Arshad Noor
Another option is to use something that's built on top of BC - something that gives you encryption, uses digital signatures of meta-data to protect from unauthorized decryption, uses a centralized key-management system, is integrated with FIPS 140-2 HSMs (if desired) and is open-source too.

This tool is being used by a very large e-commerce company in North America to encrypt more than 50 million files with more than 45 million keys (they switched to using fewer keys when they realized the default setting was using a unique AES key per file).  You can read more about the overall architecture here.

Arshad Noor
StrongAuth, Inc.

On 7/26/2015 3:05 PM, David Hook wrote:

It kind of depends on what the files are and what "protecting them" means.

In a situation with multiple files, there's two immediate outcomes if you the architecture says "use PBE", you either have every file getting encrypted with the same password, or you end up with many many passwords, so PBE as the immediate solution is highly problematic, it's either unsafe due to key overuse, or it's unmanageable. For the files, they get the best odds if they are encrypted using quality random keys, the question then is how you protect the random keys, not to mention what "quality random key" actually means.

Regards,

David

On 26/07/15 22:19, Uri Blumenthal wrote:
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David



Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

Uri Blumenthal
In reply to this post by David Hook
Isn't "every file by the same password" essentially what WDE and TrueCrypt-style solutions do? Or do you mean that you prefer a solution that protects random keys with that one password?

As for "quality random key" - again I'm interested. Are you saying that you don't trust available RNGs? Or are uniformly distributed RNG-generated bit strings not good enough?

Sent from my iPad

On Jul 26, 2015, at 18:05, David Hook <[hidden email]> wrote:


It kind of depends on what the files are and what "protecting them" means.

In a situation with multiple files, there's two immediate outcomes if you the architecture says "use PBE", you either have every file getting encrypted with the same password, or you end up with many many passwords, so PBE as the immediate solution is highly problematic, it's either unsafe due to key overuse, or it's unmanageable. For the files, they get the best odds if they are encrypted using quality random keys, the question then is how you protect the random keys, not to mention what "quality random key" actually means.

Regards,

David

On 26/07/15 22:19, Uri Blumenthal wrote:
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David


Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

David Wall
This doesn't resolve the issue of whether you use the same password repeated or not, but if you do have a good password, it should remain secure until it's stolen (which sadly can be hard to know for sure). But that's true of all security tradeoffs that must be made to be practically useful.  If you do lots of files with the same password, it can be a nightmare if you know the password is compromised or otherwise wish to change it unless you offer a bulk file re-encryption feature.

A good technique if you can control the file format using your encryption/decryption tool is to use PBE to encrypt just the AES key that encrypts the contents of the file.  Since AES keys are essentially random data, using PBE to encrypt lots of random data keys does not ease cryptanalyis (same for AES key per file), and it's all much harder than guessing the password if strong passwords are used. 

Basic idea: generate AES key; encrypt file using AES key; PBE encrypt the AES key; append PBE-encrypted key to file.  On reverse, extract PBE-encrypted key; decrypt the AES key using PBE; decrypt rest of file using that AES key. 

Not sure if it helps much, but as files often have common header/initial data (magic numbers), some will append a fixed amount of random data to the front of the file before encrypting and then can discard that on decryption. Adding a hash at the end unless using authenticated encryption/HMAC allows you to verify that nothing has been tampered with before you begin the decryption process.

Now this depends on whether your life depends on the encryption or not, and whether your files are likely to be the focus on a concerted attack by a powerful entity.  As computer hardware, operating systems, software, networks, physical locations and users themselves are far from ideally secure, you likely have to settle for good enough, which assuming you have not already been hacked and can choose good passwords, should work.

On 7/27/15 5:23 AM, Uri Blumenthal wrote:
Isn't "every file by the same password" essentially what WDE and TrueCrypt-style solutions do? Or do you mean that you prefer a solution that protects random keys with that one password?

As for "quality random key" - again I'm interested. Are you saying that you don't trust available RNGs? Or are uniformly distributed RNG-generated bit strings not good enough?

Sent from my iPad

On Jul 26, 2015, at 18:05, David Hook <[hidden email]> wrote:


It kind of depends on what the files are and what "protecting them" means.

In a situation with multiple files, there's two immediate outcomes if you the architecture says "use PBE", you either have every file getting encrypted with the same password, or you end up with many many passwords, so PBE as the immediate solution is highly problematic, it's either unsafe due to key overuse, or it's unmanageable. For the files, they get the best odds if they are encrypted using quality random keys, the question then is how you protect the random keys, not to mention what "quality random key" actually means.

Regards,

David

On 26/07/15 22:19, Uri Blumenthal wrote:
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David



Reply | Threaded
Open this post in threaded view
|

RE: Hmac-SHA256 vs SHA256

David Hook
In reply to this post by Uri Blumenthal

I think David W more than covered the first one. With the RNG, I wouldn't say I don't trust them (as in the algorithms, other the obvious ones... but I digress...) it's more that it's important to pay attention to how they get seeded and how often, especially when you are using them for generating keys. I may be wrong, but my overwhelming impression is that this an area a lot of developers still don't quite get.

Regards,

David

On 27/07/15 22:23, Uri Blumenthal wrote:
Isn't "every file by the same password" essentially what WDE and TrueCrypt-style solutions do? Or do you mean that you prefer a solution that protects random keys with that one password?

As for "quality random key" - again I'm interested. Are you saying that you don't trust available RNGs? Or are uniformly distributed RNG-generated bit strings not good enough?

Sent from my iPad

On Jul 26, 2015, at 18:05, David Hook <[hidden email]> wrote:


It kind of depends on what the files are and what "protecting them" means.

In a situation with multiple files, there's two immediate outcomes if you the architecture says "use PBE", you either have every file getting encrypted with the same password, or you end up with many many passwords, so PBE as the immediate solution is highly problematic, it's either unsafe due to key overuse, or it's unmanageable. For the files, they get the best odds if they are encrypted using quality random keys, the question then is how you protect the random keys, not to mention what "quality random key" actually means.

Regards,

David

On 26/07/15 22:19, Uri Blumenthal wrote:
Now I'm interested. What scheme *would* you use to protect multiple files? TrueCrypt container? EncFS? PGP? Note that they all end up relying on a password, one way or another. 

Sent from my iPad

On Jul 26, 2015, at 02:15, David Hook <[hidden email]> wrote:


Yes. I would not use PBE to protect the individual files.

Regards,

David

On 26/07/15 03:50, Bidewell, Mark wrote:
The number is unknown, the test files I have been using range from 8KB to 78MB.  Would you suggest another protection scheme than PBE?

From: David Hook [[hidden email]]
Sent: Saturday, July 25, 2015 12:11 AM
To: Bidewell, Mark
Subject: Re: [dev-crypto] RE: Hmac-SHA256 vs SHA256


There is a good chance that will end badly.

How many files are you talking? How long should the secrecy on them be preserved? How big are they?

Regards,

David