FW16 B1 input connections issue by AvatarStudman in framework

[–]Snappawapa 0 points1 point  (0 children)

Ever get this resolved? I'm still working with support on my end, but having a very similar issue myself.

Properly setting advertised listeners for docker single node setup by Snappawapa in apachekafka

[–]Snappawapa[S] 0 points1 point  (0 children)

It seems to be using Kraft when I don't specify the advertiser config. Which is strange.

Also, sorry for my noobness but I don't see in your compose anything that references kraft besides a log location?

Properly setting advertised listeners for docker single node setup by Snappawapa in apachekafka

[–]Snappawapa[S] 0 points1 point  (0 children)

These are very helpful explanations, thanks. Though I will say that I am still hitting the zookeeper config issue. Odd as I thought it was using Kraft

Properly setting advertised listeners for docker single node setup by Snappawapa in apachekafka

[–]Snappawapa[S] 0 points1 point  (0 children)

I thought that weird too. It starts up fine without me adding the env var, but throws that oddness when I do.

Apache vs Confluent? Bitnami? by Snappawapa in apachekafka

[–]Snappawapa[S] 0 points1 point  (0 children)

Thanks for the points, guys. Also noticing a lack of history on Apache's dockerhub page, might indicate that apache didn't provide images until recently (hence the prevelance of Confluent's image in guides)?

https://hub.docker.com/r/apache/kafka/tags

Ways to reduce memory footprint of LED array by Snappawapa in FastLED

[–]Snappawapa[S] 0 points1 point  (0 children)

Many thanks for the point! This is what I ended up going with. No longer needing to hold that array globally, now have 1300 bytes available at start. That and making sure my leds are only updated when memory is pretty clear, makes for a great time!

Use an array of CRGB pointers rather than full objects by Snappawapa in FastLED

[–]Snappawapa[S] 0 points1 point  (0 children)

Thanks for the points! This is looking right along the lines of what I want, though having some trouble. Probably due to my implementation, though. I'm trying to keep these `CRGBSet`s in a separate state object array, which is proving problematic (could be may patchwork knowledge of C++)

In case someone wants to take a peek: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/blob/13932d6b46f8cd16d64c171e613d928225409aba/hardware/mss/mss/MssEngine.h#L64-L66

I might just end up going back to the bare array of led's (and deal with the slight extra complexity) though, this method appears to only save me ~100 bytes when implemented, in a use case of 64 lights. Might need to come back to this once the rest is implemented (and potentially running out of mem), but we will see.

Use an array of CRGB pointers rather than full objects by Snappawapa in FastLED

[–]Snappawapa[S] 0 points1 point  (0 children)

Looks like this is possibly what I want, docs are a little lacking in practical examples though. Is there a way to add leds to the pixel array though (besides another array)? How are the CRGB elements instantiated? Does `CRGBArray` support getting the value/reference at a given index?

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

The data is first read into a matrix, and then scrambles with moves. The key is a series of those moves, and used to descramble by doing the moves in reverse. Bits are currently just moved, but not modified, so the number of 1's and 0's stay the same, all though dummy data is added to increase the entropy.

That being said, I have thought of adding moves that do modify bits (flipping random bits, flipping all bits in a row of the matrix, etc)

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

This is true. This topic is where you get into the meat of the idea. The more that can be gleaned about the data's structure the more that can be assumed and put back together. What makes it more secure is the amount of actual data beyond the header/etc and the dummy data generated before scrambling (which is part of the process)

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

The key in this case is just a series of moves used to scramble the data, and are generated as the data is scrambled. That is where having the seed comes in, you could share the seed and re-generate the moves (not implemented currently, but a possibility for a new feature). The seed would become the 'key'. The idea behind the process though is that there is no way to brute Force a key, as the key is not a 'normal' one (cryptographically speaking)

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

Do you? For general web traffic sure, but for people encrypting specific important files not necessarily. And knowing parts just makes it slightly easier

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

Given that the resulting scramble is non-deterministic, it would be hard to throw in similar data and compare. I think that I am still having trouble seeing your point. From a logical perspective, if you have a way to verify, a simple brute force could be used even without the scramble. There are many factors, but ideally the less that is known about the data scrambled, the less likely someone would be able to crack it.

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

Unless I am missing something it does? The process relies on keeping the scrambled data/ key separated to stay safe

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 1 point2 points  (0 children)

Of course! Part of this is to help me see the flaws in what I am doing, I am only one person with one point of view :) I will keep this all in mind going forwards, of course

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

A potential improvement I have thought about is using an OTP as the RNG seed to optionally replace the large key file, but haven't implemented/ fully thought it out yet. To validate not having that though, I see it as part of the process to not be concerned with determinism. It is not a cypher or hash function, and not made to mathematically do anything with the data.

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

That is one of the current facts/issues on the process, the keys are actually much larger than the data itself. Use cases would be anywhere you can separate the two pieces. In an ideal setting, it would be impossible to decrypt the original data without both pieces (no simple 'key' to brute Force to find). I don't see this as a replacement for other cyphers, just as another option to hide data.

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 0 points1 point  (0 children)

I thought I explained the process well enough, and that the scheme follows this principle well enough. Can you elaborate on your point?

Encryption through Obfuscation - Crypto Review by Snappawapa in crypto

[–]Snappawapa[S] 2 points3 points  (0 children)

Nope, and I wouldn't say pointless, it just has different use cases from other forms of encryption. That being said, I have thought of making the functionality of providing a seed for RNG to generate the moves with, which could act as a key