Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for SHA-3 hash function #7881

Merged
merged 5 commits into from
Mar 6, 2018
Merged

Conversation

mtausig
Copy link
Contributor

@mtausig mtausig commented Oct 26, 2017

Add the SHA-3 hash function to the hashes module

The output lengths SHA3-256, SHA3-384 and SHA3-512 are supported.

The code is taken from the public domain implementation of the original authors.

Almost finished, just need to test it some more and add the documentation.

@miri64 miri64 requested a review from BytesGalore October 26, 2017 23:13
@miri64 miri64 added Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: security Area: Security-related libraries and subsystems labels Oct 26, 2017
@miri64 miri64 added this to the Release 2017.10 milestone Oct 26, 2017
@miri64 miri64 added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 27, 2017
@emmanuelsearch
Copy link
Member

The main arguments for the package approach is that:

  • we are in contact with the Keccak maintainers, and
  • the package is currently maintained/developed.

Hence it makes more sense to add a package such as in #7903 rather than copy the code over to the RIOT repo, in my opinion.

@mtausig
Copy link
Contributor Author

mtausig commented Oct 30, 2017

@emmanuelsearch I disagree. I think that an essential standard function like SHA-3 should be part of the main distribution, available for easy usage and not hidden away in a package.
Maintainance is also not really an issue here, since the code is pretty static anyway. The code I used had its last commit 2 1/2 years ago and isn't likely to change anytime soon.

What would make sense as a seperate (and additional) package in my opinion, would be a more generic Sponge crypto package featuring a generic sponge implementation plus some different permutations plus all the fancy crypto functions that you can do with a sponge (hash, mac, rng, aead, xof, streamcipher)

@emmanuelsearch
Copy link
Member

emmanuelsearch commented Nov 6, 2017

@mtausig OK, I see your point. Maybe you're right. Any other opinions out there?
Else let's go for what you propose, with this PR and in parallel the package approach initiated by #7903

@kaspar030
Copy link
Contributor

What would make sense as a seperate (and additional) package in my opinion, would be a more generic Sponge crypto package featuring a generic sponge implementation plus some different permutations plus all the fancy crypto functions that you can do with a sponge (hash, mac, rng, aead, xof, streamcipher)

What would speak for only using a package is that if sponge crypto and sha3 is used in the same image, it would share code, correct?

@mtausig
Copy link
Contributor Author

mtausig commented Nov 6, 2017

What would make sense as a seperate (and additional) package in my opinion, would be a more generic Sponge crypto package featuring a generic sponge implementation plus some different permutations plus all the fancy crypto functions that you can do with a sponge (hash, mac, rng, aead, xof, streamcipher)

What would speak for only using a package is that if sponge crypto and sha3 is used in the same image, it would share code, correct?

Yes, that would prevent code duplication. But it would hide away the sha-3 functions (which are, what most people are going to need) from a lot of users and it would introduce some inconsistency (sha2 and sha2 in the main code, sha3 in a package).

@mtausig mtausig changed the title [WIP] Add support for SHA-3 hash function Add support for SHA-3 hash function Nov 13, 2017
@mtausig
Copy link
Contributor Author

mtausig commented Nov 13, 2017

Finished, from my point of view.

@smlng smlng removed this from the Release 2018.01 milestone Jan 12, 2018
@emmanuelsearch emmanuelsearch added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Feb 28, 2018
@emmanuelsearch
Copy link
Member

@mtausig can you check the output of Murdock?
Static checks are failing.
Can you fix?

@mtausig
Copy link
Contributor Author

mtausig commented Mar 1, 2018

OK. I have fixed everything (apart from squashing) that's in my power.
The one problem remaining is the licence header of sha3.c. Since it is mostly the original Keccak code I have to stick with the original (CC-0) licence. Could Travis be adapted to accept CC-0 licences?

@emmanuelsearch emmanuelsearch added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 1, 2018
@emmanuelsearch
Copy link
Member

@miri64 actually we should probably add CC0 in the list of accepted license header patterns, is that right ?

@miri64
Copy link
Member

miri64 commented Mar 1, 2018

I guess so.

@emmanuelsearch
Copy link
Member

added a pattern for CC0 in #8716

@mtausig
Copy link
Contributor Author

mtausig commented Mar 1, 2018

Do I have to rebase for the pattern to work?

}
#endif

#endif /* HASHES_SHA3_H */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really nit-picky, but the script actually complains about the 2 whitespaces between #endif and /* (it seems that it it supposed to be only 1...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Next try.
It would be great to have those outputs visible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #8737

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(header guards are now okay 😌 )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to have done the trick.

@mtausig mtausig force-pushed the feature/sha3 branch 2 times, most recently from 74179e0 to 368488b Compare March 5, 2018 12:53
@mtausig
Copy link
Contributor Author

mtausig commented Mar 5, 2018

Squashed & Rebased

@miri64 miri64 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 5, 2018
Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little more in-depth review now. Also tested current version on native and samr21-xpro successfully.

