Production readiness

[ahna92]

Hi

I had a small POC with it in android, iOS, web, looks great
Would love to use it in real application,

Actually I might use it or fork it then use it if this would give some real use case to the lib

Have couple of question

• Do you have a timeline when you planning to go to prod with the lib ? ,
• Are you currently using this lib in your own projects ?
• if you need help with any check list you planning to finish before finalising, please share ,
• In the docs you mention introducing new attack surfaces, can you please elaborate on this ? If it's just a wrapper how it can be abused ?

sorry i'm using issues to communicate 😬

[ionspin]

Hey @ahna92 no worries, I didn't realize I haven't enabled discussions on this repo, so your issue nudged me to do it. I'll convert this to discsussion and then answer your questions.

[ionspin]

So, to answer your questions:

Do you have a timeline when you planning to go to prod with the lib ?

Apart for missing documentation, the library is complete. I am periodically updating libsodium and maintaining any issues that show up. So in that sense this is production. The scary "Danger: Experimental" banner in the readme can go away once a proper review by an organization that does cryptography library reviews does it. I'm not actively working on making that happen at the moment, so the banner will be there indefinitely.

Are you currently using this lib in your own projects ?

Yes, although I have wrapped it in another library that makes the APIs more Kotlinesque and a bit safer to use (mostly by wrapping the byte arrays you get from libsodium into classes that try to prevent you from making developer mistakes, like serializing private key by accident or similar).
Also I am using it in context where even a failure of the library doesn't have serious consequences.
I haven't open-sourced this library yet, and no timeline when I will as I am quite low on free time.

if you need help with any check list you planning to finish before finalizing, please share ,

Thanks for offering to help, it's really appreciated, currently only the documentation (which is in the issues) is in to-do, and potentially finding an organization to review the code nothing else comes to mind

In the docs you mention introducing new attack surfaces, can you please elaborate on this ? If it's just a wrapper how it can be abused ?

It's just a broad speculation with intention to scare you additionally as the library is not yet reviewed :)
Although it's just speculation, there is room for mistakes and vulnerabilities, i.e. the way allocations are done that somehow introduce timing attacks, or something other.

To sum it all up:

• The library is mostly done (missing documentation), tested to confirm that results of calls are correct, and is actively maintained.
• There has not been a review by a third party, so you should look into the library code to make sure you are comfortable with using it.

[ahna92]

alright sounds great ! ,

one question regarding serializing private key by accident or similar , we can't serialise private keys and save it locally ? and if not how should we save them ?

[ionspin]

Ah, no that's not what I meant, I meant it prevents you from serializing private key accidentally and you meant to serialize the public key, or something similar.