Need example program implementing sha256 or keccak of the avr-crypto-lib

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey everyone.

I'm working on a program in which I need to store a 16-byte (17 including the last '\0') password to EEPROM.

I want not to store it as plain text but to hash it.

I searched the net and found the avr-crypto-lib library; however, I can't make heads or tail out of it.

Can anyone please give me an explanation on how to set up sha256, keccak or any other hashing algorithm available in the library which you think is a better choice?

I will really appreciate simple example programs.

I'm not sure if it is relevant but I'm using the ATMEGA32A so the produced .hex file size should be small enough to be uploaded to it.

Thanks in advance :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is more to password storage than simply

hashing the plaintext password and storing the

hash. Someone who wants to guess your password

can just hash their guesses and check for a match

against the stored hash value.

 

A random "salt" can be added to the plaintext (and

then hash the combination) for a bit better solution,

but this requires also storing the salt value. Even

this is not considered top-notch security, so I suggest

doing some research before rolling your own solution.

 

Also SHA-256 gives a 256-bit result which is 32 bytes

of binary or 64 hex digits to store.  Using Base-64

would need 44 bytes of EEPROM.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hello!

Welcome to AVRfreaks!

 

You might want to try your question in the IOT community as thats the place something like what you are asking would come up.  We don't get much of Crypto traffic here.

 

I can move this thread to that community if you want

 

Jim

Edit:

I see Mike has already provided some insight. 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Sun. Jun 23, 2019 - 03:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the information.

I guess I need to think more about how to store the password safely and properly.

Well, this is just a hobby project of mine and is not that serious. But as you pointed out I should do some research.

However even then I might need to hash the password at some point; hence, I would like to see some examples just to be familiar with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Hello!

Welcome to AVRfreaks!

 

You might want to try your question in the IOT community as thats the place something like what you are asking would come up.  We don't get much of Crypto traffic here.

 

I can move this thread to that community if you want

 

Jim

Edit:

I see Mike has already provided some insight. 

Thanks. I'm happy to have joined you guys :)

I'm sorry if I have posted in the wrong place. I would appreciate it if you moved it to a more suitable place.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mr0099 wrote:
I'm sorry if I have posted in the wrong place.

Nothing to be sorry about.  I was unaware that Mike had/has some experience in what you are looking to achieve, so for the moment we can leave teh thread here, and if it's not doing much, then move it over to the other community

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Is the password variable or fixed? If the latter you might as well just keep it in plain text in the code then, for a hobby project, just rely on the lock bits so no one can see/access your code. The lock bits are "crackable" but it costs $500+

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

mr0099 wrote:
I guess I need to think more about how to store the password safely and properly.
Such is data-at-rest; might consider a KDF.

https://www.embedded.com/design/safety-and-security/4369714/3/Enhance-system-security-with-better-data-at-rest-encryption

(second paragraph)

Generating the key
A typical method of storage encryption key establishment is to convert user credentials into a key using a key derivation function (KDF).

...

in Enhance system security with better data-at-rest encryption | Embedded

 

Passwords can be stored in a Microchip crypto-authenticator.

GitHub - MicrochipTech/cryptoauthlib: Library for interacting with the Crypto Authentication secure elements

The TWI or one-wire interface would be vulnerable to cracking though hardware methods like potting and/or secure enclosure detection combined with software methods (hash, etc) may be secure enough.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Is the password variable or fixed? If the latter you might as well just keep it in plain text in the code then, for a hobby project, just rely on the lock bits so no one can see/access your code. The lock bits are "crackable" but it costs $500+

The password is variable and the hash needs to be performed several times.

Basically, I want to create a program which will hash the password entered by the user  (through a keypad, for now, I might add UART later) and compare it to the one stored in the EEPROM and activate a relay if the hashes match.

There is also a change password key which asks for the current password, compare hashes, then gets the new password, hashes it and updates the EEPROM value with the new value.

Of lock bits, however, I don't have much knowledge. So, I guess I should read about them as they could be useful in future applications.

Thank you again :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:

mr0099 wrote:
I guess I need to think more about how to store the password safely and properly.
Such is data-at-rest; might consider a KDF.

https://www.embedded.com/design/safety-and-security/4369714/3/Enhance-system-security-with-better-data-at-rest-encryption

(second paragraph)

Generating the key
A typical method of storage encryption key establishment is to convert user credentials into a key using a key derivation function (KDF).

...

in Enhance system security with better data-at-rest encryption | Embedded

 

Passwords can be stored in a Microchip crypto-authenticator.

GitHub - MicrochipTech/cryptoauthlib: Library for interacting with the Crypto Authentication secure elements

The TWI or one-wire interface would be vulnerable to cracking though hardware methods like potting and/or secure enclosure detection combined with software methods (hash, etc) may be secure enough.

 

Wow! the description exactly matches a far better version of what I'm trying to achieve.

Thank you so much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mr0099 wrote:
I searched the net and found the avr-crypto-lib library; however, I can't make heads or tail out of it.
Well it looks like the plan is that you edit Makefile_main.inc and edit this section:

BLOCK_CIPHERS  :=
STREAM_CIPHERS :=
HASHES         :=
MACS           :=
PRNGS          :=
ENCODINGS      :=
SIGNATURE      :=
PK_CIPHERS     :=
AUX            :=

and I *think* you would just list the "sha256" directory name alongside "HASHES :=" but it does seem a bit off that such an extensive piece of software apparently has no documentation to explain this?

 

At least for the hash functions the general API is explained in:

 

https://github.com/cantora/avr-crypto-lib/blob/master/USAGE.hashfunctions

 

but you gotta love lines that say things like:

3.1 look at the prototypes
 Generally the prototypes (defined in the *.h files) will tell you what 
 parameter means what. 

I guess this is like one of my old professors used to write on the blackboard "LEER" meaning "Left as an Easy Exercise for the Reader"

 

To be honest though it looks like you could simply take the 3 files from the "sha256" directory and just build them with nothing else. The .h file has a "high level" function called simply sha256() which hides the details of all the _init, _nextblock, _lastblock, _ctx2hsh stuff.

 

Give me a mo' and I'll try an experiment....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


OK so I just added sha256.c to a project in AS7 and then used this as my main();

#include <avr/io.h>
#include "sha256.h"

uint8_t pwd[] = { "12345678" };
sha256_hash_t sha;

int main(void) {
	sha256(&sha, pwd, 8);
}

That builds without error. At first I thought I needed both the .c and the .S file but it seems it is "either/or". You pick whether you want the more efficient Asm implementation or not. In simulation the above reproduced:

 

 

The only small question I have about this result is:

 

 

I'm not getting the same result as this online checker ?!?