Modularize and add tests

[HACKERALERT]

Perhaps a big undertaking, but ideally we can take the main Picocrypt.go and modularize it so we can run tests on it. Open to ideas.

[njhuffman]

I think this is the first thing I'd like to try doing. Far from fully thought out ideas, but my first draft would be to make a couple of main interface methods: encrypt, decrypt, and comments.

It should be easy to set up a few test files from there to check the behavior of each interface against each encryption mode.

[HACKERALERT]

Yes, this would be a good idea. CLIv2 is already split out a little bit better than the GUI, but there is still much work that can be done. No rush or pressure to do anything btw, feel free to come and go.

[HACKERALERT]

Note: Picocrypt desktop will likely be audited soon. After the audit, code must not have major changes. So this project would be more oriented toward a common, reusable codebase that the CLI and Web and (future) mobile apps can share, not for the desktop app.

[njhuffman]

Will see how the audit goes. If we effectively freeze the desktop app, we could reframe this work as "picocrypt compatible" - it might be confusing to people if some of the tools are audited, and some are not?

[njhuffman]

Hm. I expect the answer to be "no", but if the modularization work for done by some reasonably close date, would it be worth doing to audit on that instead? Then we could say that the backend for all the tooling is audited, rather than just one of several tools. But I don't know if that's valuable to you, or what a timeline for auditing would look like.

[HACKERALERT]

The audit scope only includes the desktop app which is what most people use. The current CLI and Web aren't in scope, so we can change those however we want. Put good point, we may want to put a note in CLI and Web that they are not audited. Although if after the audit, no compatibility breaking changes are necessary, then the CLI and Web are arguably also secure, at least assuming the host machine is safe.

Maybe add a note to CLI and Web README like:

Although the Picocrypt volume format and desktop app have been audited, this (CLI/Web) hasn't been. Make sure to use it on a trusted host machine.

[HACKERALERT]

I think the GUI is the most complex and so it definitely needs the most focus. The CLI and Web are all fairly basic wrappers that basically copy code from the GUI, so as long as we get GUI and volume format audited, I think it's reasonable to say the CLI and Web is secure if they can create and decrypt volumes that the GUI can.

Also, and I might sound funny for this, but modularizing the code makes the codebase more complex and probably cost more to audit lol.

I would personally keep GUI as is, it's been like that for a long time and is very stable because of it. We'll give it the flagship treatment. Then we can work on a clean backend for CLI, web, mobile, and anything else.