[
https://issues.apache.org/jira/browse/GUACAMOLE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283292#comment-17283292
]
Mike Jumper commented on GUACAMOLE-1286:
----------------------------------------
Sure - as long as we maintain backward compatibility with the previous
behavior, I'm happy for things to move toward a standard.
Can you clarify regarding:
{quote}
... even with the signature in the payload it's possible to generate the same
cipher-text thus it is bruteforce-able
{quote}
Is the concern there that _the server integrating Guacamole_ may happen to
generate the same cipher-text? How would that lead to that text being
bruteforce-able?
> 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
> Affects Versions: 1.3.0
> 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)
