Closed DJ2LS closed 11 months ago
We could go one step further and use PKI. We could allow users to exchange public keys (even provide a way to allow users to upload their public keys somewhere the client could download them). Then when sending a message we hash the message, encrypt the hash with our private key. On receive client could decrypt the hash with our public key, and verify unecncrypted hash. This would also provide a means of verifying remote delete requests in issue #364
But how to verify, a user is the right one behind a callsign? We would still need a key which is exchanged on 2nd communication way, I think. We also should keep hash lengths in mind because of message overhead.
Update: Ah, sorry, didnt read your message correctly! Yes, this could work. Need to think about it.
Using HMAC MD5
let CryptoJS = require("crypto-js");
let message = "MESSAGE MESSAGE MESSAGE MESSAGE MESSAGE MESSAGE MESSAGE MESSAGE MESSAGE"
let secret = "1234567890"
let hash = CryptoJS.HmacMD5(message, secret)
let hex = CryptoJS.enc.Hex.stringify(hash);
console.log(hex)
hex = CryptoJS.enc.Base64.stringify(hash);
console.log(hex.length)
let ascii = Buffer.from(hex, 'base64').toString()
console.log(ascii)
console.log(ascii.length)
results in a 32byte hex string or 16bytes ascii
@Mashintime @LA3QMA
if we are introducing this on TNC level, it might perform better for headless operation. Any suggestions?
Idea: Adding an additional file with signatures. On ISS: If signature is available for a destination callsign, message will be signed. On IRS: Received data with signature will be checked against own signature If signature is correct, we will set "signed flag" to true, other its "false".
Idea: We are already using a crc32, which will be sent with every message. https://github.com/DJ2LS/FreeDATA/blob/0f1ab974443efb7785e673f413ef8cb9db5bb340/tnc/data_handler.py#L1207
It will be then checked on IRS. https://github.com/DJ2LS/FreeDATA/blob/0f1ab974443efb7785e673f413ef8cb9db5bb340/tnc/data_handler.py#L916C1-L916C1
We can use the crc field for sending the signature instead. On IRS we have to implement a 2-Stage check for the signature/checksum.
We should sign messages by a shared secret cipher.
I was thinking about https://en.wikipedia.org/wiki/HMAC
Using this library crypto-js and maybe a reduced hash length.
On IRS we are calculating the hash on received data by using its secret key, exchanged on a different path, maybe phone or email. Means we have to save the shared key in user database I think.