[
https://issues.apache.org/jira/browse/GUACAMOLE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283759#comment-17283759
]
Chris Wheeler commented on GUACAMOLE-1286:
------------------------------------------
Hello [~RomainJufer], I looked at it more closely, and you are correct, this is
not implementing CBC-MAC. Furthermore, since the sender and the recipient would
presumably be storing the IV as a pre-shared secret, and not transmitting it
with each message, then it wouldn't matter anyway. But, I would point out a few
things:
RE:
{noformat}
According to the comment in the code, you already append a MAC generated by
HMAC-SHA256 to the plaintext{noformat}
Your concern about the prefix attack may be alleviated by knowing that the HMAC
is not being appended to the message, but _prepended_. Which means that no two
prefixes will be the same in cases where the rest of the message is not
identical. Since the timestamp in the json has millisecond precision, then the
probability of two messages being identical is already pretty low, but if you
wanted to ensure that it was a practical impossibility, then you could set up
your implementation so that a 128 bit (or greater) nonce is included with the
message. Guacamole ignores fields in the json which it does not understand, so
you can add a nonce in there without any risks.
RE:
{noformat}
Another threat could be that an attacker deduce that two plaintexts are the
same since the encryption would be the same{noformat}
The proposal of a configurable IV would not solve this issue, to use an IV to
solve that issue, you would need to use a random IV and transmit it with each
message, because using the same static IV with each message is going to result
in the same encrypted end-result when the messages are the same. So at this
point we are talking about changing the protocol, but we already have a
solution that serves the same purpose without changing the protocol (use a
nonce in the json)
RE:
{noformat}
In addition, since it looks like the implementation use a MAC-then-Encrypt
approach, you could eventually forge valid encryption. This is why
Encrypt-Then-Mac is often preferred.{noformat}
I agree that Encrypt-Then-Mac is often preferred, but I don't know of, and
can't find any, practical attacks against MAC-then-Encrypt. 256 Bit AES is
often preferred to 192 bit AES, But that doesn't mean 192 bit AES is able to be
broken.
I don't think that the solution here is to change the implementation, but to
add an example to the documentation of using a nonce in the json, and encourage
it's use.
> Support a custom IV in guacamole-auth-json
> ------------------------------------------
>
> Key: GUACAMOLE-1286
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1286
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-json
> Reporter: Bojan Zelic
> Priority: Major
>
> It would be nice to support a custom (not-null) IV in guacamole-auth-json
> We have a cryptography expert at our company that took a look at the
> implementation here:
> [https://github.com/apache/guacamole-client/blob/master/extensions/guacamole-auth-json/src/main/java/org/apache/guacamole/auth/json/CryptoService.java#L76]
> according to him:
> * Having a null-IV coupled with the cipher that Guacamole is using (CBC) is
> far from ideal from security perspective, even with the signature in the
> payload it's possible to generate the same cipher-text thus it is
> bruteforce-able
> * He also thinks that it could be nice to use a standard like AEAD
> (https://en.wikipedia.org/wiki/Authenticated_encryption) in Guacamole instead
> of using a custom implementation.
> We believe that allowing a null-IV could be problematic and allowing a
> configurable IV would be a great short-term solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
