5 ms·

If it's CBC without a MAC that's a problem. The fact that this relies on MEF means that MEF should also be secure. Also if the code is based off of .NET I'm n

If it's CBC without a MAC that's a problem. The fact that this relies on MEF means that MEF should also be secure. Also if the code is based off of .NET I'm not so sure i'd trust it. Hackers are targeting .NET a lot more now. Theres been a lot of reversing going on for it. But alas .NET can be somewhat secure if you use a decent obfuscation method for the compiled binaries. Also someone who also likes encryption yay!

tptacek 13y ago
.NET's crypto libraries are good enough, but this seems to be configured in "1990s crypto mode". I have no idea why reversing matters here. It's an open source project.
- switch33 13y ago
  Yeah but this shit still scares me: http://www.reddit.com/r/netsec/comments/1km0of/injecting_arbritary_code_into_net_assemblies/ http://www.reddit.com/r/netsec/comments/1km0of/injecting_arb... Lol at the reference to "1990s crypto mode." The standards are always funky.
  - tptacek 13y ago
    You can inject into processes on Unix OS's too. Again, not sure what that has to do with this project.
    - switch33 13y ago
      That may be true, but if injection and backdooring a chat service is as easy as just using some simple code thats already floating in the blackmarket. How long do you think before that project would be backdoored? The answer is before the thing is even used there would be some people including some code to attack it. Especially because chat clients are good for botnets. Hackers think they are yummy.
      - tptacek 13y ago
        This is pretty silly.
        switch33 13y ago
        Tell that to the well made botnets developed for teamviewer, msnchat, and the hackers targeting skype as well. It's just another way to mask botnet traffic.
      - geofft 13y ago
        There's plenty of code floating around the white market for injecting code into running UNIX processes. It's a documented feature of the dynamic linker, and has been for decades. Injecting code into a process running in the same security domain is not an attack, regardless of platform.
- aarnott 13y ago
  > .NET's crypto libraries are good enough Many of them call directly into the operating system anyway. > but this seems to be configured in "1990s crypto mode" What do you mean?
  - tptacek 13y ago
    RSA, PKCS #1 v1.5 signatures, unauthenticated CBC.
    - aarnott 13y ago
      What would you use instead of RSA for public keys?
    - aarnott 13y ago
      That's AES, a government standard. And in fact the only option for some platforms (like Windows Phone 8 for example) if you want to rely on what's built into the OS.
aarnott 13y ago
All messages are both signed and encrypted. I can't remember the order, but when it was determined some research was done about the various attacks to mitigate the problem you allude to. I _believe_ we encrypt first, then sign, so that any tampering is detected before decryption begins. Using MEF is optional for the apps that use this library. But I don't see that it opens up new attack vectors. Feel free to enlighten me if you know more on this. And I agree with the other replies to your message about .NET being inherently insecure. It's trivially easy to inject code into any process, native or managed. If you have code executing on the machine (not some VM or runtime), from a security perspective you probably can own it if you like. So IMO the interesting attack vectors have to come in over the network.
- tptacek 13y ago
  Signatures and message authentication codes aren't the same thing.
  - aarnott 13y ago
    But if you have signed the message, MACs are redundant, so why have them?

tptacek 13y ago

.NET's crypto libraries are good enough, but this seems to be configured in "1990s crypto mode". I have no idea why reversing matters here. It's an open source project.

switch33 13y ago
Yeah but this shit still scares me: http://www.reddit.com/r/netsec/comments/1km0of/injecting_arbritary_code_into_net_assemblies/ http://www.reddit.com/r/netsec/comments/1km0of/injecting_arb... Lol at the reference to "1990s crypto mode." The standards are always funky.
- tptacek 13y ago
  You can inject into processes on Unix OS's too. Again, not sure what that has to do with this project.
  - switch33 13y ago
    That may be true, but if injection and backdooring a chat service is as easy as just using some simple code thats already floating in the blackmarket. How long do you think before that project would be backdoored? The answer is before the thing is even used there would be some people including some code to attack it. Especially because chat clients are good for botnets. Hackers think they are yummy.
    - tptacek 13y ago
      This is pretty silly.
      - switch33 13y ago
        Tell that to the well made botnets developed for teamviewer, msnchat, and the hackers targeting skype as well. It's just another way to mask botnet traffic.
    - geofft 13y ago
      There's plenty of code floating around the white market for injecting code into running UNIX processes. It's a documented feature of the dynamic linker, and has been for decades. Injecting code into a process running in the same security domain is not an attack, regardless of platform.
aarnott 13y ago
> .NET's crypto libraries are good enough Many of them call directly into the operating system anyway. > but this seems to be configured in "1990s crypto mode" What do you mean?
- tptacek 13y ago
  RSA, PKCS #1 v1.5 signatures, unauthenticated CBC.
  - aarnott 13y ago
    What would you use instead of RSA for public keys?
  - aarnott 13y ago
    That's AES, a government standard. And in fact the only option for some platforms (like Windows Phone 8 for example) if you want to rely on what's built into the OS.

aarnott 13y ago

All messages are both signed and encrypted. I can't remember the order, but when it was determined some research was done about the various attacks to mitigate the problem you allude to. I _believe_ we encrypt first, then sign, so that any tampering is detected before decryption begins. Using MEF is optional for the apps that use this library. But I don't see that it opens up new attack vectors. Feel free to enlighten me if you know more on this. And I agree with the other replies to your message about .NET being inherently insecure. It's trivially easy to inject code into any process, native or managed. If you have code executing on the machine (not some VM or runtime), from a security perspective you probably can own it if you like. So IMO the interesting attack vectors have to come in over the network.

tptacek 13y ago
Signatures and message authentication codes aren't the same thing.
- aarnott 13y ago
  But if you have signed the message, MACs are redundant, so why have them?