Current State of Kloak?

1 Like

Package build on the ARM hardware platform might be fixed in Debian bullseye and above:
arm support · Issue #25 · vmonaco/kloak · GitHub

Might try again on Debian bullseye.

arm support · Issue #25 · vmonaco/kloak · GitHub

1 Like

This will be solved with the addition of libsodium.

2 Likes
1 Like

I’m honestly really surprised that this commit hasn’t been added yet. He’s essentially done what was supposed to have been done years ago, make mouse fingerprinting hard and made it happen in Qubes.

If the upstream being dead is why, then why not just add the code into the next Whonix version? If you need help adding the lines of code in from the pull request, I can assist.

1 Like

Does chatgpt by adrelanos · Pull Request #49 · vmonaco/kloak · GitHub look good to you?

Some activity here today:

Not easy for me. I don’t speak C and therefore I cannot accept major C contributions by new/anonymous contributors due the security risk. With tiny exception (Existing Ports of and Porting Whonix to other Architectures), all C(++) code in Whonix comes from trusted sources such as packages.debian.org or TBB from torproject.org

So ideally:

  • common code paths make sense for non-Qubes and Qubes (if any of these are changed) so upstream is comfortable to merge them
  • Otherwise Qubes specific code paths stay out of the way for non-Qubes.
  • I need a trusted C code reviewer. Reviewing at least for non-maliciousness. Functionality testing we have testers here.
  • Hopefully upstream could review the Qubes specific code paths for non-maliciousness and then trust Whonix contributors to test functionality in Qubes. (I don’t have any indications that upstream is using Qubes and that’s a big ask.)

Unfortunately quote common that projects from academic backgrounds are unmaintained in the long run. General huge issue of code getting deprecated after a while in Open Source due to lack of contributors and non-existent business model.

A different approach would be for you to independently fork kloak and then get it merged into Tails or even better packages.debian.org. Maybe it doesn’t need to come to that. Let’s see how active upstream now is.


A wholly different idea: Any reason this must be written in C? Could this be rewritten in python or something?


I was pleasantly surprised that the C level suggestions in https://github.com/vmonaco/kloak/pull/49 got a positive review from upstream.

Before I overload (low activity) upstream with more suggestions by chatgpt… (I wanted to wait until Multi-device support by vmonaco · Pull Request #38 · vmonaco/kloak · GitHub and https://github.com/vmonaco/kloak/pull/49 are merged.9

Could I ask you please (apparently higher activity) to have a look at my GitHub - adrelanos/kloak at chatgpt2 branch. (Just increasing branch numbers by 1.) Has only 1 commit for now. Fix potential buffer overflow vulnerabilities · adrelanos/kloak@11f48c4 · GitHub

I am hoping it can fix grave usability issues such as starting kloak resets keyboard layout · Issue #12 · vmonaco/kloak · GitHub and keyboard randomly sometimes stops working · Issue #31 · vmonaco/kloak · GitHub by more defensive coding to fix some broken corner cases.

Not sure if you have access to chatgpt4 (version 4). But if you have, could you run it through chatgpt4 please to see if it can find (and even fix) some more code issues (in upstream dev branch or your branch)?

quote myself in Multi-device support by vmonaco · Pull Request #38 · vmonaco/kloak · GitHub

Forgot to mention, I tested this + #49 in Whonix today and it was working fine.

This is now in Whonix developers repository.

I need a trusted C code reviewer. Reviewing at least for non-maliciousness.

It’s impossible to prevent bugs as it’s impossible to tell when something will fail if new code is added or code is removed, but I can definitely tell you personally and on Github Issues for those projects if C code is not cryptographically sound, i.e if it uses insecure PRNG or algorithms.

If it helps you get an idea, I’ve already analyzed the randomness of the bootclockrandomizer (bootclock is safe as it uses /dev/random and uses the shuffle feature of bash, both pretty fast and safe) and have begun analysis of kloak, and it uses libsodium in Pull Request #38 so I am not as worried if this will be included in Whonix, but I am still concerned about the fact that the current version on the Github page uses a insecure RNG that could still fingerprint users. I will still be on the lookout for bugs regarding the mouse obfuscation, but I wanted to just warn you about the RNG and how #38 fixes it depsite not being officially added.

A wholly different idea: Any reason this must be written in C? Could this be rewritten in python or something?

You are right that it could be written in Python if you value ease than being fast, and I have some very promising ways such as pyautogui and keyboard but these both have the consequence of having to be bundled within the python installation on the Whonix system. pyautogui uses some C modules, while keyboard only interacts with pure Python. I’ll definitely look into making it an independent project on my Github page and I fully consent for it to be FOSS for everyone including the Whonix project to use.

1 Like

Better to use Go or Rust or something fast for this sort of thing. Python is likely too slow IMO.

Just my $0.02

1 Like

The advantage of the C version GitHub - vmonaco/kloak: Keystroke-level online anonymization kernel: obfuscates typing behavior at the device level. is that it was created by a researcher.

Problem is that keytrac.net, online keystroke biometrics demoarchive.org is down. So we don’t even have any free, proprietary, public usable, cloud hosted test test website. [1]


[1] Unrealistic to even dream of a freedom software project based one as the key tracking is usually sold for, well, commercial tracking purposes.

Regarding Add Qubes support and include information on installing dependencies in README by skyzzuu · Pull Request #50 · vmonaco/kloak · GitHub

I am not the owner of the GitHub - vmonaco/kloak: Keystroke-level online anonymization kernel: obfuscates typing behavior at the device level. repository. These are just my thoughts. This is not a complete review.

  • Any compile time hardening options seem unrelated and could be moved into its own pull request. These might be generally useful independently of Qubes support.
  • That is a lot of new C code for Qubes just for support. I am not sure it’s going to work to request upstream projects to add lots of Qubes specific code.

Is there a way to implement Qubes support without needing lots of Qubes specific code in kloak?

Quote Feature Request: Anti-Keystroke Fingerprinting Tool · Issue #1850 · QubesOS/qubes-issues · GitHub

Looks like this could be a simple modification to Qubes GUI daemon. Of course would have to be opt-in enabled for select VMs only.

Not sure what that means?

Do you think you could implement provide Linux kernel input device so kloak (anti keystroke deanonymization tool) can be used in Qubes-Whonix · Issue #2558 · QubesOS/qubes-issues · GitHub (ticket says closed but was never implemented)

kloak (anti keystroke deanonymization tool) currently cannot be used inside Qubes.

quote @marmarek:

Hmm, I was under impression it expect X server input device, not not Linux kernel input device. Qubes GUI agent do not expose the later. It shouldn’t be hard to change that, but still it is some code change. Namely, rewrite this function (feed /dev/uinput instead of X input device).