Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Pre-shared key generation #10

Open
dimon222 opened this issue Jan 7, 2021 · 5 comments
Open

Pre-shared key generation #10

dimon222 opened this issue Jan 7, 2021 · 5 comments

Comments

@dimon222
Copy link
Collaborator

dimon222 commented Jan 7, 2021

Any chance pre-shared key generation can be added tor each pair of mesh nodes? (Further security improvement)
@k4yt3x
Copy link
Owner

k4yt3x commented Jan 11, 2021

It's technically possible. How much extra security would be gained from it though?

@dimon222
Copy link
Collaborator Author

dimon222 commented Jan 11, 2021 •
edited
Loading

I'm not sure, based on official docs it's used always, but defaulted to bunch of 0s when not configured by user. It could help to further restrict one-to-one relationship between nodes.

I ended up writing my own extension of existing database_manager.py with generation of preshared keys. I didn't choose the way to store these keys tho, but I can still make PR.

@k4yt3x
Copy link
Owner

k4yt3x commented Jan 12, 2021

Hmmm that sounds interesting. If you could please make a PR I'll take a closer look.

@dimon222 dimon222 mentioned this issue Jan 12, 2021
Closed
@dimon222
Copy link
Collaborator Author

Made PR with details. (ignore the part for client identifier from above post, I reread the source and its related to public keys, not to preshared keys)

@dimon222 dimon222 mentioned this issue Mar 5, 2021
Closed
@itoffshore
Copy link

It's technically possible. How much extra security would be gained from it though?

Post-Quantum Secrecy

WireGuard is not, by default, post-quantum secure. However, the pre-shared key parameter can be used to add a layer of post-quantum secrecy. It could be post-quantum secure were the public keys hashed instead of sent directly, but this is not part of the Noise Protocol Framework, on which WireGuard's handshake is based, and this hashing technique wouldn't enable forward-secure post-quantum secrecy either. The best bet for post-quantum security is to run a truly post-quantum handshake on top of WireGuard, and then insert that key into WireGuard's pre-shared key slot.

itoffshore added a commit to itoffshore/wg-meshconf that referenced this issue Jul 2, 2023
@itoffshore
add pre-shared key generation
aaf8e2a 
This change does not add the pre-shared keys to the database but from
a security perspective this should not be done anyway.

If private keys exist the configuration is not overwritten so re-running
`genconfig` does not overwrite existing configuration.

TODO: add an option to generate new configuration (keys should be regularly
      rotated)

---

* pre-shared keys are recommended to help towards quantum resistance

  - https://www.wireguard.com/known-limitations/#post-quantum-secrecy

* this commit is based on:

  - k4yt3x#10

  (with the missing json import added)
@itoffshore itoffshore mentioned this issue Jul 2, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[WIP] Generate preshared pairs on export dimon222/wg-meshconf
3 participants
@itoffshore @dimon222 @k4yt3x