Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/PMJ7PKZ2VZO7LUVPOQTKGEYRVMVSP5ZT/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "CADq4U7KkeJUTbz7_6J9gvUuNKEqaj+kCqKQ7h71abZePX-Npfw@mail.gmail.com",
    "message_id_hash": "PMJ7PKZ2VZO7LUVPOQTKGEYRVMVSP5ZT",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/PMJ7PKZ2VZO7LUVPOQTKGEYRVMVSP5ZT/",
    "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-16T16:48:47Z",
    "parent": null,
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "I just pulled Authenticate/src/sha.c out of the code and moved it into\na separate file and played with it a bit.  It wasn't matching the\nresults from sha256sum, and looking at the code, I realized that the\nimplementation only accepts up to 64 bytes of data.  It works for\nbuffers less than 64 bytes.  It also won't do partial pieces, which\nwould make the implementation of HMAC easier.\n\nI'm going to recommend we adapt https://github.com/h5p9sl/hmac_sha256\nto our needs.  I'll work on that a bit.\n\nAlso, I couldn't find any evidence of any cryptanalysis of encrypting\nthe sha256 output with AES.  Sometimes those things work, sometimes\nyou get surprising results. Since the HMAC approach is well known and\nheavily analyzed, that would seem a better approach.\n\n-corey - AE5KM\n\nOn 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 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 to make the AES authentication work but I agree this could be simpler and 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 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.\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.  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 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",
    "attachments": []
}