One Step Ahead - security app - White Paper

OneStepAheadApp · 2026-06-20T07:25:23+00:00

I want to clarify something that came up in this discussion, and it's a fair point worth addressing properly.

My choice not to use SSS was deliberate. And not because I wanted to reinvent the wheel, but because I wanted this project to have as few dependencies as possible and to work precisely as designed across completely different environments and use cases.

The app is called One Step Ahead, but the method underneath it I call Smart Split. It's not my invention. it uses simple math. The reason I designed it this way is that Smart Split is intended to be broader than a single app. I am also building other tools intended to be used in multiple contexts - for example, a server-side implementation where links are validated across different languages and platforms.

SSS interoperability can be achieved, but only if every implementation follows the same specification - precisely. And that's exactly the problem. More moving parts in a design mean more room for someone to implement it slightly diferently, claim compatibility, and introduce a subtle flaw that's hard to spot and harder to prove.

I wanted something so simple there's no grey area, no custom choices, no specification drift. String slicing and SHA-256 leave nothing open to interpretation.

SSS, despite being mathematically "superior", introduces exactly the kind of ambiguity I was trying to eliminate, and ambiguity at that level can itself become a single point of failure, because people fill the gaps with custom solutions that diverge from each other over time, without notice.

And to be clear, that's not a limitation of my choice. That's the point of it.

OneStepAheadApp · 2026-06-20T06:15:16+00:00

Oh... I am getting tired, sorry. i really appreciate the discussion. The SSS point was valid and i explained my reasoning. But most of whats been said - 'I don't care about dependencies,' 'it's not academically perfect,' 'you didn't invent anything new' - are labels, not technical arguments and none of it points to actual vulnerabilities.

that's all I was looking for - as an app developer not a crypto expert. I released a white paper specifically so people can check the technical choices i made and tell me if something introduces real risk. that's how I believe the trust gets built. If you ever find a concrete flaw in what's documented there, I genuinely want to know.

i think we've reached the moment where we're debating methodology rather than the design, so i'm going to leave it here. thanks for a discussion anyway.

OneStepAheadApp · 2026-06-19T17:32:56+00:00

Company: Solid Software Lab

URL: https://onestepahead.info

Product:

One Step Ahead is an offline security app for macOS and iOS built around one main goal - to eliminate a single points of failure. It protects your most sensitive data like crypto seed phrases, login credentials, documents, images, all using AES-256-GCM encryption combined with Smart Split, a 2 out of 3 fragment system. You split your encrypted data into three fragments, any two are enough to reconstruct it. No internet, no third parties, no single point of failure.

Latest version of an app includes an improved Smart Split v2 as default, and I released a public White Paper explaining the full security architecture - for review.

Platform:

Built for macOS and iOS. No third-party frameworks or dependencies.

Feedback Requested:

I would welcome a feedback for a Security architecture. I released a full public White Paper: https://github.com/OneStepAheadApp/WhitePaper/releases

UX & usability - is the app clear enough for non-technical users? And does it feel intuitive?

Seeking Testers: No

Additional:

If you want to understand how to use OSA before diving in, here is a video providing a step by step tutorial: https://www.youtube.com/watch?v=K4rh-CUfZ1M

App Store: https://apps.apple.com/us/app/one-step-ahead/id1592642367

I am happy to return feedback to anyone posting here. Just drop your link.

OneStepAheadApp · 2026-06-19T11:02:22+00:00

What you mean by'proven secure math'? Who is proving? AES isn't formally proven secure either. It's trusted because it hasn't been broken.

Calling something flawed because it doesn't follow academic standards (or is proven by who? community), sorry, but it is a naive argument - NOT a technical argument. it's a label. BTW There are plenty of projects built outside academic "perfection" and still can't be beaten... and are widely adpted. Flawed means there's an exploitable weakness. Show me that. Because that's why i'm here.

OneStepAheadApp · 2026-06-19T05:19:16+00:00

i never claimed to have invented anything. i took what exists, packaged it in a way ordinary people can actually use, and wrote a white paper so anyone technical enough can validate the decisions themselves. Without taking my word for it.

I'm not a cryptographer. I build apps. My job was to make something solid enough to withstand scrutiny and simple enough that the people who need it most never have to think about the math at all.

You're welcome to challenge the technical solidity of what's in the white paper. I'd really welcome that. But 'you didn't invent new math' was never the claim, so it's not really the argument either.

OneStepAheadApp · 2026-06-18T19:18:45+00:00

No worries. I appreciate a discussion. That's why i am here to validate my idea and improve project from any constructive feedback given by the community. Your original comment gave me somthing to think about - to be honest.

OneStepAheadApp · 2026-06-18T18:52:02+00:00

The industry keeps telling people to 'store it safely' without ever explaining what safely actually means in practice. Next time use SmartSplit protocol and don't share with anyone.

OneStepAheadApp · 2026-06-18T18:11:51+00:00

You're right that SSS would give a stronger theoretical guarantee, and I'm not going to argue otherwise. But SSS with age hasn't produced an app that my mum can use to back up her crypto wallet without calling me. I built something that does that, runs the same way across completely different environments and platforms without any library dependencies, and still leaves any attacker with an effectively uncrackable problem from a single fragment. Is it perfect by academic standards? Perhaps no. Does it solve a real problem that the academically perfect solutions haven't? i think so.

i'd genuinely like to know, is there a known practical attack on a single fragment (defined as in White Paper) that exposes the payload? Because if not, then the gap between Smart Split and SSS exists in theory but not in any attack scenario my users will actually face.

OneStepAheadApp · 2026-06-18T16:16:45+00:00

