> I believe I found the issue.
>
> DL_EncryptionAlgorithm_Xor::GetSymmetricKeyLength changed between 5.6.4 and
> 6.0.0:
>
> size_t GetSymmetricKeyLength(size_t plaintextLength) const
> - {return plaintextLength + MAC::DEFAULT_KEYLENGTH;}
> +{return plaintextLength +
On Mon, Jul 1, 2019 at 7:15 PM Uri Blumenthal wrote:
>
> Hopefully it will not impact BouncyCastle interoperability. Now - also Botan
> interoperability.
Yeah, looking at the ECIES tests, it looks like pairwise consistency -
generate a key and then round trip some plaintext.
I think we should
Hopefully it will not impact BouncyCastle interoperability. Now - also Botan
interoperability.
Sent from my test iPhone
> On Jul 1, 2019, at 19:00, Jeffrey Walton wrote:
>
>
>
>> On Monday, July 1, 2019 at 6:48:57 PM UTC-4, Mouse wrote:
>> If memory serves, ECIES standard required
On Monday, July 1, 2019 at 6:48:57 PM UTC-4, Mouse wrote:
>
> If memory serves, ECIES standard required ^authenticated* encryption. That
> means - null hash wasn't allowed.
>
> Besides, there's Moxy Marlinspike principle: "If you don't enforce
> integrity, sooner or later you'll lose
If memory serves, ECIES standard required ^authenticated* encryption. That
means - null hash wasn't allowed.
Besides, there's Moxy Marlinspike principle: "If you don't enforce integrity,
sooner or later you'll lose confidentiality as well."
Having said that, I don't recall why that particular
On Monday, July 1, 2019 at 5:53:45 PM UTC-4, Jeffrey Walton wrote:
>
> On Mon, Jul 1, 2019 at 5:38 PM Andrew Wason wrote:
> >
> > On Monday, July 1, 2019 at 2:51:39 PM UTC-4, Jeffrey Walton wrote:
> >>
> >>
> >> I think this may have something to do with
>
On Mon, Jul 1, 2019 at 5:38 PM Andrew Wason wrote:
>
> On Monday, July 1, 2019 at 2:51:39 PM UTC-4, Jeffrey Walton wrote:
>>
>>
>> I think this may have something to do with
>> https://cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme#Bouncy_Castle_Patch
>> . That section needs to
On Monday, July 1, 2019 at 2:51:39 PM UTC-4, Jeffrey Walton wrote:
>
>
> I think this may have something to do with
> https://cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme#Bouncy_Castle_Patch
>
> . That section needs to clearly state when the change occirs but it does
> not.
On Monday, July 1, 2019 at 4:35:24 PM UTC-4, Jeffrey Walton wrote:
>
>
> We started catching some failed Autotools test on OS X. My MacBook is down
> at the moment so I cannot look at it in detail.
>
> Other than the Autotools tests things look OK.
>
This looks like an Autotools problem:
Hi Everyone,
We started catching some failed Autotools test on OS X. My MacBook is down
at the moment so I cannot look at it in detail.
Other than the Autotools tests things look OK.
Jeff
--
You received this message because you are subscribed to "Crypto++ Users". More
information about
On Monday, July 1, 2019 at 2:07:06 PM UTC-4, Andrew Wason wrote:
>
> We have been using the code below with libcrypto++6 on Ubuntu for years.
> It uses a custom NULLHash implementation to reduce the size of the final
> ciphertext since we are not concerned with message integrity.
>
> I
We have been using the code below with libcrypto++6 on Ubuntu for years. It
uses a custom NULLHash implementation to reduce the size of the final
ciphertext since we are not concerned with message integrity.
I recently tested this with libcrypto 8.2 and the decrypted text is now
partially
You'll probably need to share how you are sending the encrypted message.
Maybe you simply need to use a base64 encoder to get crazy characters out
of the data you send.
On Mon, 1 Jul 2019 at 01:54, Romij Uddin wrote:
> Hello ,
> I have used following code to generate key.
>
Hello ,
I have used following code to generate key.
CryptoPP::AutoSeededRandomPool rng;
CryptoPP::InvertibleRSAFunction parameters;
parameters.GenerateRandomWithKeySize( rng, 1024 );
CryptoPP::RSA::PrivateKey privateKey( parameters );
CryptoPP::RSA::PublicKey publicKey(
14 matches
Mail list logo
