starred/Quasar

Fork 0

mirror of https://github.com/quasar/Quasar.git synced 2026-04-25 15:25:59 +03:00

[GH-ISSUE #466] Enhance cryptography #243

New issue

Open

opened 2026-02-27 15:49:32 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 15:49:32 +03:00

Owner

Originally created by @MaxXor on GitHub (Jun 18, 2016).
Original GitHub issue: https://github.com/quasar/Quasar/issues/466

Cryptography Todo (see discussion here: #450):

Increase PBKDF2 iterations
Add packet counter (fix replay-attack)
Store derived keys in client instead of real password
Change AES-128 to AES-256
Use random generated salt on first Quasar Server startup and store in safe place

Originally created by @MaxXor on GitHub (Jun 18, 2016). Original GitHub issue: https://github.com/quasar/Quasar/issues/466 Cryptography Todo (see discussion here: #450): - [x] Increase PBKDF2 iterations - [ ] Add packet counter (fix replay-attack) - [x] Store derived keys in client instead of real password - [ ] Change AES-128 to AES-256 - [ ] Use random generated salt on first Quasar Server startup and store in safe place

kerem added the

enhancement

label

2026-02-27 15:49:32 +03:00

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@TheNain38 commented on GitHub (Jun 18, 2016):

You could use task lists to keep track of what's done, and what's not.
Also, the 3rd one should be: "Store derived keys in client instead of password"

@TheNain38 commented on GitHub (Jun 18, 2016): You could use [task lists](https://guides.github.com/features/mastering-markdown/) to keep track of what's done, and what's not. Also, the 3rd one should be: "Store derived **keys** in client instead of password"

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@MaxXor commented on GitHub (Jun 18, 2016):

Thanks, done.

@MaxXor commented on GitHub (Jun 18, 2016): Thanks, done.

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@GoltikRee commented on GitHub (Jun 24, 2016):

It would be better to perform double HMAC verification istead of simple
More info: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/february/double-hmac-verification/

@GoltikRee commented on GitHub (Jun 24, 2016): It would be better to perform double HMAC verification istead of simple More info: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/february/double-hmac-verification/

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@TheNain38 commented on GitHub (Jun 24, 2016):

@GoltikRee To have a secure HMAC comparison, either you do a constant-time one, ~~which is already done~~.
Or, you can do what you said here, that is, compare something that the attacker doesn't know, so, do a HMAC of the HMAC, and compare that.
~~So, here it's already safe, because optimisations are disabled for this function, and it takes a constant time.~~
What you said should indeed be implemented, thanks, because here, it's not assembly, so, you can't make it take constant-time, reliably. Or, this function should be implemented in assembly, and make sure that it takes the same amount of cycles.

@TheNain38 commented on GitHub (Jun 24, 2016): @GoltikRee To have a secure HMAC comparison, either you do a constant-time one, ~~which is already [done](https://github.com/quasar/QuasarRAT/commit/eef7d258c24cdb7cdf5219fbf074031fdc6dd335)~~. Or, you can do what you said here, that is, compare something that the attacker doesn't know, so, do a HMAC of the HMAC, and compare that. ~~So, here it's already safe, because optimisations are disabled for this function, and it takes a constant time.~~ What you said should indeed be implemented, thanks, because here, it's not assembly, so, you can't make it take constant-time, reliably. Or, this function should be implemented in assembly, and make sure that it takes the same amount of cycles.

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@MaxXor commented on GitHub (Jul 7, 2016):

@GoltikRee @TheNain38 Timing attacks are fixed due to this attribute:
https://github.com/quasar/QuasarRAT/blob/master/Server/Core/Helper/CryptographyHelper.cs#L17
Even for the .NET JIT compiler, see here: https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

@MaxXor commented on GitHub (Jul 7, 2016): @GoltikRee @TheNain38 Timing attacks are fixed due to this attribute: https://github.com/quasar/QuasarRAT/blob/master/Server/Core/Helper/CryptographyHelper.cs#L17 Even for the .NET JIT compiler, see here: https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@TheNain38 commented on GitHub (Jul 17, 2016):

@MaxXor Right... i forgot that (I'm not working with C# that much, I mean, never)

@TheNain38 commented on GitHub (Jul 17, 2016): @MaxXor Right... i forgot that (I'm not working with C# that much, I mean, never)

kerem commented

2026-02-27 15:49:32 +03:00

Author

Owner

@DragonzMaster commented on GitHub (Oct 19, 2016):

Hi @MaxXor ,

I think I can take care of most of tasks and I think it is fine to stay with AES-128 for now as it is not that bad. (we won't transfer World War 3 plans) xD
The salt generation will be easy by a helper method then we can store it in the settings after creating it on the first run [IDEA].

But, I've searched (couple of time) for replay-attacks and found that the best way to prevent it by using time-stamp (one-time session token) and make the client/server => send/hash it and it will be checked on both sides also we have to make sure it expires after sometime (maybe 1 min or less) and regenerate new one.

So I want to know your opinion about that and it will be nice if you could implement a fix for replay-attack.

@DragonzMaster commented on GitHub (Oct 19, 2016): Hi @MaxXor , - I think I can take care of most of tasks and I think it is fine to stay with AES-128 for now as it is not that bad. (we won't transfer World War 3 plans) xD - The salt generation will be easy by a helper method then we can store it in the settings after creating it on the first run [IDEA]. But, I've searched (couple of time) for [replay-attacks](https://en.wikipedia.org/wiki/Replay_attack) and found that the best way to prevent it by using time-stamp (one-time session token) and make the client/server => send/hash it and it will be checked on both sides also we have to make sure it expires after sometime (maybe 1 min or less) and regenerate new one. So I want to know your opinion about that and it will be nice if you could implement a fix for replay-attack.