Questions / Why should you use rosenpass? about rosenpass HOT 12 CLOSED

Is there some sort of forum or space where people can exchange ideas and ask questions about the Rosenpass?

There is an invite-only Matrix for the Rosenpass team. I would support a public channel, be it on Matrix or IRC, though. (@koraa)

Rosenpass PSK vs. WireGuard PSK

Rosenpass is realized through the WireGuard PSK feature. Have a look the this. The two-minute-rule was taken from WireGuard, as they do the same. In general, it is considered good practice to rotate keys frequently, as in the case that an eavesdropper obtains a single key, they can only decrypt the traffic sent between this time window, which in our case is two minutes.

Do the asymmetric keys that Rosenpass uses have the same format as the asymmetric keys of WireGuard?

No! And this is the reason why Rosenpass is so amazing. Not all asymmetric keys are equal, there are many different algorithms. The most common ones are RSA and ECC, the latter one being used by WireGuard. Both of these can be broken by the Shor algorithm, an algorithm that requires a quantum-computer with a sufficient amount of qbits. Rosenpass on the other hand uses an algorithm immune to the Shor algorithm, known as Classic McEliece. Through this, your traffic remains secure, even if quantum computers would exist.

Why GitHub? What about IPv6-only nodes?

+1 on IPv6 support, although I would personally enjoy having signed merge commits then, if we decide to mirror.

/cc @koraa

from rosenpass.

Questions outside of issues and direct emails Is there some sort of forum or space where people can exchange ideas and ask questions about the Rosenpass? (Mailling List, Forum, IRC, Matrix, XMPP).

There is an invite-only Matrix for the Rosenpass team. I would support a public channel, be it on Matrix or IRC, though. (@koraa)

That is a wonderful idea. I think a subreddit and an irc/matrix channel would be great! Would you like to start one? I can send you our nicks so we can help you moderate!

Rosenpass PSK vs. WireGuard PSK As far as I know WireGuard, WireGuard already has a PSK feature. Why should one use Rosenpass? As far as I understand, the only advantage would be that Rosenpass renews the PSK every two minutes. Is that correct? As a cryptograhie dummy: Does this bring anything?

Rosenpass is realized through the WireGuard PSK feature. Have a look the this. The two-minute-rule was taken from WireGuard, as they do the same. In general, it is considered good practice to rotate keys frequently, as in the case that an eavesdropper obtains a single key, they can only decrypt the traffic sent between this time window, which in our case is two minutes.

Emil is correct! If your PSK is secure, wireguard is secure. The trouble is that you have to transmit the PSK over network at some point and that network connection usually isn't secure against quantum computers, which is why rosenpass does a key exchange that creates a PSK…

You could build the entire internet to rely on just symmetric keys, but then you would have to keep transmitting secret keys over the internet…if any of those connections is insecure the key would be leaked.

With public key cryptography, you can just transmit the public key over a public channel and it does not matter if that channel is private.

3. How does it works? How does Rosenpass negotiate the PSK? As I understand it, Rosenpass also uses asymmetric keys like WireGuard, right? And then negotiates this accordingly securely using a separate UDP port? Do the asymmetric keys that Rosenpass uses have the same format as the asymmetric keys of WireGuard?

@emilengler 's answer is excellent. Thank you!

wg-quick and Post Statments Is it possible to integrate Rosenpass with wg-quick? Is it possible to create configuration files (like for wg-quick) for Rosenpass in which you can also enter PostUp and PostDown statements?

It could be done; Rosenpass is right now very separate from WireGuard on an organizational level. Personally I think integrating the two should definetly be done. You could write an email to the WireGuard mailing list suggesting the integration.

Why GitHub? What about IPv6-only nodes? Rosenpass is FLOSS. Is there a specific reason why GitHub, which is proprietary, is used then? Some FLOSS projects host Git instances themselves or use free ones like codeberg.org. I had several times in the past on IPv6-only nodes the problem to install Rust packages since Rust fetched the packages from GitHub. Does this problem exist with Rosenpass as well? Building rosenpass locally on an IPv6-only node is also impossible, as the source code would have to be downloaded from GitHub. If not switching from GitHub, is the plan to do a mirror on an IPv6 Git instance?

Good point. We should provide a mirror.

from rosenpass.

Rosenpass on the other hand uses an algorithm immune to the Shor algorithm, known as Classic McEliece. Through this, your traffic remains secure, even if quantum computers would exist.

Perhaps a silly question: Why doesn't WireGuard itself use Classic McEliece then? Would that be too computationally intensive?

Rosenpass uses Classic McEliece keys (for authentication) and Kyber keys to protect past communication even if the Classic McEliece keys had been leaked. At the time WireGuard was written it used bleeding edge crypto; Classic McEliece and Kyber didn't exist in their current form.

Even today, there are good reasons not to integrate RP directly into the Operating system (WireGuard is part of linux). WireGuard uses x25519 both for authentication and for protecting past sessions if keys are leaked. Lets compare the two:

x25519
  ciphertext: 32 byte
  public key: 32 byte

Kyber:
  ciphertext: ~1kb
  public key: ~1kb

Classic McEliece:
  ciphertext: 100 byte
  public key: 100kb

So yes, using Rosenpass creates quite a bit of overhead.

from rosenpass.

@marek22k Yes; the places where unsafe {} is used are precisely those places where a buffer overflow or use-after-free vulnerability could still arise.

But look at how many lines are not written inside unsafe blocks. These are safe from those sorts of errors.

