Most Requested Fresh Identification Protocol

[josh]

A side implementation point:

It might be convenient to use some true/false or multiple choice Qs where their is work to put the syntactic form of the question in a way that doesn’t leak bias for the id verification context. It might make sense then to use NLP AI & random coin flips to create uninformative syntax from the original Q.

[josh]

Well suprise suprise

— Whiskyfett (@Whiskyfett2) September 2, 2022

[josh]

The utility function of the MITM attacker may be such that they would rather draw high suspicion as a saboteur b4 allowing a secure channel. To that end, they may introduce a lot of extra malicious delay & bit rot. It’s probably worth some coping with that using a mix of practical strategies, like:
‘
a) show state of previous comprehension up front, b4 extra work/bits
b) some bits of sub-section ERC/resend protocol capability.

[josh]

I keep scratching my head about the GT situations to bridge needs & practical algorithms.

We can say that Deep State w/BOD can be very powerful. If an isolated person only sees MITM fakes with no side info then then the ability to notice that is more an issue of psychology/common sense reasonsing than crypto.

In crypto PKI, we assume that public keys are reliably broadcast & kept safe. That req can be hard to meet in practice. But without a hard to fake secret, the protocol becomes tricky to say where the Type1/Type2 rejection should be given the ability to mimic a bad line in both cases & supply correct answers from the MITM in both cases.

Secure hardware dongle type solutions/biometrics is best where available. But for public key, we can make a less good but helpful version by finding a way to create distinctive icons for each user that function as a public key and don’t readily admit near look alikes.

The icons can then be shared in a helpful way.

[josh]

For example, something like this could be implemented:

A simple blockchain like algorithm for keeping a catalog of registered icons. The implementation imposes checks to prevent icons with a highly similar visual appearance, and can also associate public keys with icons.
Steganographically embedding the public key in a retrievable way in the icon itself is also possible. A unique salt could also be embedded alongside the public key & along with a digital signature for the public key plus salt – potentially allowing for a salt only or key plus salt revision at some later poin time.

Given such a structure, users can associate the visual appearance of a given icon with a given key holder/identity and expect that robust tests would detect the substitution of a near likeness that was not authorized by the blockchain catalog or the key holder.

[josh]

One way to implement that is to map icon of a given size to a predefined set of key hole bits that would contain the steganogrpahic encoding of public key, salt, and digital signature of a cryptographic hash of the public key + salt + all the non-keyhole bits of the image in sequence.

[josh]

What is the best way to define “looks similar”. Best is to look for a smooth multi-level warp (diffeomorphism) that attempts to align the image features and then score both the resulting match – e.g. using some sort of nomralized dot produts & the penalty significance of the warp itself.

Medical image registration literature has a lot of references to algorithms of this type that run on 3D scans. The 2D generic versions would run a lot faster.

[josh]

A smoother & less messy version of the “icons must be dissimilar idea” at the cost of using 2 icons.

Let the blockchain db store it’s own large set of distinctive pictures generated by it’s own algorithm. Now when the user submits their signed picture & public key, the database supplements it with a second icon – the database choice of the stored icon that is closest in some crypto hash space to the combination the signed first image & the public key. Now the user is represented by 2 side by side icons & it’s computationally infeasible for an adversary to find 2 similar matches that are okay by the protocol check.

[josh]

Q: If an adversary can see the full set of supplemental pictures, and they knew the hashing protocol used to generate a match could they feasibly create a similar first picture & public key that would yield the same second match, resulting in 2 similar icons with a different key?

A: I don’t see any way to iterate through the 2nd icon set. If they can keep bit twiddling the similar first image & public key & it isn’t too expensive to generate the output then they could brute force a similar pair by random trial & error. There’s no reason to publish the hidden arbitrary details of the hashing, so that could be kept a secret. This could still be true with blockchain style distributed registration.

[josh]

The secrecy required isn’t source code secrecy. Just as cryptographic libraries are published, this is the same. The secrecy is contained in the bits of a hidden string of sufficient length & obscurity.

[josh]

There is still the issue of preventing an automated process from brute force trial & error via the icon key submission process. It isn’t intended for that kind of usage, but some steps need to be taken to prevent it from happening in unattended mode. The basic issue is many tries from similar source with similar pictures. The vulnerability isn’t like robbing a wallet, but it would allow a dedicated attacker to create visual mimicry or confusion pairs for some sneaky usage.

[josh]

Good practice would probably be to keep recency logs of submissions indexed by measures of pattern/visual similarity & network source. Require throttling and/or less similar submissions.

[josh]

Thinking it over more, I like the extra control of a third icon that is chosen by administrative control various criteria & efficiency of process. One of the minor criteria can be something that adds to psychological saliency & mnemonics in juxtaposition of the other 2 icons.

[Author]

Posts