0x58, 0x54, 0xB4, 0x1C, 0xC4, 0x7A, 0xD1, 0x52,
0x94, 0xBC, 0x41, 0xF3, 0x21, 0x65, 0xDF, 0xBA };
static const uint8_t hfail_384[] = { 0x89, 0xDB, 0xF4, 0xC3, 0x9B, 0x8F, 0xB4, 0x6F, 0xDF, 0x0A, 0x69, 0x26, 0xCE, 0xC0, 0x35, 0x5A, 0x4B, 0xDB, 0xF9, 0xC6, 0xA4, 0x46, 0xE1, 0x40, 0xB7, 0xC8, 0xBD, 0x08, 0xFF, 0x6F, 0x48, 0x9F, 0x20, 0x5D, 0xAF, 0x8E, 0xFF, 0xE1, 0x60, 0xF4, 0x37, 0xF6, 0x74, 0x91, 0xEF, 0x89, 0x7C, 0x23 };
static const uint8_t hfail_512[] = { 0x15, 0x0D, 0x78, 0x7D, 0x6E, 0xB4, 0x96, 0x70, 0xC2, 0xA4, 0xCC, 0xD1, 0x7E, 0x6C, 0xCE, 0x7A, 0x04, 0xC1, 0xFE, 0x30, 0xFC, 0xE0, 0x3D, 0x1E, 0xF2, 0x50, 0x17, 0x52, 0xD9, 0x2A, 0xE0, 0x4C, 0xB3, 0x45, 0xFD, 0x42, 0xE5, 0x10, 0x38, 0xC8, 0x3B, 0x2B, 0x4F, 0x8F, 0xD4, 0x38, 0xD1, 0xB4, 0xB5, 0x5C, 0xC5, 0x88, 0xC6, 0xB9, 0x13, 0x13, 0x2F, 0x1A, 0x65, 0x8F, 0xB1, 0x22, 0xCB, 0x52 };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where are all these values coming from? Please provide a comment.


RIOT OS adaptations (c) Mathias Tausig

This software is released under the Creative Commons CC0 1.0 license. To the extent possible under law, the implementer has waived all copyright and related or neighboring rights to the source code in this file. For more information see: http://creativecommons.org/publicdomain/zero/1.0/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please address!

* [Keccak Reference] http://keccak.noekeon.org/Keccak-reference-3.0.pdf
* [Keccak Specifications Summary] http://keccak.noekeon.org/specs_summary.html

This file uses UTF-8 encoding, as some comments use Greek letters.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some of the content of this could go into the details section of the sha3.h header file (otherwise it isn't added to the online-documentation, since C-files are excluded):

/**
 * @ingroup     sys_hashes
 * @{
 *
 * @file
 * @brief       Header definitions for the SHA-3 hash function
 *
 * <put it here>
 */

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added that information into the author field. Is that OK?
9a6bf99

* from position <i>n</i>+1 to position 7.
* Some examples:
* - If no bits are to be appended, then @a delimitedSuffix must be 0x01.
* - If the 2-bit sequence 0,1 is to be appended (as for SHA3-*), @a delimitedSuffix must be 0x06.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line length (see coding conventions)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why the line length is not handled by the uncrustify configuration?

* @param outputByteLen The number of output bytes desired.
* @pre One must have r+c=1600 and the rate a multiple of 8 bits in this implementation.
*/
void Keccak(unsigned int rate, unsigned int capacity, const unsigned char *input, unsigned long long int inputByteLen, unsigned char delimitedSuffix, unsigned char *output, unsigned long long int outputByteLen);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is internal to this C-file, so please make it static

/**
* @brief Squeeze data from a sponge
*
* @param ctx context handle of the sponge
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito

/**
* @brief SHA-3-256 initialization. Begins a SHA-3-256 operation.
*
* @param ctx keccak_state_t handle to initialise
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito

/**
* @brief Add bytes into the hash
*
* @param ctx context handle to use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito

* @brief SHA-3-256 finalization. Pads the input data and exports the hash value
*
* @param ctx context handle to use
* @param digest resulting digest, this is the hash of all the bytes
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dito for ctx an digest.

/**
* @brief SHA-3-384 initialization. Begins a SHA-3-256 operation.
*
* @param ctx keccak_state_t handle to initialise
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

etc.

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to set to change request...

@mtausig
Copy link
Contributor Author

mtausig commented Mar 6, 2018

@miri64 I think I have addressed all of your concerns. Thanks for the feedback.

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK (except for a minor optional improvement suggestion). Please squash.

typedef uint64_t UINT64;
typedef UINT64 tKeccakLane;

#ifndef LITTLE_ENDIAN
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically you can define this in this file so the user doesn't need to get active:

#if __BYTE_ORDER__ == __ORDER__LITTLE_ENDIAN__
#define LITTLE_ENDIAN
#endif

Copy link
Contributor Author

@mtausig mtausig Mar 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. 71cd9bd

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll wait for Murdock and squash afterwards.

@emmanuelsearch emmanuelsearch added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 6, 2018
@mtausig
Copy link
Contributor Author

mtausig commented Mar 6, 2018

Squashed.

@emmanuelsearch
Copy link
Member

emmanuelsearch commented Mar 6, 2018

There is a typo in the first commit message "Keccap" => "Keccak" ;)

@mtausig
Copy link
Contributor Author

mtausig commented Mar 6, 2018

@emmanuelsearch Oops. Fixed.

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last thing, I swear:

  1. Commit message Import Keccak code from Keccak Code Pacakge has a typo "Pacakge" => "Package"
  2. Please prefix all your commit messages with the module you add/modify, e.g. hashes: or hashes: sha3: .

Mathias Tausig added 5 commits March 6, 2018 16:17
Add init/update/final interface
Add interface functions for direct SHA3
Add unit tests for SHA-3
Document functions and types
Reduced var scope in Keccak code
Add CCO Copyright notice to Keccak code
Changed integer typedefs to portable stdint types
Added Endianness define
Remove unused SHAKE functions
Removed unused SHA3-224
@mtausig
Copy link
Contributor Author

mtausig commented Mar 6, 2018

Better?

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thank you for your patience! ACK.

@miri64 miri64 merged commit 0b928b7 into RIOT-OS:master Mar 6, 2018
@mtausig mtausig deleted the feature/sha3 branch March 6, 2018 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: security Area: Security-related libraries and subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants