我准备用 go 开发一个 saas 系统，里面设计到 [库房] -> [商品] -> [添加] 功能

 但是租户不愿意让我们知道他们的商品进货价，那么我怎么设计系统里面字段加密，让客户登录时自己看到。
 其他任何人包括软件提供商都不能看到。
 1.成熟的解决方案吗？

用户提供一个密钥，然后你用来加密

商户不变且唯一的 id ，uuid 做 密钥，加密入库，数据查询后解密，返回前端显示
chatgpt 可以问问

不用理会客户的需求，告诉他我们已经帮你加密了。目前就你自己能看

用户使用 pki rsa 证书绑定，公钥加密，私钥解密

端到端加密呗，正确方式使用确实可以做到只有用户能看到明文数据，问题是你的这些所谓租户他们愿意牺牲便利吗？估计是些连强密码都不会设置的主。

服务内置公钥，用户保存私钥。
用户输入价格后公钥加密上传到数据库。
获取价格时，用户输入私钥本地解密显示。

这样只要程序没有后门，就只要用户能看到。

伪需求，你直接告诉租户，里面的数据你们作为软件提供商是看不到的就行了，实际上你们(的运营)也确实看不到，这个概念很模糊。数据库里必须存明文，不然以后这个字段就废了，没法做任何计算和筛选

密文也可以计算，同态加密听说过没。总之技术方案有的是，问题在于 OP 的用户消受不起，连密码都不会设的主，你让 ta 管理端到端的密钥。

如果提供商是恶意的，在加密入库之前，都是能拿到的呀。

除非客户自己整一个算法，类似国内对地理坐标的处理，然后录到你这里，明文保存即可，客户从界面上看到后，用自己的算法解出来。明文只在客户的电脑/脑子里出现……

所以，如果系统能卖上价，考虑下私有化部署？

啊？同态加密用在数据库字段？别谈密码学理论，给一个工程上的实现，现在 OP 需要一种加密方式，让这个字段加密存储，并且在常见的数据库，比如 mysql, postgresql, 哪怕 clickhouse 里面，实现简单的 where price > xxx 的查询。你来讲讲用密文怎么计算

要看你们目前的基础架构方案，如果是一个租户一个数据库，那么整个库都可以做加密： 共享基建+完整的数据加密

解密的时候在数据操作层进行。需要抽象出一套加密解密的体系的 DAO 。

字段加密后所有的 sql 语法都基本废了，程序设计的方式也要变了吧。

那用数据库干嘛，让他们用文本存储数据。

让他们存数据的时候自己搞个公式存错的数据，查的时候他们自己按照自己公式倒推出来。不知道能不能行 😌

＃6
按价格降序排序怎么写？

＃10
where price > xxx
加密后的 还是可以写的
首先暂且将价格固定为分为单位的正整数

然后可以设定一个纯缩放算法，将原始数值 与一个限定范围的正整数系数作为变量 通过一定公式进行缩放算法
缩放算法 就是连续函数 f(x)在 x 为正整数时单调递增 且当 x 为正整数时 f(x)也是正整数
这个函数中的一个或者多个变量，由客户自行初始化时设置 存储到另一套数据库存储

同时，将商品基础信息描述，存储到另一套系统 实现数据库比照隔离

伪需求吧. 加密完还得解密返回客户端. 这加密和解密方法都知道了啊.
就告诉他们,我们是加密的. 公司运营和技术都是看不到的.有老板把自己关小黑屋写的加密程序. 无人可破解.
最好让他们把供应商也录入进来,这样数据就值钱了.同类商品横向对比. 公司也可以做个二道贩子了.

如果录入的金额 100 ,加完密成了 xxx 乱码 .那查询金额为 50~150 的货物,咋查..

＃10
同态加密可以做筛选啊，不一定非得用数据库自带的 select 语句完成吧。可以把所有数据 select 下来，然后后端去筛选。
全同态是可以做到所有的运算的。

OP 的需求还是不太清晰，对于加密后的进货价，还要不要进行运算？如果要运算，需要哪些运算？
如果仅仅是纯列表显示，那么前面几楼的方案最简单；
如果仅需要对进货价格进行带系数的加法运算（例如求总进价），那么半同态加密（ PHE ）就可以做到，速度也能满足；
如果需要对进货价格进行大小的比较，或者其他逻辑运算，可能要用到全同态加密（ FHE ），速度会比正常运算慢百万倍，而且内存占用也超大。（ 参考 /t/700927 ）

＃17
那如果是带系数求和（ ax+by+cz ），这个缩放的方法就不行了，缩放必须是线性的才能满足求和之后可以反算回来，那也就失去了加密的意义了。

＃20
为啥要求和？
什么系统什么场景会有商品上游渠道单价求和这个操作？

＃20
人家的需求就是 保密成本单价 让接触系统的人看不到 这是一个非常常见且合理的需求

我都经手过很多个这个需求的系统开发 比如牙科系统的牙冠成本价 医生都知道 医院都知道 但是他们完全不希望给他们开发系统的开发商和运维商知道

能不解密排序 能不解密比价 走索引 是基本要求

而你说这种 ax+by+c 场景，你确定是要写在 SQL 里面进行计算的吗？什么场景会有这种要求？

不都是取出来在程序侧计算，而程序侧是有解密的系数的 直接解开爱怎么加怎么加

如果仅仅是需要排序或者索引，那你说的方法当然可行。
加总求和的操作，你怎么知道没有呢？求出某个商品在一段时间内的进货总价，不就是数量乘以价格，再加总吗？
当然你可以说这个计算可以解密后放在前端进行，如果是这样，那前面几楼的方案也可以啊，计算都放前端，数据库只是起一个储存数据的作用。
问题的根本就是，你不知道他有哪些计算的需求，你说的缩放，也仅仅能够起到排序这一个作用。