AW: Hiding signature identification (was: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")

[Fiedler Roman]

> Von: Peter Lebbing [mailto:peter at digitalbrains.com]
> 
> On 05/09/18 11:27, Fiedler Roman wrote:
> > Sorry, but you are completely off here.
> 
> If there are six people I am actually interested in, and I know all
> their public keys,

How will you know them? I will not tell you the keys, nor publish
them. You will have to steal them or wait for GPG leaking information
about them. The later risk is what I want to prevent ...

> checking if one of them signed a message with a
> hypothetical "throw-keyid" takes me at most six trial verifications,
> using their public keys in turn.

Nope, because as stated by Werner: signature verification in sign
AND encrypt schemes is not possible without decrypting the message.
And each message WILL BE encrypted, the sender and receiver key
will be stored in a HSM in the end. So I could not even give you a
copy of the private key to perform the decryption/signature
verification, even if I wanted to.

And to make it harder for you to figure out, which HSM to steal if
you want to decrypt a given message, the messages must not give
you any clue about the sender/receiver.
 
> Now when you say that you could find the signer by brute-forcing "all
> keys in the 2^2048 key space", that seems to miss a vital step. Let's
> suppose you did this massive brute force, the universe still exists, and
> you found that the RSA key with keygrip
> 8FE036329129F568D5B58A88F6F8580A064E4887 has signed the message.
> Back to your goal. Who signed the message? You don't know. You know what the RSA
> modulus of the key of this person is, but you don't know their identity,
> because your brute-force search did not produce an identity, it produced
> an RSA modulus and exponent.

But now I can go through my archive of intercepted messages, where I usually
know, where I intercepted them, e.g. at the hacked switch of company X.
I will check the timestamps of the messages, try to figure out the originators
working hours, check with my surveillance cameras from the other side of
the street pointing at the company X parking lot until I am quite sure, which
car and hence which person is related to activity with a given key.

As soon as I have that information, I guess 40kUSD should be sufficient
to have child, wife, whatsoever kidnapped to make the employee turn
me over the HSM with his private key plus the HSM password or decrypt
messages for me in case of stationary HSMs - thus breaking an "unbreakable"
cryptosystem with quite little amount of money (the kidnapping and one
year of switch-cyberop plus passive surveillance operation on the parking
lot) compared to really factorizing moduli or exploiting crypto software/
hardware bugs.

Maybe some criminals or secret services know better ways to perform
that task, maybe such operation is much more complicated than I
currently envision. At least by best practice use of cryptosystems, I
do not want to make them even think about such a scheme to begin
with.

> So: to know who signed a message, you need their public key. 

... and the receiver private key for sign AND encrypt schemes ...

> So to check
> a random signature without identification, you try all the public keys
> you have at your disposal (perhaps ignoring the ones you know are
> uninteresting). So your search space is your collection of public keys.

The crypto design is done in such a way, so that there is NO easily accessible
collection of public keys. I am even trying to extend it in a way, that even
have a plaintext list of all relevant remote party public keys - they only can
locate a remote party key after receiving a message and decrypting it without
verification to do the verification in a second step (that's why my attempt
to verify an encrypted message) before crafting a response, encrypting it
with the now known public key and forgetting about the key until the next
message is received.

So without massive theft of multiple physical components plus an intercept
of a significant amount of messages, access to the private keys, there is NO
WAY to gain any information about the set of used public or private keys.

Regards,
Roman