kewde
We know that thorough review does not happen instantly. I want to let you know that we have bounties and funds available for doing code review. https://shadowproject.io/en/bounties
* That's indeed true, we will be including the IV in the HMAC. Will be patched in our next version. Thank you!
* ChaPoly by TweetNaCl - dearly noted. The thing is, libs need compatibility with our curve. TweetNaCl only supports Ed25519 :/
* secp256k1 is correct.
* Do you have any references to the "exploding like a pipe bomb" problem? We're using the ECDSA from the bitcoins secp256k1 library - which is constant time and should be secure enough. Function: RecoverCompact()
We initially paid for a cryptographic review but the guy, whom we know by real name, disappeared from the planet. We're scouting for cryptographers willing to do code reviews, for a payment ofcourse.
If you're capable and interested then you should reach out to us on GitHub or Slack!
We do appreciate you doing this in your free time, so we're sending Bitcoin tips to whoever makes good suggestions. Please post your Bitcoin address if you'd like to receive some.
---
Most code is inherited from Bitcoin, custom code with cryptography: smessage.cpp, ringsig.cpp and stealth.cpp
I didn't mean to come off as rude, it's a bit late and I'm quick to the trigger sometimes.
What are your concerns with our scheme? Do you have any suggestions on improving it?
We really need to implement a key ratchet, that's a sure thing.
If you want users to take your comments seriously then you should be a bit more specific about what's scare. CBC and ECDH are the basis of most modern end-to-end encrypted messaging schemes.
I agree with the key exchange, it doesn't have a proper ratchet, it's on our to-do list.
That link to NodeJS was a good read, I'm fairly convinced that we should ditch RAND_bytes from OpenSSL for something more secure, we'll look into LibSodium.
I've caught rumours of a possible RAND_sys_bytes which operates over the systems CSPRNG? We like to be conservative on the libs.
We'd like to tip you for your efforts, do you have a Bitcoin (or ShadowCash) address?
Indeed HTTPS was not enabled on the page, it was still a work in progress. It is now enabled.
We're working on an installer that will mitigate MITM issues by having releases to be signed by multiple people.
1. We do respect scalability constrains, but we decided to monitor the network and scale when needed. The idea that we have to focus our limited development time and funds on issues that are not yet a problem is a bit goofy. The idea for scaling is to include a tree like structure: 1 / \ 2 3 You split the data into numbers, based on the capacity of your node. E.G. Alice has an address of stream 2. If Bob wants to send a message to Alice he encodes the stream number as metadata into the message and connects to a node of either 1 or 2. Nodes with the same number relay messages to eachother. When Bob can't find a node with number 2 he can just share it with a node of number 1. It will finds its way down (like a stream) to 2.
Yes we're always where the critics are, they are or best source of information.
I'm very happy to see our work being reviewed. I'm not an expert cryptographer but I am capable of understanding it. (fyi I didn't code it).
Our memcmp in constant time is not the prettiest, but it's short so we roll with it :P
This project started around 2014, LibSodium was still very small back then and OpenSSL, in ours view, remains the defacto standard. Is there any particular reason on why we should move away from RAND_bytes() ?
On the other hand I agree to switching over to a different mode to eliminate padding oracle attacks.
The IV are 16 random bytes generated by OpenSSL's RAND_bytes. https://github.com/shadowproject/shadow/blob/master/src/smes...