Open mattheworiordan opened 8 years ago
@trenouf whilst you are in the Crypto stuff, I know what we don't actually adhere to the Crypto spec correctly as there are missing methods / objects according to the 0.8 IDL.
We have had one customer complain about this already and thought that the Java lib was unstable as a result.
Could you specifically check that ChannelOptions
, CipherParams
and Crypto
match the IDL? If there are changes to be made, I suspect there will be no underlying functionality change fortunately.
Will do.
Thanks
ChannelOptions spec points to the java one as a reference!
However the field that the spec thinks should be called cipher
is instead called cipherParams
, and there is another private field called cipher
. That could cause confusion.
CipherParams:
Instead of a binary field key
, it has a SecretKeySpec field keySpec
. I guess we could implement the binary field key
with some code to notice when it has changed and update the keySpec
.
It does not have a mode
field.
It has a ivSpec
public field that is not in the spec.
Crypto:
Missing the generateRandomKey
static method.
Instead of a binary field key, it has a SecretKeySpec field keySpec. I guess we could implement the binary field key with some code to notice when it has changed and update the keySpec.
Is the key
supposed to be mutable? That certainly wasn't the original intention.
From what I can tell:
key
not keySpec
. On @paddybyers's point I am not sure it needs to be mutable, that remains unspecified in the spec. Why can it not simply be provided as binary and remain as binary as an attribute?ChannelOptions#withCipherKey
is missing, and is in fact used in our documentation, see https://www.ably.io/documentation/realtime/encryption. So that definitely needs fixing.I think we should definitely get this to conform to the spec given our documentation assumes this functionality exists.
I am not sure it needs to be mutable, that remains unspecified in the spec. Why can it not simply be provided as binary and remain as binary as an attribute?
Well the original idea was that concrete subtypes of CipherParams
would have the implementation- or platform-specific realisation of the given params, even if they are created using portably-defined arguments.
However, we have a keySpec
in a Cipher
object, so there's no need for it to be constructed in the CipherParams
.
it should take a Hashmap or language equivalent so that any subset of CipherParams fields that includes a key can be provided.
That's not very java-esque but I suppose it would be a Properties
.
Please see https://github.com/ably/docs/pull/89
We need to ensure this library complies with the changes described in the PR
┆Issue is synchronized with this Jira Task by Unito