Hopefully someone else on the list can speak to your further questions…. --Jeremy
On Tue, May 13, 2014 at 12:42 PM, Tom stone <stone...@gmail.com> wrote: > Jeremy, > > Thank you for your quick response. I am definitely interested in > additional details. If you know who I should contact that would be great. > Do you know whether this only effects simple file encryption or is it > general to the gcm mode, ie. would it effect tcp/ip traffic? > > Thanks > > > > On Tue, May 13, 2014 at 12:26 PM, Jeremy Gray <jrg...@gmail.com> wrote: > >> I had exactly this issue a few days ago. Turns out that there's a bug in >> setting up the GCM cipher, so the enc part is not working correctly for >> GCM. More than that, someone else will have to elaborate if you are >> interested. >> >> --Jeremy >> >> >> On Tue, May 13, 2014 at 12:06 PM, Tom stone <stone...@gmail.com> wrote: >> >>> Using openssl-1.0.1g command line for simple file >>> encryption/decryption, when I issue the commands >>> >>> openssl enc -aes-256-cbc -k secret -in file.txt -out file.ssl >>> openssl enc -d -aes-256-cbc -k secret -in file.ssl >>> >>> The contents of file.txt go to stdout as expected. However, when I issue >>> the commands >>> >>> openssl enc -aes-256-gcm -k secret -in file.txt -out file.ssl >>> openssl enc -d -aes-256-gcm -k secret -in file.ssl >>> >>> The contents of file.txt go to stdout but the string "bad decrypt" goes >>> to stderr. >>> >>> Am I missing something or is there a bug in the openssl gcm >>> implementation? >>> >>> I have tried substituting "-pass pass:secret" for "-k secret" and get >>> the same results. >>> >>> If I had to venture a guess, I would expect that the decrypt option >>> verifies that the input represents a full block of data and throws the >>> error when the gcm encrypted file does not end on a block boundary. >>> >>> >>> >> >
