> - symmetrical crypto with shared key across all clients, letting any VPN client act as any other client
That problem should be solved by signatures or at least a chain of one to one key exchanges. But having a shared key sounds bad.
> - no PFS (straight AEAD with AES-GCM)
What does the cipher and AEAD have to do with PFS,I thought that was a key-reuse problem?
> - alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
Yup,home grown sounds kinda bad but I don't see the peoblem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
Same as before.
> - static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
Sounds like a feature request. PR?
> - no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
Again, a PR would be nice,any project adds features as they grow.
You have good critique but I don't think any of this means the project or quality is utterly bad. Issues and PRs will help them a lot I am sure but your first point about shared keys does bother me a lot.
> > - alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
> Yup,home grown sounds kinda bad but I don't see the problem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> > - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
> Same as before.
For both of these, my general thought is that they're massive crypto code smells - implementing things yourself when a vetted library exists is just not something you do for secure code. If we can see these crypto issues already, there's going to be more. Maybe it'll be implementation bugs, maybe conceptual architecture issues - but I'd bet on this not being a complete list. So even if these bugs aren't exploitable they're indicative of something deeper.
They're not saying AEAD has anything to do with PFS. They're saying that the only encryption they have is (at best) the AEAD, without a kex.
The sketchy, home-grown AES-CBC isn't "kind of bad". It's unauthenticated CBC. That's completely broken.
You don't PR a VPN from cryptographically secure to cryptographically sound. The cryptography is most of the point; if it isn't there, it's not going to get there by committee.
I did not suggest a PR for security related issues but for lacking featues, which is perfectly normal.
I understand that you know crypto extremely well but how can you say "It's unauthenticated CBC. That's completely broken." ? Using CBC without authentication is certainly broken but that only means you have to use a MAC with CBC. A MAC is NOT part of CBC and lack of MAC usage is a criticism that has nothing to do with their CBC implementation.
> They're not saying AEAD has anything to do with PFS. They're saying that the only encryption they have is (at best) the AEAD, without a kex.
If that'a what they meant then it makes sense. I read it as if AEAD was thought of by them as an alternate to PFS.
I don't like that mindset. Usually an open source contributor/creator shares a project, calls out how awesome it is. A bunch of people prove that it isn't, then the creator's response is "well, help me".
I am not the creator. But lacking features does not make it less awesome so long as the main purpose of the project is in a usable and stable state. Lacking features means OP did not need them so they did not implement it. You share it and if people like it and ask for features or do a PR you add it. What is wrong with that?
That problem should be solved by signatures or at least a chain of one to one key exchanges. But having a shared key sounds bad.
> - no PFS (straight AEAD with AES-GCM)
What does the cipher and AEAD have to do with PFS,I thought that was a key-reuse problem?
> - alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
Yup,home grown sounds kinda bad but I don't see the peoblem if they just replicated the process with their own code without modifying how it works and avoid IV reuse.
> - home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
Same as before.
> - static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
Sounds like a feature request. PR?
> - no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
Again, a PR would be nice,any project adds features as they grow.
You have good critique but I don't think any of this means the project or quality is utterly bad. Issues and PRs will help them a lot I am sure but your first point about shared keys does bother me a lot.