类似 Dropbox 的 Java 应用程序中的加密

发布于 2024-12-07 15:40:01 字数 584 浏览 0 评论 0原文

我正在考虑应用程序中的加密。该架构包括:

  1. 服务器
  2. 桌面客户端
  3. Web 客户端
  4. 移动客户端

目标是允许用户将数据存储在服务器上,并从所有客户端访问它,但通过在客户端上加密数据来保证数据隐私。

Dropbox 是这种架构的一个例子,但据我所知他们不会这样做 - 他们必须在服务器上存储纯文本数据,否则他们将无法通过仅存储相同的文件一次来节省空间,即使它由多个用户存储。

您将如何实施这样的应用程序?我正在考虑使用 Java 作为桌面客户端;理论上,相同的加密代码可以在 GWT Web 客户端(编译为 Javascript)和 Android 客户端中重复使用。然而,这只是理论上的。

  1. 是否有一个可在所有这些平台上使用的加密库?
  2. 使用什么算法?
  3. 私钥呢?我可以每次都询问用户密码,但如何确保所有客户端中同一用户的私钥相同?
  4. 我想避免使用多个密码;但是,如果我对数据和身份验证使用相同的密码,如何防止服务器向提供错误密码的黑客提供数据,或者服务器因为有用户密码而无法解密用户数据?
  5. 有哪些可能的陷阱?

I'm thinking about encryption in an application. The architecture consists of:

  1. Server
  2. Desktop client
  3. Web client
  4. mobile client

The goal is to allow user to store his data on the server, and access it from all clients, but to guarantee data privacy by encrypting data on the client.

Dropbox is an example of such an architecture, but as far as I know they don't do that - they must store plaintext data on their servers, otherwise they wouldn't be able to save on space by storing the same file only once, even if it was stored by multiple users.

How would you implement such an application? I'm thinking about using Java for desktop client; the same encryption code could theoretically be reused in GWT web client (compiled to Javascript) and in Android client. However, that's only in theory.

  1. Is there an encryption library that's available on all these platforms?
  2. What algorithms to use?
  3. What about private keys? I can ask user for the password every time, but how do I ensure that private keys are the same for the same user in all clients?
  4. I'd like to avoid multiple passwords; but if I use the same password for both data and authentication, how do I prevent server from giving data to a hacker which supplied the wrong password, or server from being able to decrypt user data because it has user's password?
  5. What possible gotchas are there?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

笑脸一如从前 2024-12-14 15:40:01

你实际上需要一些不同的加密货币。

首先,您希望客户端加密要上传的文件,并在检索加密的有效负载后对其进行解密。

其次,您需要某种方法来传输加密文件以确保只有正确的用户才能访问其文件。

第一个问题需要对称加密算法。有很多,但最好的选择可能是 AES。如果你看一下gwt-crypto,他们有一个java bouncy的包装器城堡实施。这可以处理您的三个平台中的两个。我不使用 android 平台,但如果没有 AES 实现,我会感到惊讶。至于密钥,您可能最终会得到密码的哈希值。只要记住彩虹表的可能性并采取适当的措施即可。用于加密文件的密码永远不需要通过网络传输,因为我了解您的模型,所有加密和欺骗都是在客户端完成的。由于您提到系统管理员是潜在的攻击者,因此您确实需要研究键盘记录器、内存转储等,但这超出了您提出的具体问题的范围。

第二个问题是使用 TLS 与客户端和服务器端证书解决的问题。此类客户端适用于您正在查看的所有三个平台。不过,您是否想让您的用户经历安装客户端证书的麻烦,这取决于您。有多种后备选项,但没有一个经过充分审查。

You actually need a few different pieces of cryto.

First, you want the client to encrypt the file for upload, and upon retrieving the encrypted payload back decrypt it.

Second, you want some method to transmitting the encrypted file for upload in a manner that insures that only the correct user can access his files.

The first problem requires a symmetric encryption algorithm. There are a bunch out there, but your best bet is probably AES. If you take a look at gwt-crypto at they have a wrapper for the java bouncy castle implementation. That takes care of two of three of your platforms. I don't work with android platform, but I'd be surprised if there wasn't an AES implementation floating around. As for the key, you'll probably end up with a hash of a password. Just keep in mind the possibility of rainbow tables and take appropriate measures. The password used to encrypt the file need never go over the wire, as I understand your model all encryption and deception is done on the client. Since you mentioned system administrators as a potential attacker, you really need to look into key loggers, memory dumps and the like, but that's beyond the scope of the specific question you asked.

The second problem is a solved problem using TLS with client and server side certificates. Clients for such are available for all three platforms you are looking at. Whether you want make your users go through the hassle of installing client side certificates, though, is up to you. There are various fallback options but none are as well vetted.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文