I already talked with the upstream author and we figured a possible problem due to an non-locked use of the core function. The cause of this is

unsigned char *tmpval = ec->mem + ec->memlocation;
*tmpval = (*tmpval + 1) & 0xff;
ec->memlocation = ec->memlocation + ec->memblocksize - 1;
ec->memlocation = ec->memlocation % wrap;

which is non-atomic and will thus leads to the out-of-bounds deref. The EC object may only be used by one thread at a time.

It is reproducible on my Debian (stretch). I'm going to minimize the case.

Gpg4win-3.0.3 has been released.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.

For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.

I have exactly the same problem on my Windows 10 machine. I am using bitdefender as virus scanner, but it doesn't work no matter if it is active or not. Windows is fully updated and I am using gpg4win 3.0.3.

@gniibe just checking – any news for 2.2 support? Should I reopen this bug or report a new one against 2.2?

Have posted in gcrypt-devel mailer.. thanks

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

Will be posting it in gcrypt-devel shortly.

Hope you've got the problem with the current naming conventions for arguments and the result by going them. We should either document the arguments properly or change the code as i have pointed out. Since the iterations argument used properly in the case PBKDF2 (type8) within the same wrapper api gcry_kdf_derive.

I would also suggest to discuss this at the gcrypt-devel list so that you can get get comments from others as well.

Your are looking at the libgcrypt code. Unfortunately that does not help us. What I would like to see are two protocol implementations, using sccryptone with libgcrypt and one with anoter scruypt implementation. Do they both work? If so, there is no bug in libgcrypt's code - at best the parameter have been given different names and we can point other name use in the docs.

Here's what i got from 1.8.1 code (downloaded from gnupg).

tests/t-kdf uses test vectors from an I-D and obviously works fine. Maybe that I-D has a different parameter naming than what is used in your examples. I simply can't say without researching the whole thing. Please let t me know a concrete bug where that KDF is not compatible with other implementations. As an example here is one of our test vectors:

With the current implementation when the r is set to GCRY_KDF_SCRYPT, on a 3 core system, it almost took 35 minutes to generate the hash, where as with r=41 it was around 4 minutes and 20 seconds.
when i corrected the the values, i.e. N=16384, p=1 and r=GCRY_KDF_SCRYPT, it took less than a second to generate the hash.

Let me comment this

I am sharing completed info, please look into it, at may I know the cause
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_PROD_2020'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key 88BEBD28 (all)(req_usage=1)
gpg: DBG: checking subkey 022E17B7
gpg: DBG: subkey might be fine
gpg: DBG: using key 022E17B7
gpg: using subkey F423A07D022E17B7 instead of primary key 9D09927E88BEBD28
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: LONG_KID: 'BFFCAF61B48701FD'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=0)
gpg: DBG: using key B48701FD
gpg: using pgp trust model
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key B48701FD (all)(req_usage=2)
gpg: DBG: checking subkey 403048E0
gpg: DBG: usage does not match: want=2 have=1
gpg: DBG: no suitable subkeys found - trying primary
gpg: DBG: primary key usage does not match: want=2 have=5
gpg: DBG: no suitable key found - giving up
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search 0: SUBSTR: 'JPMCBANK_GPG_UAT_2019'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: JPMCBANK_GPG_UAT_2019: skipped: Unusable public key
gpg: E:\New\steps.txt: sign+encrypt failed: Unusable public key
gpg: secmem usage: 1376/32768 bytes in 3 blocks

Multiple confirmations -> Resolved.

With git bisect I tracked it down to a0326ffb755c4a49a259cea3d83831d9ede7d5d9

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

Duplicate of T3576

Hi @aheinecke
Its also german:

GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I've noticed that myself and the cause for this is the code which we use to ensure that the key resolution dialog of Kleopatra opens in the foreground.

Thanks again for the test, your patience and the report :-)

:-)
I can confirm, that 2.0.6-beta14 is working and until now, Outlook did not crash :-)
Great work, thanks!

Ok so I found out that you could even trigger this bug without persistent options just by activating and deactivating any S/MIME option on a mail. This somehow changed the behavior of Outlook.

The segfault from an openSUSE machine looks the same:

I can't tell you from your input what is wrong with your key. Please run