ios-application
ios-application copied to clipboard
Use AES-256 as encryption method for zip export
When exporting OTPs to a ZIP archive the file is encrypted with the encryption password. The encryption method used is ZipCrypto, which basically is broken. Would it be possible to switch to AES-256?
Hello @jknockaert,
This is not a bug, but a feature request. AES-encryption was used in the past for the ZIP-archive exports. However, I've reverted back to ZipCrypto as the ZIP library in use (ZipArchive) created AES-encrypted ZIP-archives that couldn't be decrypted using utilities such as 7-Zip whenever the password contained characters such as £.
See https://github.com/raivo-otp/ios-application/issues/59 for more information on the issue.
When I've identified why ZipArchive creates ZIP-archives that can't be extracted, I will implement AES-encryption again.
If you have any ideas on the topic, please let me know!
@tijme So that's how you fixed issue #59!
I brought up that problem originally, and have a suggestion for @jknockaert's feature request. Is it possible to change the onscreen keyboard which pops up in iOS when typing in the Raivo master password? If the keyboard could be slightly altered to simply omit the 4 non-ASCII problematic characters I identified in #59, then you could revert to AES-encryption safely.
If the keyboard can't be altered, a less elegant alternative would be for Raivo to reject any password containing these 4 characters with a suitable warning, asking the user to choose another password.
I would like to support all characters, so I'd prefer to keep debugging issue #59 and fixing the root cause. I'll keep you people posted 👌
I came to Raivo OTP for the secure export function, which apparently is currently not operational.
Would it be possible to add a warning about this so people don't assume the encrypted export is actually safely encrypted? Also, what about giving people an option like "More Compatible (less secure)" with an explanation that ZipCrypto doesn't provide effective protection and "More Secure AES-256" with an explanation about the 7-zip issue and certain characters in the master password and a strong recommendation that people test that they can decrypt and open the encrypted zip file?
Alright people, AES-encryption will be enabled again in version 1.4.6. Thanks to #160 I know a little bit more about the actual issue. I think it's due to the encoding of the password. Another character that doesn't work is ‘. Apparently creating ZIP archives using e.g. 7-ZIP won't even work when using these kinds of characters. It gives an error.
Decrypting the ZIP-archives with these characters on an Apple device works perfectly fine. With or without AES. Therefore I think the problem doesn't persé originates from the AES-encryption mechanism.
Thanks for fixing this. Has 1.4.6 been submitted to the app store?
Not yet, it is still in testing. There are other features released as well in 1.4.6. One of these is not working as expected.
Any chance this fix gets released soon?
Apple is still reviewing the build. It takes some time as this build also includes a donation button in the settings screen. Donations are in-app purchases which Apple needs to test. Somehow they're unable to find the donation button, as they're not signing in to the app....
I've explained to them where to find it and included a video of it. Replied to them today again and I hope it gets approved soon. Slowness of the release is also due to late responses to Apple from my side.