我为什么要做 Shorium

我通常不在这里写自己的公司。

这一次，我有充分的理由破例。

过去几个月，我的大部分精力都投入在 Shorium 上。这是一家我正在创办的网络安全公司，我担任联合创始人兼 CTO。

在产品设计、技术和人机交互领域工作了二十五年之后，走到这一步，连我自己都觉得有意思。

但做得越久，我越发现，我们想解决的问题，和我整个职业生涯一直关注的那些问题其实紧密相关。

只不过这一次，它们牵涉到密码学、联网设备，以及一个关于数字信任之未来的、相当令人不安的问题。

产品不必损坏，也会变得不安全

想想一款联网产品。

它可以是支付终端、工业传感器、医疗设备，也可以是一辆汽车。

使用这些产品时，我们看到的是它们做了什么，却很少看到让它们得以安全运行的那些系统。界面背后，是硬件、固件、软件、证书、密钥、身份、供应商和更新机制。

所有这些组成部分都彼此依赖。

而其中许多依赖关系，都建立在产品最初设计时所做的假设之上。

现在，想象这款产品运行了十五年。

这期间，证书会过期，算法会过时，供应商会更换，漏洞会被发现，法规也会演变。产品也许依然运转完美：能开机，能联网，能完成它的功能。在用户看来，什么都没有变。

但在底层，当初让它值得信任的那些条件，可能已经不复存在。

功能正常的系统，不一定是值得信任的系统。

我职业生涯的很大一部分，都在设计这样的产品：它们越来越复杂，却仍要保持易懂、好用。

我学到的一点是：复杂性不会因为我们不再展示它就消失。在安全领域，这种隐藏的复杂性可能变成严重的问题。

尤其是当没有人能说清楚什么依赖于什么的时候。

量子计算并不是真正的起点

每当谈到后量子密码学，话题总会立刻转向量子计算机。

• 它们什么时候才会强大到足以破解今天的密码学？
• 五年？十年？二十年？

这个问题我觉得很有意思，但从工程的角度看，我不会从这里开始。我们已经知道，广泛部署的公钥密码系统终将需要迁移。

NIST 在 2024 年发布了首批后量子密码标准。欧盟也制定了协调一致的路线图，把 2030 年定为高风险用例的重要里程碑。

无论足够强大的量子计算机何时出现，这场过渡都已经开始了。

而难点并不只是选一个新算法。

想象一下，要替换一台工业设备所用的密码学，而这台设备已经部署在成千上万个现场。

• 它的固件可能依赖某种特定的签名机制。
• 它的硬件可能不支持新算法。
• 它的身份可能依赖现有基础设施签发的证书。
• 它的更新流程可能涉及多家供应商。

改动一个组件，就可能影响整条链路。

这种迁移，不能当成更新笔记本电脑上的一个应用来对待。

更不能假定每台设备都可以召回、更换或下线。我们要做的，是在必须持续运行的系统内部，更换最根本的安全机制。

密码学连续性

这正是 Shorium 登场的地方。

这个名字来自 Shor 算法。该算法证明了，能力足够强的量子计算机可以破解广泛使用的公钥密码系统。

用那个揭示了问题的算法来给公司命名，这一点我挺喜欢。

因为我们创办这家公司的前提，并不是密码学永远不会被攻破。我们的前提是：信任必须能够经受住变化。

Shorium 专注的是密码学连续性。

具体来说，我们正在开发一个平台，用于发现、建模和管理联网产品内部的密码学信任关系。

其中的核心概念，我们称之为 Trust Twin。

可以把它理解为一个活的模型，描绘支撑一款产品的各种密码学依赖。

它不只是一份证书或算法的清单。

它呈现的是这些要素之间如何相互关联。

• 哪个密钥为哪个固件签名？
• 哪张证书确立了哪个身份？
• 哪些组件依赖某种特定的密码学机制？
• 某个算法被弃用时会发生什么？
• 供应商更换某个组件时，什么会随之改变？
• 在这些变化之后，我们又如何证明产品依然值得信任？

当信息分散在各个工程团队、制造系统、供应商和文档之中时，这些问题都很难回答。

我们的方法围绕四项能力展开：Observe、Connect、Simulate 和 Orchestrate。

• 首先，发现相关的密码学信号。
• 然后，重建它们之间的关系。
• 利用这些关系，评估变更可能带来的影响。
• 最后，支持团队规划和协调过渡，同时保留事情经过的证据。

我们的目标，不是再做一个满屏绿灯的仪表盘。

而是让密码学连续性成为工程师能够理解、评估和证明的东西。

