AES CBC w/ fixed IV

[sporkmonger]

Generally not something you want to do. Likely doesn't matter that much given that both the key and IV are baked in, so the current encryption scheme is already just a speed bump, but figured it was worth mentioning at least. I might give the cryptography some reworking a little further down the line.

[n00py]

Hypothetically given the current implementation, if someone were able to access the workspace but not the key, what level of effort (time) do you think it would take to decrypt encrypted traffic? (Just curious)

If you find a way to implement the crypto in a more secure way I'd love a PR. Crypto isn't my forte.

[sporkmonger]

Probably the biggest issue is that fixed IV with fixed key means that repeats of a command result in repeats of the ciphertext. So defenders can infer some information without even touching cryptanalysis. In practice that might not be a huge deal, and again especially because there's a pretty straightforward path to full decryption still. However, if defenders with any cryptography chops saw a communications stream with repeats of an encrypted blob, I mean, I know my first thought is "AES CBC, fixed IV, fixed key." So I think my concern would be primarily that it gives a defender a big hint where to look next.

But I guess if you get into the workspace, that implies you extracted the tokens already, and I don't know how you extract the tokens but not the key?

[n00py]

I think the only attack vector where they have workspace access but not the key is if they are Slack themselves. Or if for some reason a user account with access to the workspace was compromised. Or if the target is breaking TLS, but the binary is deleted before they can pull it.