felsokning

I think you're conflating two precepts. Just because you can write an exploit, it doesn't - inherently - mean that you have the skills/knowledge/tools of where to look for all signs of exploit having occurred on your device(s).

From the inference of that logic, every developer should be able to use gdb or Windbg to ascertain where they shot themselves in the foot - but we know that this specific set of skills isn't inherently required to be a developer.

So, the same logic would be true here: Just because you can write a hand full of exploits, it doesn't inherently mean that you have the tools/know-how to be able to ascertain if any of all of the available exploits in the wild (or in private, re: tools for Trenchat) have been used on your phone.

Edit: gbd != gdb

> If you and I had been introduced, you would have a [email protected] designating me in your address book, and I would have a [email protected] for your address in my address book.

The description, here, is no different than S/MIME encryption exchange - in that the guid exchange has to be done before it could be used.

You still have the issue of [A]Guid and [C]Guid correlating between themselves _and_ it being "unique" per SMTP session (after all, you said before that each guid has to be unique per session). This is where my earlier reference to generated guids being exchanged during the SMTP session comes into play. However, leaving that aside...

A single-use guid is no different than an SMTP address, if we're going based on the single guid inferred from that line -- and that guid has to be stored elsewhere in your system for it to be resolved to a recipient. So, you need something like a guid history array on the object for the forest to be able to resolve that guid (on recipient resolve) to a mail object inside your forest.

You have no mechanism (from your description) for B sending to [A]Guid or [C]Guid junk mail (assuming they've been able to discover the guids) using those guids. You say you would invalidate [A]Guid or [C]Guid -- but this doesn't resolve the issue of [A] and [C] now having to re-exchange Guids, for something that B has done.

So, now, all valid email between [A]Guid and [C]Guid is invalidated (per your description) and they're calling into your helpdesk, trying to understand why valid email isn't being delivered.

Do you tell them to re-exchange guids? How do they re-exchange guids when the mail system is dependent (directly) on those guids already being established on both sides? How do they "re-introduce" themselves, in other words, in that scenario?

> ...the idea here is that every entity gets their own guid designating you, so the same guid is not known by more than one entity

Ok, now you're sending a list of guids that _can_ be emailed to, per negotiation? Otherwise, how are they sending to that specific guid? A guid is not a hash of an object but an identifier object (a 16-byte array, if I recall correctly) - it has to map to the recipient _somehow_.

In other words, in each SMTP exchange, that information would have to be stored in some form of look-up table, _somewhere_, on both the sending and receiving servers.

How do you enforce the senders destroying that table, so that many versions of it don't expose your half of the signature? Do you generate a new key per session? If so, where are you storing that key, in memory? How would you prevent the heap from exposing those keys in a process crash (say, where a dump is automatically generated - like in Windows)? How do you prevent a nefarious actor using A, B, or C from generating a flood of SMTP sessions and creating a tonne (yes, the metric kind) of these look-up tables in memory? What happens when back-pressure is hit? Do you force everything else to paging but keep the tables in memory?

They don't give any numbers on the amount of resistances to the expansion of the infrastructure, based on noise alone.

This reads like a "we did a cool thing" but without qualitatively demonstrating the merits for the need.

> What's your problem?

No problem. Why the hostility?

> You selectively quoted a fraction of my statement and threw in a strawman.

I disagreed with the first part of your statement and agreed with the second part. Are you only reading to respond and not to comprehend? Also, how are studies or facts "a strawman".

What does dealing with those 4 things have to do with your initial gross oversimplification?

> ...it will temporarily interrupt the current CPU execution process...

If you unwind the stack (say in a debugger), you'll find that there's no "interruption" occurring.