r/cryptography • u/Own-Case-893 • 1d ago

Looking for a Technical Advisor

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.

0 Upvotes

31% Upvoted

10 comments sorted by

8

u/alecmuffett 1d ago

Basically according to LinkedIn you are trying to implement a mixnet in Rust over UDP.

Personally, I would call that a brave value proposition, especially given the entrenchment of solutions like Tor and their haphazard adoption.

Quote follows:

Encryption protects content, but communications still expose operationally valuable metadata: who is communicating, when, how frequently, through which infrastructure, and how systems behave under changing network conditions. Under sustained observation, those signals can contribute to communication-graph inference, topology discovery, endpoint profiling and traffic correlation. OmniMesh is being designed around that problem from the transport layer upwards rather than treating metadata exposure as an application-layer add-on.

The architecture is being developed as a user-space, UDP-based secure transport system in Rust, with work spanning multipath transport, cryptography, traffic-shaping and mixing mechanisms, identity and admission, resilient routing, NAT traversal and operation across hostile or degraded networks.

The objective is not to claim that metadata can simply be made invisible. It is to make inference materially harder, constrain the information exposed by the transport system, and build those properties into the architecture from the outset.

We are currently completing the subsystem protocol specifications and threat-modelled architecture before progressing further into implementation and adversarial validation. A POC has already been developed and successfully validated, alongside technical research covering the underlying threat model and transport-layer metadata problem.

1

u/Own-Case-893 1d ago

Yes , but it’s more than implementing a mixnet in Rust over UDP. We’re designing the architecture across the transport as a whole routing, multipath, cryptography, identity/admission, resilience, traffic behaviour and metadata protection are being designed together rather than bolted onto an existing transport. We’re also researching a separate privacy/anonymity mechanism aimed specifically at making some of the principles behind mixnets practical for operational traffic. One area we’re researching is micro-latency combined with dynamically generated decoy traffic across multiple paths, rather than accepting latency penalties traditionally associated with strong traffic-analysis resistance. It’s still research at this stage, so I don’t want to overstate what it can achieve, but the goal is definitely not to recreate Tor. The interesting problem for us is whether strong metadata protection can be made practical as an integrated property of a general secure transport.

3

u/alecmuffett 1d ago

Curiously, I have worked in both of these spaces (no, I am not angling for the job, I am far too busy being a parent and anyway you couldn't afford me) but if I could make one piece of advice up front: make sure you have a plug-able architecture because otherwise if you try to make this tool monolithic it will bite you really hard.

Also, coming from Sun Microsystems and being deeply aware of both nfsv4 and VPN architecture: UDP is a brave choice because as soon as you start putting TCP over it you are going to be exposing a whole pile of latency and backoff and retry treatment to your application clients, OR ELSE you will basically be reimplementing the circuit management aspects of TCP itself. I understand the hypothetical appeal of "IP is just datagrams, right , so of course we can just implement a VPN over UDP and expect everything to work because that is datagrams too!" — but I can promise you now that it doesn't work out like that.

2

u/Own-Case-893 1d ago

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 ? 

3

u/alecmuffett 1d ago

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.

2

u/Own-Case-893 1d ago

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?

3

u/alecmuffett 1d ago

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.

1

u/Own-Case-893 1d ago

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 

2

u/tenoun 1d ago

Looks like AI slap/slop crap company established by a student ! For me it's just a honeypot!

-2

u/Own-Case-893 1d ago

AI slop crap company that already has a small experienced team , many senior cyber experts we spoke to are interested in the technical approach and the innovation of many techniques never used in the way we are applying  . Senior systems engineer with over 20 years experience completed an initial external review of our architecture with very good feedback also and much more progress has been made . Reddit is a funny place tbf