noise VS mullvadvpn-app

This is Noise IK (possibly with minor differences in the hashing):

https://noiseprotocol.org/

Wireguard uses NoiseIK, plus a static public key for the initiator which is encrypted to the agreed-upon-session-key without adding additional round trips. Your protocol simply omits the parts related to the initiator's static public key, because it has none.

With regard to this:

> - On the wire/protocol stuff. We're doing pretty rudimentary "open new connection, stream voice, POST somewhere". This adds extra latency and CPU usage because of repeated TLS handshakes, etc. We have plans to use Websockets and what-not to cut down on this.

I've recently used the Noise protocol[1] to do some encrypted communication between two services I control but separated by the internet.

It was surprisingly easy!

[1]: https://noiseprotocol.org/

Rolling your own initial handshake is hard. Right now I strongly encourage you take a look at the Noise protocol framework. Specifically the XK and IK patterns for identified clients, and the NK pattern for anonymous clients. The best security will be achieved by the XK pattern, but if you need to reduce the number of messages to a minimum IK might be a bit more attractive. (Also, if I recall correctly IK is used by Wireguard, so there's an example to follow).

Rosenpass author here;

There is a confusion about terminology here I think. Mathematical proofs including cryptography proofs use models simplifying reality; i.e. the real practical system might still be susceptible to attacks despite a proof of security.

For crypto primitives (classic mc eliece, curve25519, ed25519, RSA, etc etc) the standard for proofs is currently showing that they are as hard as some well studied mathematical problem. This is done by showing that an attack on the primitive leads to an attack on the underlying mathematical primitive. The proof for Diffie-Hellman shows that attacking DH leads to an efficient solution for the discrete log problem. I.e. the proof is a reduction to the underlying primitive.

No primitive is perfectly secure (at least a brute force – i.e. guessing each possibility is possible); there is some probability that the adversary can guess the right key. We call this probability the adversary's advantage. One task in cryptoanalysis is to find better attacks against primitives with a higher advantage; if an attack with a polynomial time average runtime is found, the primitive is broken. Finding a higher non-polynomial attack is still an interesting result.

The standard for protocols is proving that the protocol is secure assuming the primitives are secure; since multiple primitives are used you basically get a formula deriving an advantage for breaking the entire protocol. The proof is a reduction to a set of primitives.

We did not build a proof in that gold standard, although we are working on it. We built a proof in the symbolic model – known as a symbolic analysis. This uses the perfect cryptography assumption; i.e. we assumed that the advantages for each primitive are zero. Google "Dolev-Yao-Model".

This makes the proof much easier; a proof assistant such as ProVerif can basically find a proof automatically using logic programming methods (horn clauses).

The definitions of security are fairly well understood; unfortunately there is a lot to go into so I can't expand on that here. Looking up "IND-CPA" and "IND-CCA" might be a good start; these are the security games/models of security for asymmetric encryption; you could move on to the models for key exchange algorithms there. Reading the [noise protocol spec](https://noiseprotocol.org/) is also a good start.

There is no description of the protocol or of its security goals, so I am making some guesses based on a cursory look at the source and what I imagine this might be for.

A single symmetric key is derived for both directions, and there is no checking of nonces, so as far as I can tell any message can be dropped, reordered, or replayed in both directions. (Including replaying message from A to B as if they were from B to A.)

This is a bit like using ECB and likely to lead to fun application-specific attacks like [0].

This is very much rolling your own crypto, in a dangerous way. I am on the record as being "against" the "don't roll your own crypto" refrain [1], but mostly because it doesn't work: it should discourage people from publishing hand-rolled protocols such as this, but instead people think it means "don't roll your own primitives" and accept the use of "Ed25519/X25519" as probably secure.

Please read about the Noise framework [2] to get an idea of how much nuance there is to this, and consider using a Go implementation of it [3] instead.

P.S. This kind of issue is also why I maintain that NaCl is not a high-level scheme [4]: this could have used NaCl and have the exact same issues. libsodium has a couple slightly higher-level APIs that could have helped, secretstream [5] and kx [6], but again please use Noise.

[0] https://cryptopals.com/sets/2/challenges/13

[1] https://securitycryptographywhatever.buzzsprout.com/1822302/...

[2] https://noiseprotocol.org/noise.html

[3] https://github.com/flynn/noise

[4] https://words.filippo.io/dispatches/nacl-api/

[5] https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...

[6] https://libsodium.gitbook.io/doc/key_exchange

* Mozilla VPN: wrapper around https://mullvad.net/ (and had security issues: https://www.techradar.com/news/security-audit-finds-major-is...)

hey there, after doing some research it seems like the conclusion is your vpn. Nord VPN has a lack of port forwarding, while other vpns have port forwarding (proton, mullvad). that is most likely interrupting your speed. also, apparently nord does keep some sort of logs if your interested in that. i would recommend cancelling nord and getting something else like proton or mullvad (i would recommend proton more) if you really want to download movies/shows. another option for you (if you dont want to switch) is to find your movie on websites that don't require a vpn (aka not torrenting) but you can if you want to. you can use this for that, they have tons of movies and shows. or just use a streaming site off of the megathread.

The 500 MiB thing is because the frontend is an Electron app. That's sadly how it is with Electron. The UI can of course be re-written into a language/framework that produces way smaller programs, but it's not currently really worth the tradeoff. Most people are not that constrained in disk or internet speeds. https://github.com/mullvad/mullvadvpn-app/issues/1572

The downloads folder access thing is because Apple made it so. If you run an installer from the downloads folder it will need access to the downloads folder. This has nothing to do with Mullvad, but is a permission check macOS puts on all software. The Mullvad VPN app has no code for doing anything in the Downloads folder specifically.

Requiring an account for search is a deal breaker. They say they need it for payment, but mullvad[0] does just fine without an account as well.

[0]: https://mullvad.net/

From this post: https://github.com/mullvad/mullvadvpn-app/issues/1570

I don't understand why the .rpm package of Mullvad VPN still only officially supports Fedora. This issue on GitHub has been open for almost three years now and there is even someone else trying to help you making the necessary changes to support openSUSE in this PR. I kinda agree with cornfeedhobo's sentiment that the necessary changes to make it work on openSUSE are being gated. I'm a paying user for quite some years already and made the switch to openSUSE and I'd really like to continue using Mullvad VPN there without having to force install the .rpm package and thus living with a lot of uncertainty about how well it will run.

It's just a false-positive. If you're still wary, feel free to review the source code of the app and you can even build it yourself: https://github.com/mullvad/mullvadvpn-app/