0

I'm currently running my command as so:

/usr/local/Cellar/libressl/3.0.2/bin/openssl enc -aes-256-gcm -d -in enc.token -out dec.token -iv {IV} -K {KEY}

and the output of that command is bad decrypt. My output file also looks like it's only half decrypted, with the file looking like

Object(id=998fdsa981sdafkj@ÛP²•v’@v[ðt

  1. Is that fully decrypted? I believe those symbols represent binary, but it looks like only half of my object got decrypted
  2. I've been looking up bad decrypt and it seems like it has to do with the GCM encryption authentication tag not being supplied to decrypt. Is there a way to supply this to the Libre command? I've been looking through LibreSSL via https://www.libressl.org/ but there seems to be no documentation of any sort.
user3613290
  • 461
  • 6
  • 18

1 Answers1

0

I assume that LibreSSL is the same as OpenSSL in this regards. OpenSSL documents this issue on its man page for the enc utility:

https://www.openssl.org/docs/man1.1.1/man1/enc.html

The enc program does not support authenticated encryption modes like CCM and GCM, and will not support such modes in the future.

The same paragraph goes on to explain the reasoning behind this. It recommends to use the cms utility instead of enc.

Matt Caswell
  • 8,167
  • 25
  • 28
  • If LibreSSL didn't support GCM, why would it have ```aes-256-gcm``` as a command line option? – user3613290 Mar 12 '20 at 14:59
  • For the same reason that OpenSSL does. It supports GCM internally - just not in conjunction with the enc app. It uses generic handling for multiple commands to parse those options and will accept *any* cipher name. It just doesn't *work* with some of them. OpenSSL detects this and spits out an error - but older versions did not and failed in the same way as you are seeing. Caveat: I don't use Libressl, only OpenSSL. I just know that OpenSSL works this way. – Matt Caswell Mar 12 '20 at 15:44