On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Just for reference, the sha.c algorithm did match what I get from Java with the standard sha-256 digest. So it does work for the 18 bytes of our commands. But it sounds like it will not work if we append the secret key twice.
Yes, my impetus for replacing it, plus the new algorithm allows partial adds of data to make the process easier.
I have pushed up an update-sha-hmac branch that reworks all the keying. It uses the hmac-sha256 algorithm for authentication, it adds the code to load the key from NVRAM, and reworks the keysize to be 32 bytes. Reworking the key size will rearrange NVRAM, unfortunately. With this, you should be able to add a key from the command line and have it write it to NVRAM, and use it for the hmac-sha256 authentication. It does remove the AES code.
-corey - AE5KM
73 Chris
On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev pacsat-dev@amsat.org wrote:
I just pulled Authenticate/src/sha.c out of the code and moved it into a separate file and played with it a bit. It wasn't matching the results from sha256sum, and looking at the code, I realized that the implementation only accepts up to 64 bytes of data. It works for buffers less than 64 bytes. It also won't do partial pieces, which would make the implementation of HMAC easier.
I'm going to recommend we adapt https://github.com/h5p9sl/hmac_sha256 to our needs. I'll work on that a bit.
Also, I couldn't find any evidence of any cryptanalysis of encrypting the sha256 output with AES. Sometimes those things work, sometimes you get surprising results. Since the HMAC approach is well known and heavily analyzed, that would seem a better approach.
-corey - AE5KM
On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
I did not implement it yet. It would go in Command task.c and replace or perhaps duplicate the authenticate function.
Feel free to code it.
I don't know if we will ultimately go this way. I would still like to make the AES authentication work but I agree this could be simpler and faster. So it would be good to test it.
Chris
On Fri, Sept 15, 2023, 11:20 Corey Minyard minyard@acm.org wrote:
On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Ok, thanks for that Corey. Very interesting. We may not be susceptible to the length extension attack vulnerability though. If I understand correctly, then a message sent as: Hash( key + "Watch the enemy") could be manipulated to Hash(key + "Watch the enemy and attack them after 5 mins"), without knowing the key. But our commands are fixed at 18 bytes length (for now at least). So any extra appended message would be ignored. With that said, it may not be much harder to implement the scheme as described.
Yes, I was more worried about the "various security papers have suggested vulnerabilities with this approach" comment in the article on the key || message || key approach. It probably means there are other issues with the approach, possibly key extraction attacks. The HMAC approach seems generally more cryptographically sound.
I was going to say that I could implement it, though it's pretty trivial. You've probably already done it :).
-corey - AE5KM
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
Sounds very good. I will try to have a look at it tomorrow or Monday.
73 Chris
On Sat, Sept 16, 2023, 15:53 Corey Minyard minyard@acm.org wrote:
On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Just for reference, the sha.c algorithm did match what I get from Java
with the standard sha-256 digest. So it does work for the 18 bytes of our commands. But it sounds like it will not work if we append the secret key twice.
Yes, my impetus for replacing it, plus the new algorithm allows partial adds of data to make the process easier.
I have pushed up an update-sha-hmac branch that reworks all the keying. It uses the hmac-sha256 algorithm for authentication, it adds the code to load the key from NVRAM, and reworks the keysize to be 32 bytes. Reworking the key size will rearrange NVRAM, unfortunately. With this, you should be able to add a key from the command line and have it write it to NVRAM, and use it for the hmac-sha256 authentication. It does remove the AES code.
-corey - AE5KM
73 Chris
On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev <
pacsat-dev@amsat.org> wrote:
I just pulled Authenticate/src/sha.c out of the code and moved it into a separate file and played with it a bit. It wasn't matching the results from sha256sum, and looking at the code, I realized that the implementation only accepts up to 64 bytes of data. It works for buffers less than 64 bytes. It also won't do partial pieces, which would make the implementation of HMAC easier.
I'm going to recommend we adapt https://github.com/h5p9sl/hmac_sha256 to our needs. I'll work on that a bit.
Also, I couldn't find any evidence of any cryptanalysis of encrypting the sha256 output with AES. Sometimes those things work, sometimes you get surprising results. Since the HMAC approach is well known and heavily analyzed, that would seem a better approach.
-corey - AE5KM
On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
I did not implement it yet. It would go in Command task.c and
replace or perhaps duplicate the authenticate function.
Feel free to code it.
I don't know if we will ultimately go this way. I would still like
to make the AES authentication work but I agree this could be simpler and faster. So it would be good to test it.
Chris
On Fri, Sept 15, 2023, 11:20 Corey Minyard minyard@acm.org wrote:
On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev pacsat-dev@amsat.org wrote:
Ok, thanks for that Corey. Very interesting. We may not be
susceptible to the length extension attack vulnerability though. If I understand correctly, then a message sent as: Hash( key + "Watch the enemy") could be manipulated to Hash(key + "Watch the enemy and attack them after 5 mins"), without knowing the key. But our commands are fixed at 18 bytes length (for now at least). So any extra appended message would be ignored. With that said, it may not be much harder to implement the scheme as described.
Yes, I was more worried about the "various security papers have suggested vulnerabilities with this approach" comment in the article on the key || message || key approach. It probably means there are other issues with the approach, possibly key extraction attacks. The HMAC approach seems generally more cryptographically sound.
I was going to say that I could implement it, though it's pretty trivial. You've probably already done it :).
-corey - AE5KM
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at
participants (2)
-
Chris Thompson -
Corey Minyard