This patch does not seem to bring results with CryptoPP-5.6.2 and BouncyCastle-1.50. After applying the patch, the result still is:
javax.crypto.BadPaddingException: Invalid MAC. at org.bouncycastle.jcajce.provider.asymmetric.ec.IESCipher.engineDoFinal(Unknown Source) at javax.crypto.Cipher.doFinal(Cipher.java:2145) at uijr7.decECAESKey(uijr7.java:482) at uijr7.main(uijr7.java:565) MAC doesn't get computed correctly. It is possible that I don't create/use the ECIES correctly - would appreciate any example of (a) reading ECIES-encrypted file, and (b) creating an ECIES-encrypted byte array. Thanks! On Thursday, April 11, 2013 1:02:26 PM UTC-4, Daniele Perito wrote: > > Jesse and I think we have found the problem. Here is the patch to fix it. > This has been confirmed to work and we were able to encrypt in CryptoPP and > decrypt in Bouncy Castle. > > On Thursday, April 11, 2013 9:32:16 AM UTC-7, Jesse Wilson wrote: >> >> Cryptopp folks, >> >> I'm attempting to interop ECIES encryption between bouncy castle and >> cryptopp. Unfortunately, I've run into a problem and I think it's a bug in >> cryptopp. >> >> When cryptopp creates the digest for ECIES, it sends the payload, >> followed by the encoding parameters, followed by the encoding parameters' >> size in bytes as an 8-byte value. For example, if the encoding parameter is >> 4 bytes long, it writes the length as 00 00 00 00 00 00 00 04. If its 32 >> bytes long it writes00 00 00 00 00 00 00 20. >> >> This is driven by code in >> gfpcrypt.h<http://cryptopp.svn.sourceforge.net/viewvc/cryptopp/trunk/c5/gfpcrypt.h?revision=535&view=markup> >> : >> >> mac.Update(encodingParameters.begin(), encodingParameters.size()); >> if (DHAES_MODE) >> { >> byte L[8] = {0,0,0,0}; >> PutWord(false, BIG_ENDIAN_ORDER, L+4, >> word32(encodingParameters.size())); >> mac.Update(L, 8); >> } >> >> Bouncy castle writes the encoding parameter size in bits as a 4-byte >> value. For example, if the encoding parameter is 4 bytes long it writes 00 >> 00 00 20. If its 32 bytes long, bouncy castle writes 00 00 01 00. >> >> This is driven by code in >> IESEngine.java<http://www.bouncycastle.org/viewcvs/viewcvs.cgi/java/crypto/src/org/bouncycastle/crypto/engines/IESEngine.java?revision=1.10&view=markup> >> : >> >> byte[] L2 = new byte[4]; >> >> if (V.length != 0) >> { >> if (P2 != null) >> { >> Pack.intToBigEndian(P2.length * 8, L2, 0); >> } >> else >> { >> Pack.intToBigEndian(0, L2, 0); >> } >> } >> >> ... >> >> if (V.length != 0) >> >> { >> mac.update(L2, 0, L2.length); >> } >> >> I cross >> posted<http://bouncy-castle.1462172.n4.nabble.com/Problem-with-the-way-IESEngine-HMAC-s-the-encoding-parameters-length-td4655770.html>this >> message to the bouncy castle list, and David Hook replied with a quote >> from Victor Shoup's paper <http://www.shoup.net/papers/iso-2_1.pdf>: >> >> In particular, we multiply |L| by 8 so as to encode the length of L in >> bits, rather than bytes, since the IEEE P1363a version of ECIES allows >> (in theory, but not really in practice) messages and labels that are bit >> strings rather than byte strings. >> >> Is it a bug? >> >> Thanks! >> > -- -- 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/groups/opt_out.
