Use AES-CTR + ARGON2 + HMAC instead of AES-GCM

[brusherru]

It keep support of importing Smapp's wallet format and AES-GCM encrypted wallet file, but it will re-encrypt it using Argon2.

Since Argon2 with the selected params requires more computation and takes more time to decrypt/encrypt I've added "waiting" states to the buttons, which works with secret data, such as button in password modal, buttons on unlock and import screens.

P.S. This implementation uses the same Argon2 params for storing wallet inside local storage (App's persistent memory) and for the exported wallet file. But mb we'd better have two different params for them to have fast speed in App and safest wallet file on FS?

[github-actions[bot]]

You can preview the changes at : https://04758797.smapp-lite-prod.pages.dev

[brusherru]

I've also tested it on iPhone 15 Pro, works well and has approximately the same encrypt/decrypt time :)

[brusherru]

If I save this file and try to load on prod it says "wrong password" - error message is there, but not correct.

Yeah, that's correct because this changes introduces new encryption method. The old one does not support it. If we will need to export using old encryption method — it is still possible and easy to do. However, Smapp-lite uses a newer wallet format, which is not support in Smapp and Smcli. So I don't think we need it :)

I didn't try to brute force the file. Probably we can ask Halborn to validate.

Everything might be brute-forced, it's the only matter of resources. Now it takes about 700 ms to decrypt the wallet on my MacBook Pro. While previously it takes about 37 ms. So now brute-force are expected to take about 20 times more time/resources than before.

But of course we should point Halborn on this PR and ask is it enough to remove this "minus" point from their audit :D

We may tweak encryption params to require more/less resources, but we have to find a golden middle between speed (usability) and security. However, there is a way to improve the situation and move away from compromises a little:

• store in local storage / file system the file with more complex encryption params (to make it takes up to 10-30 seconds per decryption),
• after success unlocking wallet file keep it in the App memory (not a persistent one) encrypted with lower params, then it will make it possible to have encrypted secrets in memory, BUT have a quick access to it
• The cons here, that we will still need to encrypt secrets with strong params from time to time (e.g. on locking the wallet, before window close, etc), which will take 10-30 seconds. And we need to ensure that User won't close the window with unsaved changes... while currently, it is saved automatically every time. Anyway, it seems like a seprate pretty big feature, so even if we want it — let's implement it within another PR.

P.S. If you're deriving a new key pair / creating account, this changes makes it to take about 1.5 second on my machine, because it decrypts secrets first, and then encrypts...