Thanks for the report. AES can fail for a few different reasons, so I need a bit more detail before calling it a Windows bug.
Please do not post the actual key publicly. Can you share:
1. The exact DSD-neo version or ZIP name you’re running.
2. Which protocol this is: DMR, P25 Phase 1/2, or NXDN.
3. The encrypted call log line showing ALG ID, Key ID, and MI, with any sensitive values redacted.
4. The command line you used, with the key replaced by XXXXX.
5. Whether DSD-neo prints “AES-128 key loaded”, “AES-256 key loaded”, or “Key: [redacted]” during the call.
On Windows Command Prompt, single quotes do not work like they do on Linux. If you are using `-H` with spaces, use double quotes or remove the spaces:
`dsd-neo.exe ... -H "736B9A9C5645288B 243AD5CB8701EF8A"`
or:
`dsd-neo.exe ... -H 736B9A9C5645288B243AD5CB8701EF8A`
For a 256-bit AES key, DSD-neo expects 64 hex characters. For a key file with `-K`, the CSV needs a header and the key split into 64-bit hex segments, for example:
`keyid(hex),value0,value1,value2,value3`
Also, “AES” depends on the mode. P25 AES ALG IDs like `0x84` / `0x89`, DMR AES `0x24` / `0x25`, NXDN cipher `3`, and vendor modes like TYT Enhanced Privacy are handled differently, so the ALG ID from the log matters.