On Thursday, July 30, 2015 at 5:05:22 PM UTC-4, jean-pierre.muench wrote:
>
> Right now the ECIES definition looks as follows:
>
> template <class EC, class COFACTOR_OPTION = NoCofactorMultiplication, bool
> DHAES_MODE = false>
> struct ECIES
> : public DL_ES<
> DL_Keys_EC<EC>,
> DL_KeyAgreementAlgorithm_DH<typename EC::Point,
> COFACTOR_OPTION>,
> DL_KeyDerivationAlgorithm_P1363<typename EC::Point, DHAES_MODE,
> P1363_KDF2<SHA1> >,
> DL_EncryptionAlgorithm_Xor<HMAC<SHA1>, DHAES_MODE>,
> ECIES<EC> >
> {
> static std::string CRYPTOPP_API StaticAlgorithmName() {return "ECIES";}
> // TODO: fix this after name is standardized
> };
>
>
> Now this means the user is stuck with using HMAC<SHA-1> (for AE) and
> P1363_KDF2<SHA1> (for KDF).
> This bothers me, because the general consensus is to avoid SHA-1 whenever
> possible, although it may be still safe in these two applications.
>
It depends on how long the signature or MAC has to withstand or survive
attack. In its application in the KDF, its acting as a PRF and collisions
are not a concern (some hand waiving). So its fine there. The HMAC is a
different story.
If the HMAC is used to protect a network packet, then the HMAC only needs
to survive the transport's window size. In the case of TCP, that means the
lifetime is bounded and roughly 2MSL. However, a file on a disk is a
different story because its lifetime is unbounded.
> Therefore I'd like to propose the following "new" definition of ECIES,
> enabling the user to easily replace SHA-1 with an algorithm of their choice:
>
> template <class EC, class COFACTOR_OPTION = NoCofactorMultiplication, bool
> DHAES_MODE = false, class H = SHA1>
> struct ECIES
> : public DL_ES<
> DL_Keys_EC<EC>,
> DL_KeyAgreementAlgorithm_DH<typename EC::Point,
> COFACTOR_OPTION>,
> DL_KeyDerivationAlgorithm_P1363<typename EC::Point, DHAES_MODE,
> P1363_KDF2<H> >,
> DL_EncryptionAlgorithm_Xor<HMAC<H>, DHAES_MODE>,
> ECIES<EC> >
> {
> static std::string CRYPTOPP_API StaticAlgorithmName() {return "ECIES";}
> // TODO: fix this after name is standardized
> };
>
>
Yeah, I think we are approaching that pain point.
> Now my questions concerning this:
>
> 1. Should we do it?
>
> Yes, eventually. "Eventually" is kind of vague, but I would say near
future, like within 3 or 6 months.
>
> 1. Why wasn't it done when the class was introduced into Crypto++?
>
> I'm just guessing, but it probably finds its roots in P1363.
>
> 1. Should we also allow people to switch away from HMAC?
>
> Then its no longer ECIES.
>
> 1. Should we also allow people to switch away from P1363_KDF2 in favor
> of HKDF as soon as we have finalized the KeyBasedKeyDerivationFunction
> interface?
>
> Then its no longer ECIES.
We also have Issue 21 (https://github.com/weidai11/cryptopp/issues/21) to
contend with. We are going to have to switch from a byte count to a bit
count for the label. That will ensure conforming behavior from the class.
We lack that now, and that's clearly an interop bug.
Bouncy Castle is also fixing a interop bug. We are trying to roughly
co-incide them so users either library enjoy interop without jumping
through hoops.
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