There is no absolute security; using formal methods in the context of software engineering reduces risk, but never to zero. Even in a mathematically perfect, formally verified system there is still the potential hardware bugs (can't get around physics) and human error in specifying what the system would do.

With this in mind, formal methods applied to real-world problems is about the process of reducing risk in the software we use. Having no unsafe blocks at all would certainly reduce risk so getting rid of those would be an improvement we should implement at some point.

But the risk from those blocks is limited: Having a few unsafe blocks allows us to focus on those sections with our code reviews in particular which is why there are diminishing returns.

The need to get rid of unsafe blocks has to be weighed against other goals such as performance and getting rid of root permissions for rosenpass.

from rosenpass.

Rosenpass on the other hand uses an algorithm immune to the Shor algorithm, known as Classic McEliece. Through this, your traffic remains secure, even if quantum computers would exist.

Perhaps a silly question: Why doesn't WireGuard itself use Classic McEliece then? Would that be too computationally intensive?

from rosenpass.

@marek22k Passwort: Zürcherinnen Sarajevo Wedel Spezialausgabe zusammenpassendem

from rosenpass.

Hello, now that I have tried Rosenpass myself, several questions arise:

• Currently, the Rosenpass keys are stored in a file. Is it also possible to specify them in a base64 string or would they become too long?
• Why is the public key specified in addition to the private key - both in configuration files and in the rosenpass exchange command? Does it take too much time to calculate the public key from the private key each time?
• Why is the key stored in a file with the prefix pq. rp for rosenpass would make more sense, wouldn't it?

rosenpass man does not work for me. How can I display the man pages:

$ rosenpass man
man: can't set the locale; make sure $LC_* and $LANG are correct
No manual entry for rosenpass in section 1

I have encountered the following error: #106

from rosenpass.

@emilengler Do you feel like taking this?

from rosenpass.

@emilengler Do you feel like taking this?

Sure.

from rosenpass.

Currently, the Rosenpass keys are stored in a file. Is it also possible to specify them in a base64 string or would they become too long?

base64 I have just tried myself... (reminder for myself: compressing random data is dump)

method: length
Base64(key): 18092
Base64(Zlib(key, best)): 17516
Base64(Gzip(key, best)): 17532
BaseZ85(key): 16936

from rosenpass.

Another question:
The readme says the Rosenpass application is written in the Rust programming language which is much less prone to such issues. However, the unsafe keyword is used several times. Doesn't this override the security measures of Rust?

$ grep -r unsafe *
src/cli.rs:                unsafe {
src/cli.rs:    unsafe fn store_secret<P: AsRef<Path>>(&self, path: P) -> anyhow::Result<()>;
src/cli.rs:    unsafe fn store_secret<P: AsRef<Path>>(&self, path: P) -> anyhow::Result<()> {
src/coloring.rs:        unsafe {
src/coloring.rs:    unsafe fn release_by_ref<const N: usize>(&mut self, s: &mut Secret<N>) {
src/coloring.rs:    /// This function contains an unsafe call to [libsodium::sodium_malloc].
src/coloring.rs:            let ptr = unsafe { libsodium::sodium_malloc(N) };
src/coloring.rs:            unsafe {
src/coloring.rs:unsafe impl Send for SecretMemoryPool {}
src/coloring.rs:        unsafe { SECRET_CACHE.lock().unwrap().release_by_ref(self) };
src/coloring.rs:        let slice = unsafe { std::slice::from_raw_parts(ptr, N) };
src/coloring.rs:        let slice = unsafe { std::slice::from_raw_parts_mut(ptr, N) };
src/coloring.rs:        unsafe { libsodium_sys::sodium_init() };
src/coloring.rs:        let ptr = unsafe { libsodium_sys::sodium_malloc(N) };
src/coloring.rs:        let mem = unsafe { std::slice::from_raw_parts(ptr as *mut u8, N) };
src/coloring.rs:        let ptr = unsafe { libsodium_sys::sodium_malloc(N) };
src/coloring.rs:        unsafe { libsodium_sys::sodium_free(ptr) }
src/pqkem.rs:/// This Trait impl calls unsafe [oqs_sys] functions, that write to byte
src/pqkem.rs:/// the unsafe calls, and an early return with an Err occurs if the byte slice
src/pqkem.rs:        unsafe {
src/pqkem.rs:        unsafe {
src/pqkem.rs:        unsafe {
src/pqkem.rs:/// This Trait impl calls unsafe [oqs_sys] functions, that write to byte
src/pqkem.rs:/// the unsafe calls, and an early return with an Err occurs if the byte slice
src/pqkem.rs:        unsafe {
src/pqkem.rs:        unsafe {
src/pqkem.rs:        unsafe {
src/sodium.rs:        ensure!(unsafe{libsodium::$name($($args),*)} > -1,
src/sodium.rs:        && unsafe {
src/sodium.rs:    unsafe { libsodium::sodium_compare(a.as_ptr(), b.as_ptr(), a.len()) }
src/sodium.rs:    unsafe {
src/sodium.rs:    unsafe { libsodium::randombytes_buf(buf.as_mut_ptr() as *mut c_void, buf.len()) };
src/sodium.rs:    unsafe { libsodium::sodium_memzero(buf.as_mut_ptr() as *mut c_void, buf.len()) };
src/util.rs:    unsafe fn store_secret<P: AsRef<Path>>(&self, path: P) -> Result<()>;
src/util.rs:    unsafe fn store_secret<P: AsRef<Path>>(&self, path: P) -> Result<()> {
src/util.rs:    unsafe fn store_secret<P: AsRef<Path>>(&self, path: P) -> Result<()> {

from rosenpass.

@marek22k I hope you got satisfying answers to your questions. I'm closing this issue now. Please feel free to reopen and comment if I overlooked something or if there is more that you want to know 🙂 .

from rosenpass.