$ time openssl rand -base64 1000000000 | tr a-z n-za-m >/dev/null
real 0m1.073s
user 0m1.327s
sys 0m0.644s
$ time openssl rand -base64 1000000000 | rot13 >/dev/null
real 0m19.225s
user 0m20.101s
sys 0m0.747sobs4: https://github.com/Yawning/obfs4
obs4 in tor: https://support.torproject.org/glossary/obfs4/
I feel like the article missed out on mentioning one key thing: Using a deny-list doesn’t work. It’s much more viable to default block and allow the stuff you know you’ll allow. Defaulting to allow and blocking stuff you don’t want is how you end up being owned by rot13.
"The Six Dumbest Ideas in Computer Security"
> #1) Default Permit
> #2) Enumerating Badness
I wonder how you might encourage deeper introspection into software infrastructure security vulnerabilities, both from closed source companies and from obscure open source projects, without "spreading breadcrumbs for the roaches"
* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...
* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...
Just create a self-signed certificate:
openssl req -newkey rsa:2048 -nodes -keyout socat.key -x509 -days 1000 \
-subj '/CN=www.mydom.com/O=My Company Name LTD./C=US' -out socat.pem
Some companies mention in their employment contracts these type of circumvention activities, unless explicitly allowed, are a firing offense.
They are clearly already whitelisting connections, but still allow unidentified connections through?! What sort of logic is that?
I'm not a security expert but we had those kind of measures at a previous job and AFAIK they are there so that a lazy employee (me) doesn't just skip configuring their tools to go through Artifactory out of laziness and introduce a supply chain vulnerability. If "pip install XYZ" just worked out of the box, how likely would it be that all 10k devs in your organization would bother configuring it to avoid PYPI?
But if you do not control both ends, let's say you want many customers or even the public to connect to your server that's not an option.
The keyspace is essentially infinite, because of 2 things:
1 you don't have to worry about control bytes (aka "binary")
2 unicode
rot13 using 1/2 of the 26 letter English a-z alphabet is just an arbitrary limit for visual appearance and limitation of the channel in bbs/newsgroup posts.
Things like rot18 and rot47 already widen the alphabet significantly up from 26 to include numbers, punctuation, and more of the "printable" ascii from 0-127, while still avoiding control bytes like null etc.
But this example is using rot13 in a channel passing binary data already, so there is no point avoiding the control bytes like null etc.
So without going to unicode the limit would already be 255.
But the alphabet, and thus the key space, is practically infinite with unicode. Merely your bandwidth goes down when you get to say, 16 encoded bytes per plaintext byte.
In fact, you don't even need to bother 'rotating' anything, you can just pick a random number anywhere from 1 to the zillions, and simply add that number to the plaintext values and subtract from the ciphertext. Rather than rotating, it's just transposing, but that's all rotating is anyway.
You don't even need to install any package like bsdgames either. You can do the encode/decode directly in bash, not even very many lines.
Of course you could do rot2 - rot24 and all the other combinations. Is that were the factor 25 comes from?
The deep inspection needs to look only at the first couple of bytes of each new a TCP connection. So it's not that disrupting. After 2 bytes you can already skip for a vast fraction of other traffic.
cd /lib/firmware
( find -name '*.xz' -exec xzcat {} \; ; find -type f -a \! -name '*.xz' -a -exec cat {} \; ) |
rot13 |
grep -aEo '\w+' |
awk '{print length, $0 }' |
sort -nsru |
head -20
Edit: The sort -u option hides words of the same length. Removing that option (and the head command) gives more results, but nothing that interesting.