Email Detail
Show an email
GET /hyperkitty/api/list/[email protected]/email/4PQD6RNGTYUJEFVDABTNDKESD3SPA36V/
{ "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/4PQD6RNGTYUJEFVDABTNDKESD3SPA36V/", "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/", "message_id": "[email protected]", "message_id_hash": "4PQD6RNGTYUJEFVDABTNDKESD3SPA36V", "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/4PQD6RNGTYUJEFVDABTNDKESD3SPA36V/", "sender": { "address": "minyard (a) acm.org", "mailman_id": "59a713764a2e4ccabdcfd85f5b213a94", "emails": "https://mailman.amsat.org/hyperkitty/api/sender/59a713764a2e4ccabdcfd85f5b213a94/emails/" }, "sender_name": "Corey Minyard", "subject": "[pacsat-dev] Re: Using SHA256 for authentication", "date": "2023-09-19T18:18:54Z", "parent": null, "children": [], "votes": { "likes": 0, "dislikes": 0, "status": "neutral" }, "content": "On Tue, Sep 19, 2023 at 05:58:23PM +0000, Chris Thompson via pacsat-dev wrote:\n> Corey, I was delayed by another bug but managed to look at this today. It\n> looks very good.\n> \n> I can calculate the same hash value with the default key using the Java Mac\n> class and the HmacSHA256 algorithm. So that is great. It uses the public\n> algorithm.\n> \n> I did notice that the default key in the code you implemented is 28 bytes\n> and not 32 bytes as you stated in an earlier email. Is that correct? It\n> works with the 28 byte key.\n\nOops, that was an off-by-one bug in my brain. It will still work, it\nwill just be padded with zeros at the end. It's better to add the four\nextra bytes.\n\n> \n> One other thing. The existing code prevents a replay attack by sending the\n> reset/uptime on the spacecraft in the command. We have to send the same\n> reset and an uptime that is the same or no more than 300 seconds after the\n> actual uptime on the spacecraft. I think this could cause issues with an\n> unresponsive spacecraft where we don't know the time onboard. I'm sure that\n> is why there is a special command that goes around the requirement and\n> turns it off.\n> \n> I would instead propose we send a serial number in the command, with no\n> other meaning. Any command can only be used once and we store the highest\n> serial number used so far. The serial number would be in the hash of the\n> command of course. To make it easy to sync the serial numbers across\n> different command stations I propose that the serial number be unix time in\n> UTC, or the time based on a later epoch if we want something with less than\n> 32 bits. It will just be treated as a serial number that is checked for\n> duplicates when received at the spacecraft. Specifically all commands must\n> have a serial number greater than the largest one received so far.\n\nUsing current epoch as the serial number would be an excellent idea.\nAll it has to be is non-reusable and increasing.\n\nIt will cause a problem on January 2038 when the epoch rolls over.\nHowever, if you used an unsigned 32-bit integer and calculated it from\na 64-bit epoch, you get another 70 years beyond that. Or you could do\nyou own epoch from spacecraft launch time.\n\n-corey\n\n> \n> Maybe that is not secure enough. Let me know.\n> \n> 73\n> Chris\n> \n> \n> On Sat, Sep 16, 2023 at 6:56 PM Chris Thompson via pacsat-dev <\n> [email protected]> wrote:\n> \n> > Sounds very good. I will try to have a look at it tomorrow or Monday.\n> >\n> > 73\n> > Chris\n> >\n> > On Sat, Sept 16, 2023, 15:53 Corey Minyard <[email protected]> wrote:\n> >\n> >> On Sat, Sep 16, 2023 at 1:58 PM Chris Thompson via pacsat-dev\n> >> <[email protected]> wrote:\n> >> >\n> >> > Just for reference, the sha.c algorithm did match what I get from Java\n> >> with the standard sha-256 digest. So it does work for the 18 bytes of our\n> >> commands. But it sounds like it will not work if we append the secret key\n> >> twice.\n> >>\n> >> Yes, my impetus for replacing it, plus the new algorithm allows\n> >> partial adds of data to make the process easier.\n> >>\n> >> I have pushed up an update-sha-hmac branch that reworks all the\n> >> keying. It uses the hmac-sha256 algorithm for authentication, it adds\n> >> the code to load the key from NVRAM, and reworks the keysize to be 32\n> >> bytes. Reworking the key size will rearrange NVRAM, unfortunately.\n> >> With this, you should be able to add a key from the command line and\n> >> have it write it to NVRAM, and use it for the hmac-sha256\n> >> authentication. It does remove the AES code.\n> >>\n> >> -corey - AE5KM\n> >>\n> >> >\n> >> > 73\n> >> > Chris\n> >> >\n> >> > On Sat, Sept 16, 2023, 12:49 Corey Minyard via pacsat-dev <\n> >> [email protected]> wrote:\n> >> >>\n> >> >> I just pulled Authenticate/src/sha.c out of the code and moved it into\n> >> >> a separate file and played with it a bit. It wasn't matching the\n> >> >> results from sha256sum, and looking at the code, I realized that the\n> >> >> implementation only accepts up to 64 bytes of data. It works for\n> >> >> buffers less than 64 bytes. It also won't do partial pieces, which\n> >> >> would make the implementation of HMAC easier.\n> >> >>\n> >> >> I'm going to recommend we adapt https://github.com/h5p9sl/hmac_sha256\n> >> >> to our needs. I'll work on that a bit.\n> >> >>\n> >> >> Also, I couldn't find any evidence of any cryptanalysis of encrypting\n> >> >> the sha256 output with AES. Sometimes those things work, sometimes\n> >> >> you get surprising results. Since the HMAC approach is well known and\n> >> >> heavily analyzed, that would seem a better approach.\n> >> >>\n> >> >> -corey - AE5KM\n> >> >>\n> >> >> On Fri, Sep 15, 2023 at 1:21 PM Chris Thompson via pacsat-dev\n> >> >> <[email protected]> wrote:\n> >> >> >\n> >> >> > I did not implement it yet. It would go in Command task.c and\n> >> replace or perhaps duplicate the authenticate function.\n> >> >> >\n> >> >> > Feel free to code it.\n> >> >> >\n> >> >> > I don't know if we will ultimately go this way. I would still like\n> >> to make the AES authentication work but I agree this could be simpler and\n> >> faster. So it would be good to test it.\n> >> >> >\n> >> >> > Chris\n> >> >> >\n> >> >> > On Fri, Sept 15, 2023, 11:20 Corey Minyard <[email protected]> wrote:\n> >> >> >>\n> >> >> >> On Fri, Sep 15, 2023 at 10:06 AM Chris Thompson via pacsat-dev\n> >> >> >> <[email protected]> wrote:\n> >> >> >> >\n> >> >> >> > Ok, thanks for that Corey. Very interesting. We may not be\n> >> susceptible to the length extension attack vulnerability though. If I\n> >> understand correctly, then a message sent as: Hash( key + \"Watch the\n> >> enemy\") could be manipulated to Hash(key + \"Watch the enemy and attack them\n> >> after 5 mins\"), without knowing the key. But our commands are fixed at 18\n> >> bytes length (for now at least). So any extra appended message would be\n> >> ignored. With that said, it may not be much harder to implement the scheme\n> >> as described.\n> >> >> >>\n> >> >> >> Yes, I was more worried about the \"various security papers have\n> >> >> >> suggested vulnerabilities with this approach\" comment in the article\n> >> >> >> on the key || message || key approach. It probably means there are\n> >> >> >> other issues with the approach, possibly key extraction attacks.\n> >> The\n> >> >> >> HMAC approach seems generally more cryptographically sound.\n> >> >> >>\n> >> >> >> I was going to say that I could implement it, though it's pretty\n> >> >> >> trivial. You've probably already done it :).\n> >> >> >>\n> >> >> >> -corey - AE5KM\n> >> >> >\n> >> >> >\n> >> >> > -----------------------------------------------------------\n> >> >> >\n> >> >> > pacsat-dev mailing list -- [email protected]\n> >> >> > View archives of this mailing list at\n> >> https://mailman.amsat.org/hyperkitty/list/[email protected]\n> >> >> > To unsubscribe send an email to [email protected]\n> >> >> > Manage all of your AMSAT-NA mailing list preferences at\n> >> https://mailman.amsat.org\n> >> >>\n> >> >> -----------------------------------------------------------\n> >> >>\n> >> >> pacsat-dev mailing list -- [email protected]\n> >> >> View archives of this mailing list at\n> >> https://mailman.amsat.org/hyperkitty/list/[email protected]\n> >> >> To unsubscribe send an email to [email protected]\n> >> >> Manage all of your AMSAT-NA mailing list preferences at\n> >> https://mailman.amsat.org\n> >> >\n> >> >\n> >> > -----------------------------------------------------------\n> >> >\n> >> > pacsat-dev mailing list -- [email protected]\n> >> > View archives of this mailing list at\n> >> https://mailman.amsat.org/hyperkitty/list/[email protected]\n> >> > To unsubscribe send an email to [email protected]\n> >> > Manage all of your AMSAT-NA mailing list preferences at\n> >> https://mailman.amsat.org\n> >>\n> >\n> > -----------------------------------------------------------\n> >\n> > pacsat-dev mailing list -- [email protected]\n> > View archives of this mailing list at\n> > https://mailman.amsat.org/hyperkitty/list/[email protected]\n> > To unsubscribe send an email to [email protected]\n> > Manage all of your AMSAT-NA mailing list preferences at\n> > https://mailman.amsat.org\n> >\n> \n> \n> -- \n> Chris E. Thompson\n> [email protected]\n> [email protected]\n\n> \n> -----------------------------------------------------------\n> \n> pacsat-dev mailing list -- [email protected]\n> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]\n> To unsubscribe send an email to [email protected]\n> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org\n\n", "attachments": [] }