[FEAT] added randomize pixels function to pixelate tool

[kurayami07734]

Fixes #3289

Concerns

Pixelate tool's look changes completely. It now looks like white noise

Changes

• Added a randomize pixels function to pixelate tool
• Utilized random_shuffle from <algorithm> and memcpy from <cstring>

Results of cursory test

before

after

[mmahmoudian]

@kurayami07734 Thanks for the great work. Is it possible to:

1. change the pixel size in accordance to the tool size that the user is using?
2. considering that its a drastic change, can you add an item in the settings that allow the user to toggle this on/off? This is good for privacy, but it now looks like an extra opaque layer. This may cause backlash from users.

[kurayami07734]

change the pixel size in accordance to the tool size that the user is using?

I did not find where exactly the pixel size is being set

considering that its a drastic change, can you add an item in the settings that allow the user to toggle this on/off? This is good for privacy, but it now looks like an extra opaque layer. This may cause backlash from users.

I tried to add a setting for this in my latest commit. I followed the example of other settings already present. I am some how getting a segfault now

QLayout: Attempting to add QLayout "" to SidePanelWidget "", which already has a layout

Edit

I've narrowed it down to QAbstractButton::setChecked(bool)
I am probably not using the connect function properly

[kurayami07734]

Hey guys, you probably missed this PR

[veracioux]

@kurayami07734 I'm reviewing your PR now. Sorry about the wait.

[nxmndr]

Is it not the same issue as #2439, #3323, #3242 etc ?

The current blur tool can be set at max size by scrolling and I think the effect is very satisfying. I'd rather have it than these little dots (no offense). It may not be clear enough that the scroll can be used for size though.

[kurayami07734]

Is it not the same issue as #2439, #3323, #3242 etc ?

The current blur tool can be set at max size by scrolling and I think the effect is very satisfying. I'd rather have it than these little dots (no offense). It may not be clear enough that the scroll can be used for size though.

I've randomized the pixel using std::random_shuffle, so it looks like white noise a bit.

Also, can I run flameshot from wsl?
I'm this error flameshot: error: Unable to connect via DBus

[nxmndr]

Ah my bad it will be a separate toggle/option. Cool.

[AlexFolland]

What's the status of reviewing this? The only conversation in the latest review looks resolved. I'm specifically referring to the need to add an initRandomizePixels call to the GeneralConf constructor, which was done. Is this ready for merging?

[jrpie]

The pRNG is not initialized using a suitably secure seed (time can be brute forced, or - in the case of images - simply taken from the metadata). Hence using this implementation does not improve security over pixelation (it might even be worse).

More generally I'd argue that the contents of the area to be hidden should not be used as an input at all, see my comment on #3289.

[AlexFolland]

The pRNG is not initialized using a suitably secure seed (time can be brute forced, or - in the case of images - simply taken from the metadata). Hence using this implementation does not improve security over pixelation (it might even be worse).

That's a good point. Using something like time since local boot instead of time since epoch in the seed assignment (currently unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();) would be a useful change.

[jrpie]

Using uptime is not a good idea either. The uptime of most machines is less that a month. And a month has only about 2.6 * 10^6 seconds which can be easily brute-forced. Using time to generate secure random numbers is not going to work. What would be needed is a CPRNG.

A better solution would be to sort the pixels by value and then shuffle using an insecure PRNG for the same visual effect. That way reversing the insecure shuffling would only reveal the sorted pixels.

However as I said I'm not convinced that the approach of shuffling works at all. All values of all pixels are kept, which is quite a lot of information. There might be situations where e.g. the precise number of oddly colored pixels from subpixel rendering might reveal substantial information about the secret. The point is that I have absolutely no idea how to prove that no such attack exists. I'm also quite pessimistic about other similar approaches. There are simply way too many footguns.
However when not using the input at all, proving security is trivial.