Storing fields as encrypted data works locally, fails on server

Questions / Help
,
1

Probably I am missing something obvious - so I would be grateful for some help with the folowing problem:

In a PostgreSQL database using Ecto, I am storing the contents of some fileds as encrypted data using cloak_ecto and defining the respective fields in the schema like so:

  field(:super_secret_data, DataStore.Encrypted.Binary)

The cipher algorithim is set like this:

 ciphers: [
    default:
      {Cloak.Ciphers.AES.GCM,
       tag: "AES.GCM.V1", key: Base.decode64!("dfgdfg 46 bytes of secret key fdshdskjfhd")}

Everything works fine and as expected on my local development machine (Win10/wls).

Once I run the same program on a Debian 9 server, I get the following error:

15:00:12.259 [error] GenStateMachine :"XYZ.Server" terminating
** (ArgumentError) argument error
    (crypto) :crypto.aead_encrypt(:aes_gcm, <<85, 167, 118, 80, 73, 58, 181, 54, 93, 106, 63, 155, 177, 110, 168, 25, 139, 17, 102, 80, 8, 78, 56, 54, 86, 141, 254, 230, 84, 71, 52, 115, 211>>, <<85, 24, 172, 236, 98, 42, 153, 227, 92, 182, 95, 114, 68, 254, 219, 179>>, "AES256GCM", ""
, 16)
    (cloak) lib/cloak/ciphers/aes_gcm.ex:44: Cloak.Ciphers.AES.GCM.encrypt/2
    (data_store) lib/cloak_ecto/type.ex:33: DataStore.Encrypted.Binary.dump/1
    (ecto) lib/ecto/type.ex:817: Ecto.Type.process_dumpers/3
    (ecto) lib/ecto/repo/schema.ex:925: Ecto.Repo.Schema.dump_field!/6
    (ecto) lib/ecto/repo/schema.ex:938: anonymous fn/6 in Ecto.Repo.Schema.dump_fields!/5
    (stdlib) maps.erl:257: :maps.fold_1/3
    (ecto) lib/ecto/repo/schema.ex:936: Ecto.Repo.Schema.dump_fields!/5
    (ecto) lib/ecto/repo/schema.ex:869: Ecto.Repo.Schema.dump_changes!/6
    (ecto) lib/ecto/repo/schema.ex:255: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
    (data_store) lib/data_store/data_store.ex:330: DataStore.create_credential/2

What puzzles me most: If I run a simple test of the function DataStore.create_credential on this very same server, it works as expected without causing an error. If this wasn’t the case, I would have suspected some version differences in os crypto libs or something similar.

Any pointers for finding the cause of this behaviour are much appreciated.

1 Like
2

Problem solved: The key, which was set for the cipher algorithm, was the only relevant difference between my local setup and the server. - And for whatever reason, it contained illegal characters which led to the crash.

1 Like