Invalid iv in the message

srubben

Hi,

All requests using the CLI for items and documents return the following message:

$ op list items
[LOG] 2018/09/12 08:13:38 (ERROR) Invalid iv in the message: 16

The same error when getting info on items and documents.

Getting the list of vaults or groups for instance works correctly.

The other 1Password tools work correctly without problems (v7.1.1, and latest 1password X). Only the CLI gives this problem.

---

1Password Version: 0.5.3
Extension Version: Not Provided
OS Version: OS X 10.13.6
Sync Type: 1Password Families
Referrer: forum-search:Invalid iv in the message

jpgoldberg

The CLI is clearly being stricter in some checks than other clients, and is expecting a nonce (logged as "iv" for "initialization vector") of exactly 12 bytes (which is the recommended standard for AES-GCM, while for the vault in question you have a 16 byte nonce

if len(iv) != symmetricKeyGCMNonceSize {
    return nil, fmt.Errorf("Invalid iv in the message: %d", len(iv))
}

I'm wondering which of our clients created a key encrypted using a 16 byte nonce. Do you recall how and when this particular vault was created?

I will do some research to see if we can safely modify this test to to check that the IV is at least 12 bytes instead of requiring that it is exactly 12 bytes.

As a work around for you until we get this sorted you, you may need to copy the data from that vault (using a 1Password client that works for this vault) into a new vault. That should work (unless your client is creating the new vault with a key with another 16 byte nonce.)

Update: If you try that work-around, please just copy items from the troublesome vault and leave the problem in place. We are looking at getting you a version of the CLI that will log some identifiers of the problematic item so that we can try to find how it was created.

jpgoldberg

I will do some research to see if we can safely modify this test to to check that the IV is at least 12 bytes instead of requiring that it is exactly 12 bytes.

It turns out that the answer is "no". There is a weakness in how nonces that aren't exactly 12 bytes long are processed in GCM. So we need to track down what client created those.

cohix

@srubben I'm shortly going to send you a direct message on this forum with a link to a build of op that will collect some information about this issue so we can track down which client created the bad item(s) please keep a lookout for that, I'll include instructions in the message.

srubben

It was definitely created with a v6 client (Mac) a few years ago, but I can't remember which version exactly. I did an import from a keepass, but I can't remember the exact steps I took I'm afraid.

rickfillion

Hi @srubben,

We've been looking into this problem for the past few days and we believe that we've identified what happened here.

The item in question was originally created in 1Password for Mac and that version of the item seems to be fine. But it was subsequently edited in 1Password for Android, and it's this version of the item that seems "off". The good news is that the bug that caused this in 1Password for Android has already been fixed. If you're super curious about the exact technical issue at play I can elaborate, but it's probably not as interesting to you as actually getting things working again.

If you re-save the item with a trivial edit like say its title with either 1Password for Mac or 1Password for Android, this should re-encrypt the item with an IV value that's of the correct/expected length. Once that's done it should be usable in the command-line tool.

I hope this helps.

Rick

srubben

Brilliant! I had to fix a few items before it started working, which I found using the build you provided. Good thing you can search for the UUID's in the Mac app.

Thanks for the help!

AGAlumB

Awesome! Thanks for the update. On behalf of Rick and cohix, you are most welcome! I'm sorry you encountered that issue, but glad to hear that editing did the trick for you. It sounds like you should be all set, but we're here if you need us. :chuffed:

akraut

I'm running into this issue as well. How do I identify the offending items?

jpgoldberg

Hi @akraut. Someone should be in touch with you soon (or perhaps already has been) to get you a build of the CLI that does additional logging which will help identify the incorrect items.

tsenart

This is happening to me as well.

[LOG] 2018/11/08 14:59:47 (ERROR) Invalid iv in the message: 22

cohix

@tsenart I'll send you a direct message with instructions to fix your items.