Er... the cipher algorithm we chose does take an IV, so how could its size be 0?  I can't find anything relevant in http://lists.gnutls.org/pipermail/gnutls-devel/2015-April/007535.html.  Any chance of this being a gnutls bug??

Could you please comment out that line and see if it works correctly?

By "works correctly" I mean:  Start it with a large-ish scrollback (e.g. "./src/vte-2.91 -n 10000"), produce tons of output (e.g. "ls -lR /" for a few seconds, then interrupt with ^C) and scroll back all the way in the scrollback buffer.  The contents should appear correctly.  Thanks!

The text does appear correctly, but I don't thinks vte-2.91 has that much scrollback, as I reached the top rather quickly.

I repeated the test using termite, a vte-based terminal emulator, and was able to scroll back much further, and the text still looked fine.

I don't see how gnutls_cipher_get_iv_size [ https://gitlab.com/gnutls/gnutls/blob/master/lib/algorithms/ciphers.c#L284 ] can ever return 0 for a known algorithm (GNUTLS_CIPHER_AES_256_GCM).

(Also looking at our code, we should really check (assert) the successful result of gnutls_cipher_init().)

Thanks, it sounds good!

(The -n 10000 option specifies the number of scrollback lines, it's large enough for our purpose, or you could even specify -1 for infinite.  The scrollback is batched up in 64kB units and then encrypted (by gnutls).  If you produced more than 64kB of data (e.g. approx. 1000 lines of "ls -lR") and managed to scroll back and see it properly, it means that encryption/decryption is working.)

I haven't looked at gnutls's code yet, but...  for AES GCM, the IV size can be anywhere between 0 and 16 maybe (??), with 12 being the preferred for the best cryptographic result (using a shorter or longer one requires other precautions or provides weaker encryption).  At least if I understood it correctly :)  So the API that returns a single number is faulty by design to begin with.  Maybe the reason why it changed is somewhere along these lines.

        { .name = "AES-256-GCM",
          .id = GNUTLS_CIPHER_AES_256_GCM,
          .blocksize = 16,
          .keysize = 32,
          .type = CIPHER_AEAD,
          .implicit_iv = 4,
          .explicit_iv = 8,
          .cipher_iv = 12,
          .tagsize = 16},

and gnutls_cipher_get_iv_size returns cipher_iv. So this should return 12, as expected.

Still haven't look at the code (no time for this right now).  Could it be that gnutls (or its underlying nettle) was compiled without aes_256_gcm support, and hence the above code is ifdef'ed out?

No, get_iv_size has no such conditionals.

Oh, I just realized that I launched vte-2.91 with "-n 1000", not "-n 10000". That would certainly explain the lack of extra scrollback when I was testing yesterday.

Is this still happening? If so, please reopen.