Re: Using SHA256 for authentication
Why don't you talk to Heimir. I still think we should try to re-use as much code as possible, in particular AMCOM. Heimir can figure out how AMCOM does it. I don't object to changing it for Golf for that matter, except that it is getting later and later and there will soon be a lot more software requirements.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Sep 15, 2023 at 2: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
If the Amcom code can be opened up and shared that would be great. Even if it is just the routine that creates the digest and encrypts it.
I don't know Heimir. Can you introduce us?
73 Chris
On Fri, Sept 15, 2023, 21:58 Burns Fisher (AMSAT) wb1fj@fisher.cc wrote:
Why don't you talk to Heimir. I still think we should try to re-use as much code as possible, in particular AMCOM. Heimir can figure out how AMCOM does it. I don't object to changing it for Golf for that matter, except that it is getting later and later and there will soon be a lot more software requirements.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Sep 15, 2023 at 2: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
participants (2)
-
Burns Fisher (AMSAT) -
Chris Thompson