search

eclipse-californium / californium

CoAP/DTLS Java Implementation
https://www.eclipse.org/californium/
Other
729 stars 365 forks source link

OSCORE AEAD Algorithm option #2268

Closed sakphea closed 3 weeks ago

sakphea commented 2 months ago

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 commented 2 months ago

@rikard-sics

Would it be possible, that you jump in?

rikard-sics commented 2 months ago

Currently supported algorithms

The current implementation supports the following algorithms:

(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):

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

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Just in the case:

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

sakphea commented 2 months ago

Thanks for your clarification.

rikard-sics commented 2 months ago

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 https://github.com/eclipse-californium/californium/pull/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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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).

boaks commented 3 weeks ago

Is this done? I released today 3.13 so that should be included and I would like to close the issue.

rikard-sics commented 3 weeks ago

Is this done? I released today 3.13 so that should be included and I would like to close the issue.

Yes, from my point of view this is done and the issue can be closed. The support for the additional algorithms was added and updated information included in the README. The error message when attempting to use an unsupported algorithm was also improved.