这里有一个重要的区分：以上是我们正在努力实现的架构和产品方向。我们还是一家早期公司，我不想把技术愿景和一个已经完成、经过验证的产品混为一谈。

但问题是真实的，方向也是清晰的。

为什么一名产品设计师在做密码学

我不是密码学家。

我也不打算假装是。

Shorium 有多年从事密码学研究的同事。我的工作不一样。我用了大约二十五年设计数字产品、界面和复杂系统。

我待过不同的行业，从数字服务到企业软件，再到嵌入式网络安全。我曾在 Exein 担任三年 Design Lead，在那样的环境里做产品，硬件、软件与安全之间的关系尤为重要。

这些年来，我一次次回到同一个问题。

只有当人们明白自己在用技术做什么时，技术才真正有用。

这听起来像是废话。

实际上并非如此。

我见过技术上很精密的产品变得毫无必要地难以操作，因为它们的架构只对构建它们的工程师讲得通，对负责使用它们的人却讲不通。

我也见过相反的情况：为了看起来简单而设计的界面，藏起了太多复杂性，让用户再也无法理解实际发生了什么。

这两种都算不上好设计。

而在网络安全领域，两者都可能变得危险。

想象一下，你负责几千台联网设备的安全。

有一个密码算法需要被替换。

你手上有一份受影响产品的清单、几个工程团队、若干供应商、合规要求，还有一个截止日期。你不需要一个漂亮的界面来告诉你出了问题。

你需要的是理解自己决策的后果。

• 哪些设备受到影响？
• 什么可以改？
• 什么不能改？
• 如果先迁移某个依赖、后迁移另一个，会发生什么？
• 之后你能证明系统依然安全吗？
• 这正是我看到自己的背景与我们所做之事的联系之处。

作为 CTO，我的职责不只是确保我们选对技术。

而是帮助构建这样一种架构：科学上的正确性、工程上的约束和人的决策，可以在其中共存。

• 密码学必须站得住脚。
• 软件必须可靠。
• 操作它的人也必须对系统有足够的理解，才能做出明智的决定。

这不是在开发末尾加一个更好看的仪表盘就能解决的。

它必须从一开始就影响架构。

让复杂变得可理解，不等于把它藏起来

在产品设计中，有一条原则我遵循了很多年。

不要靠删掉人们需要的信息，让东西看起来简单。

要让它变得可理解。

我认为这个区分在当下尤其重要，因为越来越多的软件产品正在把自动化和 AI 引入日益复杂的工作流。

我们已经非常擅长让系统给出答案。

但在帮助人们理解这些答案从何而来、依赖哪些假设、假设变了又会怎样这方面，我们就不总是那么擅长了。对消费类应用来说，这也许只会带来令人沮丧的体验。对安全攸关的系统来说，后果可能严重得多。

在 Shorium，这影响着我对 Trust Twin 的思考。

密码学依赖模型只有帮助人们对系统进行推理，才是有用的。

光发现一种关系还不够。

我们还需要了解它的来源、它的上下文，以及有什么证据支持它。

如果某个依赖发生变化，系统应该帮助解释后果。

如果系统给出一条建议，负责执行的人需要有足够的信息来评估它。而当决策做出之后，必须有办法还原事情的经过。最后这一点比看上去更重要。

在网络安全领域，六个月后还能解释清楚一项决策，可能和当初做对这项决策同样重要。

这就是为什么我觉得产品设计、软件架构和安全的交汇点如此有意思。

好的设计不是涂在工程表面的装饰。

它是系统传达自身行为的方式之一。

有时候，正是它决定了你只是拥有信息，还是能够据此行动。

Shorium 背后的人

我决定接受这个挑战，原因之一就是这支团队。

Danilo Bontà，我们的创始人兼 CEO，在网络安全和国际科技领域工作了十五年以上。他的经历包括搭建 Moodle 的全球合作伙伴生态、在亚太地区开展工作，以及与 NATO 和政府组织等机构合作。

Dan 和我此前在 Exein 共事过。

我们早已了解彼此处理问题的方式，也都关心同一件事：当网络安全必须在真实产品中而不是理论架构中运转时，会发生什么。

Dariia Porechna，联合创始人兼首席科学官，有着截然不同的背景。

她是一位后量子密码学家，曾在 Wolfram Research 工作六年，与 Stephen Wolfram 共事，为 Wolfram Language 开发密码学功能。她还是后量子数字签名构造 SILMARILS 的共同作者。Dariia 带来了 Shorium 这样的产品所需要的科学基础。

我们的团队还包括密码学研究人员、工程师，以及负责把这些研究变成可构建、可运行之物的同事。

