fix ctr mode when counter overflows.

resolve merge conflicts

It might have unwanted side-effects - I am not sure. Anyway for me it works.

I've added few new CTR test vectors to tests/basic.c for checking 32-bit and 64-bit carry overflow cases, rC971d372f512ff6805d5b8b54e9ac1446f3f66643

If it is that simple I really do not understand why this is not upstream. o.O

LGTM

Good catch on using the counter to foil "smart" algorithms.

I had to patch strace to follow threads but not forks (P8) and then when built with support for -k I tracked it down: In the inbound handler we close the fd immediately on EOF. However the upper layers don't know about it and a select fails with EBADF. Of course we could ignore the EBADF, figure out the closed fd and restart. The problem is that another thread may have opened a new oobject and that will get the last closed fd assigned - bummer.

Just noticed that due to me failing to properly understand re-entrant locks the run-thread test is broken at least on windows in that it never waits for completion. So running out of filedescriptors is to expect. I'll fix the test.

My observation from running the verify threaded test on windows is that it does behave differently. The EBADF does not occur.

Nope

• --import-options restore
  • Implies
    • import-local-sigs
    • keep-ownertrust
  • Turns off
    • import-minimal
    • import-clean
    • repair-pks-subkey-bug
    • merge-only

• --export-options backup
  • Implies
    • export-local-sigs
    • export-attributes
    • export-sensitive-revkeys
  • Turns off
    • export-clean
    • export-minimal
    • export-pka
    • export-dane
  • Causes build_packet_and_meta() to be used instead of build_packet()
    • This variant also writes the meta data using ring trust packets.
      • a8895c99a7d0
        • Ring trust packets are implementation defined and have always been used in gpg to cache the signature verification status.
        • Ring trust packets are only exported with the export option "backup" and only imported with the import option "restore".
        • As a side-effect of this patch the signature status cache works again and "gpg --check-sigs" is thus much faster.
      • RFC 4880 § 5.10
      • doc/DETAILS

Here are the patches without any new commands:

New commands can't be introduced.

New commands can't be introduced.

@werner Only patches 2 and 3 introduce new commands. What do you think about the other changes?

Fixed in master.

Something(tm) closes an arbitrary file descriptor behind our back. Not easy to track down because strace can not trace only threads - it always wants to trace all children as well - which is a bit too much and leads to other problems.

In case I not already mentioned it: There won't be any new commands to delete a key. Of course you are free to change GnuPG as you like but I won't apply them here.

The openssl version is a 64-bit counter (at least for ppc8), not 32-bit.

Log loops with:

I have a hang now when keylisting in Kleo with GPGME_DEBUG=9:

ECB is not bulk optimized in libgcrypt. I've send patches to add this in past but this was rejected on grounds that ECB is insecure and should not be used.

any feedback on this proposed patch?

wipe the stack

Benchmarks with the block ciphers is here https://dev.gnupg.org/D493

include missing file.

added CTR mode support

I did forget to mention that the key I'm using is 4096 bit long

I was creating a tar archive with 7-Zip on my Windows 10 machine. After the creating was completed I was encrypting the archive like so:

Just to clarify, you were able to decrypt and extract it without error? Which tool did you use to extract the tar archive?

The change in message class did not help.

The solution conflicts the the fix suggested and implemented for T4330.

Fixed similar to the suggestion but NaN and INF are detected earlier.