Known-plaintext attack might be possible then, although there are ways to mitigate that.
slowdoorsemillc · 21m ago
Current signature verification: Calculate hash of known operating system image, decrypt digital signature with public key (known because it's public) which is a hash encrypted with private key, compare calculated hash with decrypted hash, boot if equal.
That's like saying "I know the hash value and operating system image encrypted and decrypted so I can deduce the private key."
If the current signature verification algorithms aren't subject to known plaintext attacks (but are to hash collision attacks) then my algorithm isn't subject to known plaintext attacks and isn't subject to hash collisions.
The only thing hidden in current signature verification is the private key (intended for signing) and my idea for a mitigation also keeps the private key private (intended for signing.)
zzo38computer · 10m ago
OK, although I was thinking that an entire file might be encrypted and that you would have multiple blocks, because your description was unclear to me. Digital signatures do use padding, although it is not that simple.
slowdoorsemillc · 7m ago
Yes, the entire file would be encrypted but with the private key after adding, say, 2048 bits of all 0's to the beginning of the file. After decrypting the whole file, check if the first 2048 bits are all 0's. If they are, good, boot. It can be brute forced, but with 1 in 2^2048 probability of guessing right.
That's like saying "I know the hash value and operating system image encrypted and decrypted so I can deduce the private key."
If the current signature verification algorithms aren't subject to known plaintext attacks (but are to hash collision attacks) then my algorithm isn't subject to known plaintext attacks and isn't subject to hash collisions.
The only thing hidden in current signature verification is the private key (intended for signing) and my idea for a mitigation also keeps the private key private (intended for signing.)