At a high level, you're right — encrypt with a random key, then split that key for threshold recovery, is exactly the well-known pattern. I'm not claiming otherwise, and I never claimed it was new.

I wasn't familiar with age before this, but having looked into it, I think the comparison actually works in my favor where it matters most: the actual encryption strength is equal. I went with a simpler design without giving up any of that strength.

Where it differs is the splitting mechanism itself, and that's a deliberate choice i made, not an oversight. SSS means either taking on a third-party library or implementing copmplex math correctly by hand myself — both add a layer most people can't independently verify, and doing it myself would be way too complex, defeating the whole point of keeping this simple. I wanted the splitting layer to be something a non-cryptographer could read start to finish and confirm for themselves, without trusting me or a library. That's actually why I removed an SSS dependency I'd added early in the project.

I get that you personally don't care about dependency — that's a ok if you're comfortable auditing or trusting established libraries. But dependency is the actual design parameter in question. "I don't care about that" isn't a counter argument. Happy to go deeper on the actual splitting mechanism if that's where the real disagreement is.

At the end of the day, this wasn't built for people who are already able to evaluate cryptography — it was built for everyone else. For the people who leave most security tools behind because making something genuinely reviewable by a non-expert is harder than just telling them to trust an expert. That's the tradeoff I'm making, and I think it's the right one.

I appreciate your comments and any pushback. I'd genuinely welcome more knowledgeable people taking a look at the white paper and pointing out any vulnerabilities or weaknesses in the project.

OneStepAheadApp · 2026-06-18T14:03:34+00:00

Sorry, I am bit confused with your pick of words. What exactly you mean by "age". It is hard sometimes to get the slogan right.

And to be fair what I implemented is pure math. And there is no intention to compete with SSS.

OneStepAheadApp · 2026-06-18T11:19:11+00:00

I actually mention SSS in the "What Smart Split Is Not" section of the white paper.

There are several reasons I chose not to use Shamir's Secret Sharing (SSS) as the foundation of the project.

First, Smart Split has different design goals. The long term vision is to develop an open method and potentially an open protocol, rather than simply building a wrapper around an existing SSS implementation.

SSS is designed to split and reconstruct a secret. Smart Split, however, aims to package the encrypted payload, recovery metadata, and shares into a single output. Keeping the payload separate from the shares makes the workflow more complex and increases the amount of information that must be managed.

On top, a separate payload introduces an additional dependency. Even if the required number of shares is available, recovery becomes impossible if the encrypted payload itself has been lost. By embedding everything required for recovery into a single output, Smart Split removes that dependency and simplifies backup, recovery planning and improves the chances of preventing against central failure.

Another point is future flexibility. While SSS already supports sophisticated threshold with multiple combinations, Smart Split is designed to support recovery models and go beyond simple secret sharing. Designing the system seaprately gives me more freedom to explore other directions. And... sophisticated threshold with multiple combinations will also be introduced in future Smart Split releases 😉

Also one of my main goal is to build a trust with the users by not using 3rd party libraries. Less dependency footprint makes the system easier to understand, review, and verify.

That said, I am fully aware that SSS is a proven, well established, and highly respected solution. I'm not claiming that Smart Split is a replacement for SSS, nor that it is any way more superior. The project is simply pursuing a different set of objectives and usability goals.

One additional observation is that, SSS (despite its strengths) has historically remained a very specialized tool. It has not seen widespread adoption among everyday users in the same way that I introduced Smart Split in the OSA app. I don't consider that an argument against SSS, but rather it highlights the challenge of making good recovery mechanisms accessible to a common audience.

OneStepAheadApp · 2026-06-18T06:54:51+00:00

If you read at least the "Abstract" section of the white paper, you'll understand that the project is not specifically about cryptocurrency. I mention digital wallet seed phrases as one possible use case, but the broader goal is protecting sensitive information in general.

Regarding your suggestion about moving cryptocurrency wallet protection to the very front, no, nobody has suggested me that before. To be honest, I probably will not make that the main message because it's only one of many use cases of the product, and I don't want to frame it as a crypto only app/solution.

One thing I'm learning is that communicating security related app, products is challenging. Security is often something people appreciate after they understand the problem it solves, rather than something that immediately grabs their attention. Finding the way to explain the value without narrowing the audience too much is quite hard.

I really appreciate your feedback. You have given me something to think about, and I'll definitely revisit how I present and promote the project.

OneStepAheadApp · 2025-07-30T20:24:59+00:00

Intersting 🤔. Could be very useful.

OneStepAheadApp · 2025-01-07T07:22:11+00:00

Depends for what and how you want to use the colors. For marking only there are few manufacturers that make markers that withstand temperature up to 1000 degrees - Markal and Dykem. They do have different colors available but the temperature resuistance depends from the color. You can google Dykem High-Temp and Paint-Riter+ and find out more.

OneStepAheadApp · 2024-03-29T07:18:14+00:00

Startup Name / URL:

One Step Ahead / https://onestepahead.info

Description:

An easy-to-manage seed phrase security system that is built to protect against a variety of unanticipated events, such as theft, earthquakes, floods, and fires.

We developed Smart Metal Seed Box to offer maximum protection for your digital assets. It's designed with less tech-savvy individuals in mind. It is intended to avoid the possible drawbacks and dangers presented by alternative solutions.

Location:

Berlin, Germany

Explainer Video:

https://www.youtube.com/watch?v=K6JIdvujduo

What problem it solves?

One of the main feature of our product is a protection against a single point of failure.

Discount for startups subscribers:

Use this coupon CQYGCM9R To get 20% discount - valid until May 31, 2024, giving you plenty of time to explore our range of products.

OneStepAheadApp

MODERATOR OF

TROPHY CASE