我喜欢在这样的环境里工作。

用不同思维模型看待同一个问题的人，往往会问出不同的问题。

密码学家可能会问，这个构造在数学上是否成立。

工程师可能会问，它能否在特定设备的约束下被可靠地实现。

产品设计师可能会问，负责这台设备的人能否明白接下来需要发生什么。

这三个问题都重要。

而作为 CTO，我的部分职责就是确保它们不会变成三场各说各话的对话。

为什么这也是一个 brownfield 问题

我在这里写 Shorium，还有另一个原因。

科技行业的大多数人都喜欢谈论新东西。

新架构。新框架。新基础设施。新产品。

我们描述技术进步时，往往好像一切都始于一个干净的环境和一个设计完美的系统。

现实很少如此。真实的组织有现成的产品、现成的基础设施，有现成的供应商、流程、认证，还有多年前做出的技术决策。

其中一些决策在当时完全合理。另一些是妥协。还有一些之所以难以改变，是因为如今有太多东西依赖于它们。

这就是 brownfield 工程的现实。你没有机会从零开始重新设计一切。你继承一个系统，理解它的约束，然后想办法让它演进，同时不破坏已经运转良好的部分。

后量子过渡是一个特别有意思的例子。我们不可能在一夜之间替换全世界的密码基础设施。我们只能在它运行的同时进行迁移。有些产品很容易更新。

另一些则需要改动固件、硬件、制造流程，甚至整条信任链。有些产品在最初的设计者早已离开之后，仍将长期在役。

而在整个过程中，制造商依然要维持安全性、可用性和合规性。对我来说，这比通常那种讨论量子计算机何时强大到足以破解现有密码学的话题有意思得多。

真正的工程工作早在那之前就开始了。

而且发生在已经存在的系统内部。

成为 CTO 并不意味着离开设计

还有一件事我想谈谈，因为它关系到我如何看待自己的角色。

我职业生涯的大部分时间里，别人都把我看作设计师。

Product Designer。UX Designer。Design Lead。

这些头衔随着时间变化，但底层的工作始终是理解系统、系统的约束，以及与系统交互的人。

我从不认为设计仅限于界面。

界面不过是系统中变得可见的那一部分。

它背后是关于架构、信息、行为、性能、可靠性以及各组件如何交互的种种决策。

不理解至少其中一部分决策，就设计不出好的体验。

而产品越复杂，把设计和工程当作完全独立的学科就越没有意义。

转任 Shorium 的 CTO 并没有改变这个看法。

而是拓展了它。

如今，我把更多时间花在思考架构、技术选型、工程流程，以及如何构建一个能够演进而不累积不必要复杂性的平台上。

性能对我很重要。可维护性也是。能够理解系统为何如此运行，同样重要。

当然，我依然在意界面。

但我同样关心任何东西抵达屏幕之前发生的事。

• 数据如何采集。
• 关系如何表示。
• 系统如何通信。
• 证据如何保存。
• 如何避免制造日后会成为问题的依赖。
• 以及如何构建一个在成长过程中依然可理解的东西。

我不认为这是在远离设计。

我认为这是把同样的思维方式，用在系统的另一个层面。

对我来说，这也许正是这次转变最有意思的地方。

二十五年过去了，我依然在研究人与技术之间的关系。

只不过是在技术栈更深的地方。

接下来

Shorium 还处于早期。

我们正在都灵建设公司、开发平台，并逐一攻克其中涉及的科学和工程挑战。

有些事我们知道。有些事我们还需要验证。前面还有很多艰难的决定。

我没什么兴趣在能力尚不存在时就宣布它们，也不想假装打造一款技术上雄心勃勃的产品是件简单的事。

它并不简单。

尤其是当你身处密码学、嵌入式系统、软件架构和监管要求的交汇点时。

但我认为，这个底层问题值得解决。

多年来，我们一直把安全当作可以在某个特定时刻评估的东西。

• 一款产品通过了审计。
• 一张证书是有效的。
• 一个算法被认为是安全的。
• 一台设备符合某项标准。
• 然后时间流逝。
• 产品变了。
• 它的依赖变了。
• 它周围的世界也变了。

问题在于，我们能否构建这样的系统：它们足够理解这些变化，从而在整个生命周期中维持信任。

这正是我们在 Shorium 努力做的事。

也是我决定把职业生涯的下一段投入其中的原因。

当初让产品值得信任的假设早已改变之后，产品仍可能继续运转很久。

我认为，我们应该有办法知道这种情况何时发生。

最好是在什么东西损坏之前。

Shorium — Cybersecurity for Continuity

原文发表于 Brownfield AI。