OSCORE AEAD Algorithm option

[sakphea]

Hi,

Just a quick verification. I want to know if the current OSCORE version support other AEAD rather than the default one (AES_CCM_16_64_128) and AES_CCM_16_128_128. I was trying to change it to AES_GCM_128, but it did not work at all and it did not give me much detail of error.

[boaks]

@rikard-sics

Would it be possible, that you jump in?

[rikard-sics]

Currently supported algorithms

The current implementation supports the following algorithms:

• AES_CCM_16_64_128
• AES_CCM_16_128_128
• AES_CCM_64_64_128
• AES_CCM_64_128_128

(See this COSE IANA registry for details about the algorithms)

So currently AES_GCM_128 is not supported. If you try to use it you should get the following error message (which I agree could be more descriptive):

Unable to set lengths, since algorithm

I do however have a separate codebase where I am working on implementing the Group OSCORE protocol, where I have support for AES GCM variations.

Adding support for further algorithms

Perhaps this could be an occasion to add support for further algorithms to OSCORE in Californium, if that is useful for your (and other people's) use cases?

I believe the following algorithms could be added trivially by using CCMBlockCipher.decrypt and CCMBlockCipher.encrypt (as is currently done in EncryptCommon.java with the algorithms I mentioned above):

• AES_CCM_64_64_256
• AES_CCM_16_64_256
• AES_CCM_16_128_256
• AES_CCM_64_128_256

As for adding the following 4, I see 2 different strategies regarding how to do it.

• AES_GCM_128
• AES_GCM_192
• AES_GCM_256
• CHACHA20_POLY1305 (maybe)

Strategy 1 is where I do it "my own way", as I have done in the code base for Group OSCORE.

Strategy 2 relies on re-using as much functionality from Scandium as possible. I believe I could use AeadBlockCipher.encrypt and AeadBlockCipher.decrypt. However to do this it seems I would need to be able to create custom CipherSuites and CipherSpecs, or have other methods available to me where I can specify the key length, MAC length, and possibly the IV length too.

@boaks Do you think it would make sense to add support for these further algorithms, and in such case which strategy would you prefer?

[boaks]

Thanks for your answer.

The stuff in Scandium is more or less a wrapper, so I don't really care, if you use that or not.

From performance perspective, using thread-local crypto function in package cipher may have a benefit.

But in the end, feel free to chose, what is easier and more efficient for you. I guess, maintaining two code bases would take more time for you.

[rikard-sics]

Thanks for your answer.

The stuff in Scandium is more or less a wrapper, so I don't really care, if you use that or not.

From performance perspective, using thread-local crypto function in package cipher may have a benefit.

But in the end, feel free to chose, what is easier and more efficient for you. I guess, maintaining two code bases would take more time for you.

I see, thanks for the feedback!

I will start preparing a PR with my proposed solution.

[boaks]

Just in the case:

v3 is limited by java 7 as minimum required version,
v4 it will java 8.

[sakphea]

Thanks for your clarification.

[rikard-sics]

Just in the case:

v3 is limited by java 7 as minimum required version, v4 it will java 8.

Thanks. I have now created a PR with a proposed solution at #2272

The code will run with Java 7, but of course what algorithms can be practically used relies on support in the JCE (depending on Java version, strong crypto support, BouncyCastle use etc.)

[rikard-sics]

Hi,

Just a quick verification. I want to know if the current OSCORE version support other AEAD rather than the default one (AES_CCM_16_64_128) and AES_CCM_16_128_128. I was trying to change it to AES_GCM_128, but it did not work at all and it did not give me much detail of error.

The pull request to add support for the new algorithms has now been merged, so feel free to try again using the latest Californium if you wish.

@boaks I noticed now that there is a list of algorithms supported by OSCORE in the README.md. Is it appropriate to update it now (if so I can do it), or do you typically wait until the release of a new version?

[boaks]

list of algorithms supported by OSCORE in the README.md.

Yes, please update the README.

My current plan is to release v3.13 mid of September (depending on some open work for the CoAP S3 Proxy).

[rikard-sics]

Yes, please update the README.

My current plan is to release v3.13 mid of September (depending on some open work for the CoAP S3 Proxy).

Alright, sounds good. I will create a PR to update the README during next week.

[rikard-sics]

Yes, please update the README.
My current plan is to release v3.13 mid of September (depending on some open work for the CoAP S3 Proxy).

Alright, sounds good. I will create a PR to update the README during next week.

Just to note here also that this PR has now been created and merged (#2275).