If you have the code with inline assembly for MacOS M1, I can test it.
> On Apr 25, 2023, at 22:39, Jeffrey Walton wrote:
>
>
>
> On Friday, March 31, 2023 at 1:44:41 AM UTC-4 Sam Van Gucht wrote:
> Hi everyone,
>
> We noticed AES GCM in significant slower on M1 compare to an Intel Mac.
I support the idea of adding SIV mode. Except that I prefer AES GCM SIV, as I
like it's key derivation mechanism better.
> On Jul 21, 2022, at 16:20, Alan Gillespie wrote:
>
>
> I have a need for AES SIV Mode as described in RFC 5297, and I wondered
> whether there was anything in the
It should be obvious, but you cannot verify (as in "technically impossible") a
digital signature without having public key of the signer.
It is not recommended to re-invent the basic digital signature algorithms or
implementations.
> On Sep 22, 2021, at 15:30, Luca Bonaldo wrote:
>
> Hi
Sorry, I've no idea what your makefile looks like, or how to convey the working
flags to it.
> On Sep 17, 2021, at 16:39, Samyukta Yagati wrote:
>
> (I currently have -l:libcryptopp.a in my LDFLAGS)
>
>> On Friday, September 17, 2021 at 1:38:31 PM UTC-7 Samyukta Yagati wrote:
>> Ah I see --
Say, you have a file that includes Crypto++ headers and needs linking with
Crypto++ library. And Crypto++ is installed into /usr/local.
Then, the following would be sufficient:
clang++ -o my_binary -I/usr/local/include my_source.cpp -L /usr/local/lib
-lcryptopp -lm
(I'm not sure if "-lm" is
I don't see a good alternative. -fno-lto seems it.
> On May 5, 2021, at 14:23, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> LTO is slowly accumulating bugs. From what I have seen in the
> post-mortems, it looks like LTO is either (1) results in a compile
> error (older compilers) or (2)
ote:
>
>
> Hi Uri,
>
> Thanks.OS version and clang version is project binding right now. But
> certainly, will check.
>
> Do you see any obvious problem in the code snippet I have added in the above
> post?
>
> Regards,
> Sunandan
>
>> On Su
Considering that the current stable version of Clang is 11, would or not make
sense to upgrade your compiler?
Not to mention that your OS probably does not get any security patches now -
so, perhaps, moving from 18.04LTS to 20.04 LTS would be a good idea?
I regularly build with Clang and GCC,
I say let's release.
> On Mar 17, 2021, at 22:29, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> We fixed a nasty little bug in stream ciphers. The bug surfaced when
> inString == outString and the compiler decided to short-circuit the
> transformation during code generation. The bug potentially
each message. (Keeping the IV/nonce
>> same)
>>
>> How about AES-GCM-GMAC? Is it same as AES-GCM?
>>
>> Is AES-GCM-SIV patent free? Does cryptopp provide AES-GCM-SIV library?
>>
>>>> On Feb 25, 2021, at 5:04 PM, Uri Blumenthal wrote:
>>
What is your threat model?
If you can guarantee that a combination of Key + Nonce will not repeat, AES-GCM
is a better choice.
AES-GCM is a yesterday's achievement. A smarter and a more secure altogether
choice today is AES-GCM-SIV.
CBC + HMAC is/was before yesterday.
> On Feb 25, 2021, at
Run cryptest.exe like this:
LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH} ./cryptest.exe TV all
> On Nov 28, 2020, at 20:03, Inês wrote:
>
> Can you give me some help? I am so confused.
>
>> On Saturday, November 28, 2020 at 12:37:59 PM UTC Jeffrey Walton wrote:
>> On Fri, Nov 27, 2020 at 7:33 PM
the “fat” binaries. I can’t even compile the
> library on arm64. There are some Intel-specific code in the library (ie., in
> cpu.h if you look at my original post).
>
>
> On Fri, Oct 16, 2020 at 12:11 AM Uri Blumenthal wrote:
>> IMHO, having a fat library is bad idea becaus
IMHO, having a fat library is bad idea because it doesn't seem to work well fur
the last several years. Wasting space is another reason.
IMHO, you're better off recompiling once you get the new ARM-based Mac. Keep
x86_64 stuff on Intel (don't drag it to ARM), and build ARM-only stuff on ARM.
I have never built Crypto++ as a universal (fat) library, and personally think
it's not a good idea.
> On Oct 14, 2020, at 20:39, Tolu wrote:
>
> Hello,
>
> I am trying to create a universal library (x86_64 and arm64), however, I am
> difficulties building the cryptopp library on arm64 on
Regardless, for *non-cryptographic* purposes you should consider only how well
a given hash performs. MD4 would be fine too.
Having said that, Blake3 probably would be supported (eventually), only
question is when.
Sent from my test iPhone
> On Jan 22, 2020, at 15:16, Michael Nahas wrote:
>
Yes. What RSA provides is KEM - Key Encapsulation Mechanism. You would run
*two* of them - one in reach direction - and then run a KDF over concatenation
of these two encapsulated symmetric keys.
AFAIK, it's the only way. And that's what NIST is doing with their Post-Quantum
competition: they
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
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
I'm for it.
Sent from my test iPhone
> On May 16, 2019, at 19:54, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> I want to split config.h into several smaller files. It should help with
> managing the monolithic config.h, and allow better Autotools integration. As
> it stands we can't use
Correction:
- if you have CLANG compiler from Macports, then do what Jeffrey said below;
- if you have GCC compiler from Macports, then do
$ CXX=/opt/local/bin/g++ make -j 4
Sent from my test iPhone
> On Nov 11, 2018, at 17:34, Jeffrey Walton wrote:
>
> Hi Everyone,
>
> We need someone to
Andrew,
Could you explain why the standard approach like
#include
#include
did not work for you?
P.S. You are NOT supposed to add -I$prefix/include/cryptopp flag. If you do -
please reconsider.
Sent from my test iPhone
> On Aug 21, 2018, at 05:57, Andrew Marlow wrote:
>
>> On
Regardless, I agree that enforcing specified IV length would be a desirable
property and a useful enhancement.
Sent from my test iPhone
> On Jul 6, 2018, at 04:04, Weikeng Chen wrote:
>
> I think crypto libraries have to assume the developers to have some
> familiarity with the cryptography
23 matches
Mail list logo
