问题标签 [encryption]

我需要打乱我们拥有的 UAT 数据库中所有用户的名称和登录名。（由于数据保护法）

但是，有一个问题。

测试人员仍然需要能够使用散列登录名登录

因此，如果用户登录名是“Jesse.J.James”，那么哈希应该类似于

Ypois.X.Qasdf

即大致相同的长度，点在同一个地方

因此 MD5、sha1 等将不适合，因为它们会创建非常长的字符串，并且还会添加自己的特殊字符，例如 + 和 =，验证正则表达式不允许使用这些字符。

所以我正在寻找一些关于如何实现这一目标的建议

我想我需要推出自己的哈希算法

有人做过类似的事情吗？

我正在使用 c# 但我想这对算法并不那么重要

多谢

添加 -

感谢所有的答案。我认为我有责任在不需要做的时候使用“哈希”这个词来造成混乱

我在 sql server 2000 中有这个查询：

它输出一个加密的“AAAA”字符串：

如何转换（解密）来自其来源（即“AAAA”）的输出？

我想将数据保存在 cookie 中（用户名、电子邮件地址等），但我不想让用户轻松阅读或修改它。我需要能够读回数据。我怎么能用 php 5.2+ 做到这一点？

它将用于“欢迎回来鲍勃”类型的功能。它不能替代持久性或会话存储。

JKS（Java Key Store）文件是否加密？它们是否为加密密钥提供全面保护，还是我只需要依赖访问控制？
有没有办法确保密钥受到保护？

我对细节很感兴趣，包括算法、密钥管理等。这些可以配置吗？

我最近遇到了一个奇怪的问题RSACryptoServiceProvider.VerifyHash。

我有一个使用它进行解密的 Web 应用程序。当运行 Web 服务的用户通过我们的 VPN 执行此操作时，它变得非常非常慢。当他们没有连接或互联网连接时，他们很好。

经过大量挖掘，我发现每次RSACryptoServiceProvider.VerifyHash调用它都会发出 LDAP 请求来检查MyMachineName\ASPNET。

我们的 WebDev（基于 cassini 的）服务器不会发生这种情况，因为它们以当前用户身份运行，而且它只是在 VPN 上真的很慢，但根本不应该发生。

出于以下几个原因，这似乎是错误的：

• 为什么要检查本地计算机用户的域控制器？
• 为什么在乎？加密/解密无论如何都有效。

有谁知道为什么会发生这种情况或如何最好地解决它？

什么是 C/C++ 中最好的加密库 在以下方面：

• 熵
• 质量
• 使用方便
• 可读性
• 可移植性
• 表现

你最喜欢什么，为什么喜欢它？

我刚刚发现了 Stack Overflow，我只是在检查是否有关于我与一些朋友在项目中遇到的约束的想法，尽管这更像是我一直试图找到的一个理论问题一段时间的答案。

我对密码学的了解不多，但如果我不够清楚，我会尝试编辑/评论以澄清任何问题。

简而言之，环境是这样的：

• 前端用作访问加密/解密密钥而后端仅用于存储和查询的应用程序。

• 拥有一个您无法访问几个字段的数据库，例如让我们说“地址”，它像往常一样是 text/varchar。

• 您无权访问用于解密信息的密钥，并且所有信息到达已加密的数据库。

主要问题是这样的，如何始终如一地对数据库进行查询，不可能做“像'%F§YU/'~#JKSks23%'这样的地址”之类的东西。（如果有人对此有答案，请随意拍摄）。

但是可以where address='±!NNsj3~^º-:'吗？或者它也会完全吃掉数据库？

另一个可能适用的限制是前端没有太多可用的处理能力，因此加密/解密信息已经开始将其推向极限。（这样说只是为了避免诸如“将表的连接导出到前端并在那里查询”之类的回复。）

有人可以指出我继续思考的方向吗？

非常感谢凌晨 4 点这么快的回复，第一次使用我对这个社区印象深刻。（或者也许我只是针对不同的时区）

只是提供一些信息：

主要问题是部分匹配。大多数数据库中的一项强制性要求是允许部分匹配。主要限制实际上是不允许数据库所有者查看数据库内部的信息。在过去的 10 分钟里，我想出了一个可能的解决方案，它再次扩展到可能的数据库问题，我将在这里添加：

允许半部分匹配的可能解决方案：

• 密码+用户的几个公共字段实际上是加密的关键。对于身份验证，想法是加密一个静态值并在数据库中进行比较。
• 创建一组新的表，其中信息以解析的方式存储，这意味着：“4th Street”将变成 2 个加密行（一个用于“4th”，另一个用于“Street”）。这已经允许半部分匹配，因为已经可以在单独的表上执行搜索。

新问题：

• 这可能会再次占用数据库服务器，还是有人认为这是解决部分匹配问题的可行解决方案？

Post Scriptum：我不接受 Cade Roux 的回答，只是为了进一步讨论，特别是对新问题的可能答案。

在对用户密码进行加盐和散列处理时，任何加盐显然都会有所帮助。盐应该放多长时间有什么最佳做法吗？我会将盐存储在我的用户表中，因此我希望在存储大小和安全性之间进行最佳权衡。随机的 10 个字符的盐是否足够？还是我需要更长的时间？

假设您有一堆文件。假设您可以将元数据存储到这些文件中。比如说，这些元属性之一被称为“加密” 假设每个人都可以查看这些文件，但由于它们是加密的，只有知道如何解密它们的人才能真正读取内容。比如说，对于每个给定的“加密”值，一群人分享如何解密标有该值的文件的知识。假设您希望能够以与操作系统无关的方式以编程方式执行此操作（如果可能）

您将用于“加密”的值是什么？您将如何存储密钥？您将如何组织对密钥的访问？

我目前倾向于以下实施：

• “加密”字段的值包含密钥的名称，可能还表示使用的算法
• 每个用户都可以访问一堆密钥。这可以由用户在类似 LDAP/ActiveDirectory 的结构中的角色定义，或者它们可以只是用户配置文件/主目录中安全目录中的文件。
• 在查看文件时，查看器（我正在尝试构建文档管理系统）检查用户密钥并在找到匹配密钥时解密文件。

你会使用什么加密？对称（AES）？或不对称（什么是好的）？

使用非对称密钥还有一个额外的好处，那就是在读取文件和写入文件之间有所不同：写入文件需要访问私钥，访问公钥（仅半公开，因为只有某些角色可以访问它）将允许读取文件。我在这里完全错了吗？

在中小型企业中解决这些问题的常用系统是什么？

编辑：似乎没有通用的解决方案。因此，我将更清楚地说明我要解决的问题：

想象一个以分布式方式运行的文档管理系统：每个文档都被复制到（公司控制的、私有的）P2P 网络中的各个节点。确保文档冗余的算法用于确保所有文档（包括修订）的备份。该系统在后台作为服务/守护程序工作，并来回铲除文档。

这意味着，用户最终会得到可能不打算在他们的本地工作站（公司控制的 PC 或笔记本电脑或其他东西）上看到的文档 - 设置是这样的，SME IT 人员设置这一切并控制谁是其中的一部分P2P 网络）。

这排除了基于目录访问的方案，因为用户可能能够访问数据。我在这里弄错了吗？本地文件夹是否可以加密，使其只能由域用户访问？那有多安全？

我知道用户共享文件的解密版本——这在技术上很难压制。这不是我要解决的问题。

混淆、散列和加密有什么区别？

以下是我的理解：

• 散列是一种单向算法；无法逆转
• 混淆类似于加密，但不需要任何“秘密”来理解（ROT13 就是一个例子）
• 加密是可逆的，但这样做需要“秘密”