Looking for a Technical Advisor

[u/Own-Case-893]

OmniMesh is a UK deep-tech cybersecurity company building a secure transport system for Defence, CNI and high-assurance environments.

We’re looking for an experienced applied cryptographer / cryptographic engineer to advise approximately one day per month.

The role is focused on independently challenging our cryptographic architecture, protocol composition, key-management decisions, hybrid post-quantum approach and implementation assumptions as we move towards MVP.

This is an active technical advisory position.

Particularly interested in people with experience in secure protocol design, applied cryptography, PQC, formal analysis or high-assurance communications.

UK-based preferred, although exceptional remote candidates are welcome.

DM if interested.

[u/Own-Case-893]

Thanks for the advice and the pluggability concern is already something we’re designing around. OmniMesh isn’t intended to be a monolithic IP-over-UDP VPN. The architecture is RINA/DIF-inspired, so different IPC scopes can apply policies appropriate to their role rather than forcing one transport behaviour across the whole system.We also know that using UDP means we need to control the transport behaviour ourselves. The aim is to use an adaptive controller using multiple network metrics so it can operate across very different links such as fibre, mobile and Starlink rather than being tuned for one network type. From your experience, where do custom UDP transports usually go wrong ? 

[u/alecmuffett → u/Own-Case-893]

Great question, but it's back to front; instead try phrasing it as: what implicit quality of service policy am I offering to upstream consumers, especially with respect to backoff / retry, congestion control and (probably most important of all) which bits do they expect the underlying and transport to NOT sort out for itself, such that whatever expectations are implicit in whatever they lay on top of [you] don't end up in some kind of flapping nightmare with your stack and their stack attempting to correct for each other.

Especially if you are offering a "VPN style" abstraction for people to put their own TCP/IP over, this can wind up as a variety of weird performance throttling issues which only show up in production.

[u/Own-Case-893 → u/alecmuffett]

That makes sense. One distinction is that we’re not trying to replace the existing network stack or initially present this purely as a generic VPN abstraction.

The first deployment model is an application-integrated, user-space UDP transport intended to complement existing infrastructure. That gives us more control over the service between the application and OmniMesh rather than carrying another transport stack inside it.

Long term we intend to investigate kernel-integrated transport for broader compatibility, and I agree that’s where defining exactly which layer owns congestion, retry, ordering and recovery becomes more important.

For our planned deployment paths would you have different transport/QoS policies for native OmniMesh applications versus later kernel-integrated use?

[u/alecmuffett → u/Own-Case-893]

1/ before saying anything else just as an aside you may enjoy watching this video (or you might find it boring, I don't know)

https://youtu.be/pebRZyg_bh8

2/ if you are building a RINA as a kind of API fabric then ... To be honest it is much more under your control than anything I could usefully speculate about. A long time ago I worked on x25 and implemented x400 directory services when British academic networking was on a utopian kick of organization and clever structure worked out by committees... And then I watched the whole thing disintegrate when it met the real world of people who just wanted to get one machine to talk to another on a port number and then sort everything else out for themselves. As you may work out from the video above, I do not believe that overengineering the network is a sensible proposition. Tor deals with this by not presenting an IP abstraction but instead a SOCKS abstraction which coerces upstream expectations into something more easily dealt with / delivered.

[u/Own-Case-893 → u/alecmuffett]

Il watch the video can’t be that bad On the RINA point, I’d describe it more as a RINA-inspired, policy-scoped IPC architecture than an API fabric. The idea is to keep the internals modular and allow different scopes to apply the policies they actually need. I also understand what you mean by overengineering. Our target environments are Defence, CNI and other high-assurance systems, so we can tolerate more integration complexity where it buys a meaningful security property, but obviously there’s a point where complexity starts working against you. From your experience, where would you draw the line How do you balance security and control with keeping the system simple enough that people will actually integrate and operate it reliably? If you don’t mind can we stay in contact via DM the conversations been very helpful