I assume this will have a bad time on compressed files?
.zip extension is ignored by default along with other binary formats :)
Right but like .tar.gz, etc. are also a thing
Entropy, a CLI that scans files to find high entropy lines (might be secrets)
71–80 of 141 posts
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#72Earlier quoted context omitted.
The weights of the LLM become the private key (so it better be a pinned version of a model with open weights), and for most practical applications (i.e. unless you're willing to complicate your setup with fancy applied statistics and error correction) you'd have to use a temperature of 0 as baseline. Then, having done all that, such steganography may be detectable using this very tool by encoding the difference betwe…
You seem to be making some weird assumptions? Here's how I would do this: Use some LLM, the weights need to be know to both parties in the communication. Producing text with the LLM means repeatedly feeding the LLM with the text-so-far to produce a probability distribution for the next token. You then use a random number generator to pick a token from that distribution. If you want to turn this into steganography, yo…
I was imagining the message encoded in clear text, not encrypted form, because given the lengths required to coordinate protocol, keys, weights, and so on, I assumed there would be more efficient ways to disguise a message than a novel form of steganography. As such, I approached it as a toy problem, and considered detection by savvy parties to be a feature, not a bug; I imagined something more like a pirate broadcast than a secure line, and intentionally ignored the presumption about the message being encrypted first.
That being said, yes, some of my assumptions were incorrect, mainly regarding temperature. For practical reasons I was envisioning this being implemented with a third party LLM (i.e. OpenAI's,) but I didn't realize those could have their RNG seeded as well. There is the security/convenience tradeoff to consider, however, and simply setting the temperature to 0 is a lot easier to coordinate between sender and receiver than adding two arbitrary numbers for temperature and seed.
I misspoke, or at least left myself open to misinterpretation when I referred to the LLM's weights as a "secret key"; I didn't mean the weights themselves had to be kept under wraps, but rather I meant that either the weights had to be possessed by both parties (with the knowledge of which weights to use being the "secret") or they'd have to use a frozen version of a third party LLM, in which case the knowledge about which version to use would become the secret.
As for how I might take a first stab at this if I were to try implementing it myself, I might encode the message using a low base (let's say binary or ternary) and make the first most likely token a 0, the second a 1, and so on, and to offset the risk of producing pure nonsense I would perhaps skip tokens with too large a gulf between the probabilities for the 1st and 2nd most common tokens.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#73Why would I need to install go to run this tool? I thought one advantage of go was that devs could just distribute a single binary file that works...
I'd love to have it on homebrew but my PR is denied so I'll have to create my own brew tap or convince them to accept it.
I'll also create a docker image.
I just didn't expect this much popularity so the repo isn't 100% ready te be honest
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#74This is very cool, but I have a thought - I see this as a last line of defense, and I am concerned that this would this give a false sense of security leading people to be more reckless with secrets.
Ehhh considering how low the security bar is, I think it is better than nothing. If you inherit a code base, make it a quick initial action to see how much pain you can expect. In practice, I expect a tool like this has so many false positives you cannot keep it as an always running action. More a manual review you run occasionally. I hope that more secrets adopt a GitHub like convention where they are prefaced with…
Indeed. I open-sourced `entropy` after we discovered an actual secret leak in our client codebase
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#75Earlier quoted context omitted.
You seem to be making some weird assumptions? Here's how I would do this: Use some LLM, the weights need to be know to both parties in the communication. Producing text with the LLM means repeatedly feeding the LLM with the text-so-far to produce a probability distribution for the next token. You then use a random number generator to pick a token from that distribution. If you want to turn this into steganography, yo…
I was imagining the message encoded in clear text, not encrypted form, because given the lengths required to coordinate protocol, keys, weights, and so on, I assumed there would be more efficient ways to disguise a message than a novel form of steganography. As such, I approached it as a toy problem, and considered detection by savvy parties to be a feature, not a bug; I imagined something more like a pirate broadcas…
> I was imagining the message encoded in clear text, not encrypted form, [...]
I was considering that, but I came to the conclusion that it would be an exceedingly poor choice.
Steganography is there to hide that a message has been sent at all. If you make it do double duty as a poor-man's encryption, you are going to have a bad time.
> As such, I approached it as a toy problem, and considered detection by savvy parties to be a feature, not a bug; I imagined something more like a pirate broadcast than a secure line, and intentionally ignored the presumption about the message being encrypted first.
That's an interesting toy problem. In that case, I would still suggest to compress the message, to reduce redundancy.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#76Why would I need to install go to run this tool? I thought one advantage of go was that devs could just distribute a single binary file that works...
I'd love to have it on homebrew but my PR is denied so I'll have to create my own brew tap or convince them to accept it. I'll also create a docker image. I just didn't expect this much popularity so the repo isn't 100% ready te be honest
Making a tap is super easy, you just upload a file with 5 LoC to github. I wouldn’t even bother with brew core.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#77Earlier quoted context omitted.
So you do random capital words, random punctuation and add a number somewhere and you’re at 60. Add more for whatever threat model you’re trying to be secure against. https://beta.xkpasswd.net/
The random punctuation sort-of defeats the point, doesn't it? Otherwise, I agree.
Not sure; you can use the same character instead of a space and still get a few bits. Of course different ones would be better, but again, depends on how many bits you actually need.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#78Earlier quoted context omitted.
Entropy is a measure of complexity or disorder of a signal. The interesting part is that the disorder is with respect to the proper basis or dictionary. Something can look complex in one encoding but be low entropy in the right encoding. You need to know the right basis, or figure it out from the context, to accurately determine the entropy of a signal. A much stronger way of building a tool like the OP is to have a…
bookmarking to think about later... does this hold for representing numbers as one base compared to another? Regarding a prime as having higher entropy / less structure than say a perfect square or highly divisible number a prime is a prime in any base, but the number of divisors will differ in non-primes, if the number is divisible by the base then it may appear to have more structure (smaller function necessary to…
I don't think there's any interesting difference with different bases. Usually the base you represent stuff in is a relatively small number (because using very large bases is already wildly inefficient). I think it only usually makes sense to consider constant or logarithmic bases. If your base is scaling linearly with your number then things are going to be weird.
The problem of finding factors is only complex when you're asking about relatively big factors. If you're looking for constant or log sized factors you can just do trial division and find them.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#79Is there any good posts about the use of entropy for tasks like that? I am wondering for quite some time of how do people actually use it and if it is any effective, but never actually got to investigating the problem myself. First of all, how to define "entropy" for text is a bit unclear in the first place. Here it's as simple as `-Sum(x log(x))` where x = countOccurences(char) / len(text). And that raises a lot of…
The Kolmogorov complexity of an arbitrary string is uncomputable.
Re: Entropy, a CLI that scans files to find high entropy lines (might be secrets)
#80Earlier quoted context omitted.
The random punctuation sort-of defeats the point, doesn't it? Otherwise, I agree.
Not sure; you can use the same character instead of a space and still get a few bits. Of course different ones would be better, but again, depends on how many bits you actually need.
I thought the point was to construct a password that's secure enough _and_ easy to remember for humans.
Adding random punctuation helps with the former, but might interfere with the latter. (In the extreme case, you just generate completely random strings character for character. That's the most secure, but the least memorable.)