Good fun with bad crypto(intrepidusgroup.com)
intrepidusgroup.com
Good fun with bad crypto
https://intrepidusgroup.com/insight/2014/01/good-fun-with-bad-crypto/
5 comments
From your second link: "Please note that for security reasons I have chosen to only allow Encoding via the scripting interface."
It also seems a little odd that it's doing XOR with the sum of all previous characters if there is no attempt to obfuscate.
It also seems a little odd that it's doing XOR with the sum of all previous characters if there is no attempt to obfuscate.
Good point. What, more specifically, is the purpose of the Citrix encoding system? Is it to map an arbitrary byte string onto a limited range of bytes (ASCII A to P)? If so, any reason base 64 was unsuitable for these applications?
Base64 can maybe result in strings unsuitable for pasting as-is into bad HTTP servers' URLs (the default character set include '/' and '+').
Using only the uppercase letters lets them worry less about whether the string got mangled because some systems interpreted it as Unicode and some didn't etc.
Something like Bitcoin and Flickr's base58 would have also worked, but the encoder and decoder would have been more complicated. They got away with only division by 16.
They get a little bit of integrity checking too.
Basically, this is base16 with a poor man's integrity checking baked in. Pretty interesting.
Using only the uppercase letters lets them worry less about whether the string got mangled because some systems interpreted it as Unicode and some didn't etc.
Something like Bitcoin and Flickr's base58 would have also worked, but the encoder and decoder would have been more complicated. They got away with only division by 16.
They get a little bit of integrity checking too.
Basically, this is base16 with a poor man's integrity checking baked in. Pretty interesting.
Ah, so the design of this encoding is specifically targeting URLs? That makes a lot more sense. Thanks!
Knowing that, it does in fact seem like a sensible encoding for certain applications. Encoding, not encryption, mind you. I assume (or at least hope) the designers intended it as the former only, and never as the latter.
Knowing that, it does in fact seem like a sensible encoding for certain applications. Encoding, not encryption, mind you. I assume (or at least hope) the designers intended it as the former only, and never as the latter.
This article coincides perfectly with the online Stanford Crypto class that just started up: https://www.coursera.org/course/crypto We just covered the principles of good encryption, and this is a great exercise to witness in that context.
> x = sys.stdin.readline()
> while x:
> …
> x = sys.stdin.readline()
for x in sys.stdin:
…That doesn't strike me as a very worthwhile criticism of code.
As written, the code will write the response string out immediately. The for x in version will block until end-of-input.
Er... no. No it absolutely wouldn't block until end-of-input.
If list comprehensions were being used to precompute the output and the whole list printed from (what you seem to be thinking of) then perhaps yes, but any of:
as per the GP post will print response strings as the input comes in.
If list comprehensions were being used to precompute the output and the whole list printed from (what you seem to be thinking of) then perhaps yes, but any of:
for x in sys.stdin:
...
[... for x in sys.stdin]
as per the GP post will print response strings as the input comes in.
The two versions are functionally identical, which is why the shorter version without repeated code is better.
Firefox returns: (Error code: ssl_error_no_cypher_overlap) via https
Same here. So i checked what ciphersuits they use.
TLS_RSA_WITH_RC4_128_SHA
Too bad they cant correctly set up their servers ...
TLS_RSA_WITH_RC4_128_SHA
Too bad they cant correctly set up their servers ...
Funny how I had just disabled RC4 and DES in my browser...
I wonder how can that be your only supported crypto in 2014!
For a while, RC4 was recommended because it's immune to the BEAST attack.
A new theoretical attack was published in 2013 that showed that RC4 was still weak in TLS. While the attack was more academic, it did raise questions of what else would be possible.
We often forget that RC4 is a fundamentally broken algorithm.
We often forget that RC4 is a fundamentally broken algorithm.
I'd like to try figuring this out myself as an exercise, and therefore haven't read past the introduction of the article.
Does anyone know where I can find either the application in question or some other program that will at least encode this format?
Does anyone know where I can find either the application in question or some other program that will at least encode this format?
It's in the post.
wget http://lelf.lu/files/MAGF.py if you absolutely don't want to spoil it
wget http://lelf.lu/files/MAGF.py if you absolutely don't want to spoil it
While I'm sure it was an interesting exercise, the author could have saved himself some time and simply Googled the name, there are published scripts and COM objects to deal with this encoding stream such as[2].
[1] http://www.securityfocus.com/archive/1/520869
[2] http://www.remkoweijnen.nl/blog/2013/03/19/scriptable-citrix...