It's not bad crypto, it's an encoding scheme. It's even in the name! Citrix uses this to pass around credentials between disparate systems which might not be part of the same ActiveDirectory forest preventing the use of OS provided ticketing systems. The traffic carrying these credentials are encrypted with SSL, so you shouldn't be able to pull this in cleartext off the wire. It's obviously not a great system, but it does what it's designed to do. Details on abusing this system are available here[1], but they still require getting access to the unencrypted stream which once again will be passed around the network inside an HTTPS connection.

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...

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.

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.

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.

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()

Seeing stuff like that makes me sad. This could be more simply be written as:

    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:

    for x in sys.stdin:
        ...

or

    [... for x in sys.stdin]

(where ... is print(func(x)) as per the post)

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 ...

Funny the blog post is about bad crypto and its all they support.

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.

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?

It's in the post.

wget http://lelf.lu/files/MAGF.py if you absolutely don't want to spoil it