Handle ambiguous and nested encrypted QR codes, and hide legacy AES v1 modes

[earthdiver]

Description

• Added support for nested encrypted QR codes
  (currently limited to static QR codes)

• Added support for ambiguous QR codes. You can now choose in Settings how to handle QR codes that could be interpreted as either CompactSeedQR or EncryptedQR (or xprv).

• Handle decrypted text from encrypted QR codes (as an alternative to PR Handle text payloads in encrypted QR decoding #175)

• Hid legacy AES v1 modes from the encryption mode selector

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Documentation
• Other

Checklist

• I’ve run pytest and made sure all unit tests pass before sumbitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

• No, I’m a fool
• Yes (auto generated by gpt codex)
• N/A

I have tested this PR on the following platforms/os:

• Raspberry Pi OS Manual Build
• SeedSigner OS on a Pi0/Pi0W board
• Other

[earthdiver]

Notes

• Encrypted QR does not support high-capacity QR formats such as BBQR, but in most cases it should be sufficient. (I have not figured out how to support reading both static and animated QR codes in SS.)

• For ambiguous QR codes, CompactSeedQR is prioritized by default. This is to preserve compatibility with previous behavior and to account for the possibility that someone may create an encrypted QR code resembling CompactSeedQR for plausible deniability.

• If the decrypted data does not match CompactSeedQR, xprv, or EncryptedQR, but is valid UTF-8 text, that text will be displayed. However, there are font limitations.

At present, all of these new features are meaningful only when used in combination with Krux’s Datum tool.

[3rdIteration]

@codex can you include this document https://github.com/3rdIteration/seedsigner/blob/763cf91a38c2b3fdc56e65c917d5eb47deac1023/demo_qr_codes/README.md in a comment

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[3rdIteration]

QR codes to demonstrate this are here: https://github.com/3rdIteration/seedsigner/blob/763cf91a38c2b3fdc56e65c917d5eb47deac1023/demo_qr_codes/README.md

[3rdIteration]

(I'll review and merge tomorrow)

[3rdIteration]

@earthdiver Hey so I'm looking at this and given that it can result in different seeds, should probably just default to prompt if encrypted QR is enabled (which it is by default) as opposed to how it is currently where it defaults to treat as compact seed QR,

[earthdiver]

Got it. I don’t have any particular preference.

[earthdiver]

Thank you for merging this PR.

By the way, in terms of differences from Krux behavior, the ShSi version differs not only in supporting static QR codes only, but also in supporting only Base43 for text-encoded encrypted data. Krux can automatically detect and decode encrypted data encoded as Base64, Base32, or hex as well, whereas the ShSi version supports only Base43. I do not think this is a major issue, but do you think it would be better to align it with Krux?

(On the other hand, Krux cannot decode encrypted QR data when the encrypted payload contains nested Base43-encoded encrypted data, whereas the ShSi version can.)

[3rdIteration]

No worries, I the key thing is that it works for the default encrypted seed workflow, which it currently does. That said, supporting all the other stuff would be nice to have as well if you are feeling so inclined to code it :)

[earthdiver]

Got it. I’ll implement it when I feel like it.