[
https://issues.apache.org/jira/browse/GUACAMOLE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283675#comment-17283675
]
Romain Jufer edited comment on GUACAMOLE-1286 at 2/12/21, 1:19 PM:
-------------------------------------------------------------------
Hello [~grintor], I work with [~bnzelic]. I entirely agree with your message
above, in the case of CBC-MAC you must have a 0 IV. However, I might be
mistaken, but you are not using CBC-MAC in your implementation. CBC-MAC is a
way of generating a MAC from a block cipher, the MAC being the last block
produced by the block cipher. You must not use it for encryption. According to
the comment in the code, you already append a MAC generated by HMAC-SHA256 to
the plaintext so there is no need to use CBC-MAC. I might be wrong in saying
that you use CBC-MAC for encryption because I don't see the `encrypt` function,
but from the implementation of the `decrypt` function it looks like you do, due
to the fact that you pass an IV 0. Let me now if my explanation is unclear :)
Hello [~mjumper], this is more malleability than bruteforce-able. With a
constant IV you could theoretically perform prefix attacks in the case where
two plaintext share the same prefix. 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. Another
threat could be that an attacker deduce that two plaintexts are the same since
the encryption would be the same (no randomized IV). While this is not always a
problem, it's often better to stick to the hypothesis made by the cipher
implementation in order to avoid any problem. Don't know if that answer your
question ?
was (Author: romainjufer):
Hello [~grintor], I work with [~bnzelic]. I entirely agree with your message
above, in the case of CBC-MAC you must have a 0 IV. However, I might be
mistaken, but you are not using CBC-MAC in your implementation. CBC-MAC is a
way of generating a MAC from a block cipher, the MAC being the last block
produced by the block cipher. You must not use it for encryption. According to
the comment in the code, you already append a MAC generated by HMAC-SHA256 to
the plaintext so there is no need to use CBC-MAC. I might be wrong in saying
that you use CBC-MAC for encryption because I don't see the `encrypt` function,
but from the implementation of the `decrypt` function it looks like you do, due
to the fact that you pass an IV 0. Let me now if my explanation is not unclear
:)
Hello [~mjumper], this is more malleability than bruteforce-able. With a
constant IV you could theoretically perform prefix attacks in the case where
two plaintext share the same prefix. 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. Another
threat could be that an attacker deduce that two plaintexts are the same since
the encryption would be the same (no randomized IV). While this is not always a
problem, it's often better to stick to the hypothesis made by the cipher
implementation in order to avoid any problem. Don't know if that answer your
question ?
> 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)
