Mega的加密如何共享？ [英] How does Mega's encryption work for sharing?

问题描述

我有一些问题要找到一种方法来实现可以与多个收件人共享的任意数据的加密。巨型似乎这样做。据我所知，在将数据上传到Web服务器之前对其进行加密。仍然可以与他人共享该文件。如何使用加密？

想象下面的情况：

1. 用户Alice将文件上传到服务器，正在加密


2. 爱丽丝想与Bob和Dave共享该文件。 Bob和Dave如何访问该文件并查看其原始内容（解密）？

解决方案

如何使用加密？

答案是对称密钥算法。 Mega利用HTML5提供的浏览器，对称密钥加密。看到问题MEGA在内部使用什么加密算法？

如onemouth所示，您的数据glob用主密钥加密。

每个用户还有一个公钥/私钥对。并且每个文件都是
在不同的会话密钥下加密。会话密钥在用户的主密钥下被加密
。

要了解它的工作原理，意味着查看所有组件，看看他们如何互操作。 Mega解释了在他们的网站上加密对称/共享密钥的过程：

（嵌入的链接和强调的文本在我引用的引用文本中）

MEGA内部使用什么加密算法？ / a>

对于批量传输，AES-128（我们认为，AES-192和AES-256的CPU
的使用率越高越好理论安全
有利，至少直到量子计算机的出现）。
下载完整性检查是通过CCM的分块变量
完成的，该变量的效率低于OCB，但不受
专利的限制。

为了在用户之间建立共享秘密，并将
文件放入您的收件箱，RSA-2048 关键长度被选为太不安全和太慢之间的中间
理由。在 JavaScript中实现所有加密，
解密和密钥生成 ，其中
将吞吐量限制为几MB / s，并导致显着的CPU负载。我们
期待执行拟议的 HTML5
WebCrypto API 在所有主流浏览器，这将消除这个
的瓶颈。 JavaScript的内置随机数生成器通过鼠标/键盘增强
定时驱动的RC4熵池以及
crypto。*随机性，其中可用（Chrome和Firefox只有
时间 - Internet Explorer和Safari生成的密钥的安全性比它们的安全性要小得多）。

文件夹共享如何工作？

您可以共享任何您的云驱动器的子树与朋友，家人或
同事。邀请是通过电子邮件地址。没有
帐户的受邀者将收到一封具有注册链接的电子邮件通知。
或者，您可以创建到任何文件夹的公共链接，
导出文件夹特定的加密密钥，使其无需
MEGA帐户就可以访问。然后，您有责任将
文件夹密钥安全地传送给收件人。

要建立，修改或删除共享，只需右键单击文件管理器中的
文件夹，然后选择共享。有三个访问
级别：只读，读/写（文件可以添加，但不能删除），
和完整（可以添加和删除文件）。如果您添加了一个还没有帐号的电子邮件
地址，则您需要在收件人完成注册过程后至少在
上线，以便
您可以加密共享他新创建的公钥的秘密。

我将共享文件夹中的数据作为我的其他数据安全吗？
共享文件夹本质上与其最不安全的
成员一样安全。

而不是只有一个主键，你现在有另一个钥匙，你委托给X个人。您的安全性与您对X人的信任一样好。

Mega上的每个文件都有唯一的ID。所以如果凭证是：

  fileId = Abc123Ab 
 shareKey = abcdefghijklmnopqrstuvwxyz0123456789ZYXWVUT 
 https：// mega。 co.nz/#!fileId!shareKey 
  

试图下载

  https://mega.co.nz/#!fileId 
  

将导致下载加密文件。该文件无法解密，除非用户具有共享解密密钥。你如何获得shareKey给某人取决于你。但是，访问该shareKey的任何人都可以解密下载的文件，因此通过电子邮件或其他未加密的媒体发送完整的URL是一个坏主意。一旦创建了一个shareKey（通过webapi中的获取链接），它就无法更改。

另外，

但是，我们的核心服务器基础架构的妥协使得
有额外的风险：可以操纵公钥，并且可以伪造关键请求
。

他们所说的是在没有共享启用增加的情况下出现的安全问题，因为个人私人密钥的个人威胁妥协。

我的存储数据是否绝对安全？ a> 所有安全性都是相对的。存在攻击向量的
- 它们不是特定于MEGA的，但是我们
要让您了解风险：个人帐户受到损害
：

• 计算机上的间谍软件。一个简单的键盘记录器就足够了，但会话凭据和密钥也可以从内存或
  文件系统中提取。


• 肩上冲浪。请勿在有人看到您的按键时输入密码。


• 密码强制。使用强密码。


• 网络钓鱼。在输入
  您的密码之前，请始终确认连接的安全状态（https：//）和正确的域名（mega.co.nz）。大规模攻击可以通过以下方式进行：


• 中间的人攻击。需要发布一个有效的重复SSL证书与DNS伪造和/或攻击我们的BGP
  路由（DigiNotar风格的场景）。


• 访问托管< a href =https://mega.co.nz/index.html =nofollow> https://mega.co.nz/index.html ，并用伪造的$ b替换该文件$ b版本（这不会影响通过安装的应用程序基础访问）。
  请注意，在分配的静态内容CDN
  上操作内容不会造成安全风险，因为从
  index.html加载的所有活动内容都需要使用加密散列进行验证（认为
  作为网站的某种安全启动）。这种类型的攻击
  需要向客户端发送恶意代码，因此可以检测到
  。


• 访问我们的核心服务器基础架构，并为现有共享创建伪造的密钥请求。这种类型的攻击仅影响具有共享文件夹的帐户中的数据
  ，并且在客户端
  也可以检测到。

此外，并不是所有数据都是私有的，大多数用户可识别的信息都是未加密的。

我的所有个人信息是否受到加密？ 否。只有文件
数据和文件/文件夹名称被加密。我们需要
的操作访问权限，例如您的电子邮件地址，IP地址，文件夹
结构，文件所有权和付款凭据，以及
处理未加密的EM>。有关详细信息，请参阅我们的隐私政策。

他们的API文档可以在 https://mega.co.nz/#doc

12.2密码学

所有对称加密操作均基于AES-128。它以文件的密码块链接模式和
文件夹属性块和实际文件数据的计数器模式运行。
每个文件和每个文件夹节点使用自己随机生成的128位
密钥。文件节点对属性块和文件
数据使用相同的密钥，加上64位随机计数器起始值和64位元MAC
来验证文件的完整性。每个用户帐户使用对称的
主密钥来ECB加密其自己的
树中保存的节点的所有密钥。该主密钥存储在MEGA的服务器上，使用从用户登录密码导出的
哈希进行加密。文件完整性是
验证使用分块CBC-MAC。块大小从128 KB开始，
增加到1 MB，这是所需空间
存储块MAC之间的合理平衡以及
完整性检查部分读取的平均开销。除了对称密钥，
每个用户帐户都有一个2048位RSA密钥对来安全地接收数据
，如共享密钥或文件/文件夹密钥。其私有组件是
，用用户的对称主密钥加密。

12.3共享文件夹

该文件夹的所有者全权负责管理访问; 股票是非传递性的（不能在收入股份中的文件夹上创建股票
）。共享文件夹
中的所有参与者通过通用共享特定密钥获取加密访问权限，其中
从所有者传递（理论上讲，从任何人参与
分享，但这将在核心基础架构妥协的
事件中造成重大的安全风险）通过RSA向新参与者
创造。共享文件夹中的节点的所有密钥（包括其
根节点）都被加密到该共享密钥。向共享文件夹添加新
节点的方负责提供相应的
节点/共享特定密钥。缺少节点/共享专用密钥只能由共享所有者提供
。

12.4未认证的传递

MEGA支持安全的未经身份验证的数据传送。任何完全
注册用户可以通过
他们的RSA公钥接收收件箱中的文件或文件夹。

，您信任他们的JavaScript代码，通过HTTPS验证正确。然后，您信任您的JavaScript引擎（网络浏览器）来正确处理该事务。最后，您相信您的操作系统不允许其他正在运行的进程嗅探RAM中的未加密的私钥（请参阅 https ：//nzkoz.github.io/MegaPWN/ ）。

一定要采取预防措施，但它是最好的选择之一目前可用。在使用GPG上传到Mega之前，您可以随时对其进行加密，以减轻上述问题。

I have some issues regarding to find a way to achieve the encryption of arbitrary data that can be shared with multiple recipients. Mega seems to do exactly that. As far as I read it encrypts the data before its uploaded to the web server. Still it is possible to share that file with others. How is that done with the encryption?

Imagine the following scenario:

1. User Alice uploads a file to the server, it is being encrypted
2. Alice wants to share that file with Bob and Dave. How can Bob and Dave access the file and see its original content (decrypted)?

解决方案

How is that done with the encryption?

The answer is symmetric-key algorithm. Mega utilizes in-browser, symmetric key encryption provided by HTML5. See question "What encryption algorithms does MEGA use internally?" below.

As onemouth said, your data glob is encrypted with a master key.

Every user also has a public/private key pair. And every file is encrypted under different session key. Session keys are encrypted under user's master key.

To understand how it all works means looking at all the component pieces and seeing how they interoperate. Mega explains the process of encrypting symmetric/shared keys on their website:

(embedded links and emphasized text in quoted text added by me)

What encryption algorithms does MEGA use internally?

For bulk transfers, AES-128 (we believe that the higher CPU utilization of AES-192 and AES-256 outweighs the theoretical security benefit, at least until the advent of quantum computers). Post-download integrity checking is done through a chunked variation of CCM, which is less efficient than OCB, but not encumbered by patents.

For establishing shared secrets between users and dropping files into your inbox, RSA-2048 (the key length was chosen as middle grounds between "too insecure" and "too slow"). All encryption, decryption and key generation is implemented in JavaScript, which limits throughput to a few MB/s and causes significant CPU load. We are looking forward to the implementation of the proposed HTML5 WebCrypto API in all major browsers, which will eliminate this bottleneck. JavaScript's built-in random number generator is enhanced through a mouse/keyboard timing-driven RC4 entropy pool as well as crypto.* randomness where available (Chrome and Firefox only at the moment - keys generated by Internet Explorer and Safari are less secure than they could be).

How does folder sharing work?

You can share any subtree of your cloud drive with friends, family or coworkers. Invitation is by e-mail address. Invitees who do not have an account yet will receive an e-mail notification with a signup link. Alternatively, you can create a public link to any of your folders and export the folder-specific crypto key, making it accessible without a MEGA account. It is then your responsibility to securely transmit the folder key to the recipient(s).

To establish, modify or delete a share, simply right click on a folder in your file manager and select Sharing. There are three access levels: Read-only, read/write (files can be added, but not deleted), and full (files can be added and deleted). If you added an e-mail address that did not have an account yet, you need to be online at least once after the recipient completes the signup process so that you can encrypt the share secret to his newly created public key.

Is data that I put in shared folders as secure my other data? Shared folders, by nature, are only as secure as their least secure member.

Instead of just one master key, you now have another key that you have entrusted to X number of people. Your security is as great as your trust of those X people.

Each file on Mega has a unique ID. So if the credentials are:

fileId=Abc123Ab
shareKey=abcdefghijklmnopqrstuvwxyz0123456789ZYXWVUT
https://mega.co.nz/#!fileId!shareKey

Attempting to download

https://mega.co.nz/#!fileId

will result in downloading the encrypted file. The file cannot be decrypted unless the user has the shared decryption key. How you get the "shareKey" to someone is up to you. But anyone with access to that shareKey can decrypt the downloaded file so sending the full URL via email or other unencrypted mediums is a bad idea. Once a shareKey is generated (by "Get Link" in the webapi) it cannot be changed.

And additionally,

However, a compromise of our core server infrastructure poses an additional risk: Public keys could be manipulated, and key requests could be forged.

What they are saying is the security issues that arise without sharing enabled increase because the individual threats of individual private key compromise.

Is my stored data absolutely secure? All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks: Individual accounts are jeopardized by:

• Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
• Shoulder surfing. Do not type your password while someone could watch your keystrokes.
• Password brute-forcing. Use strong passwords.
• Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password. Large-scale attacks could be mounted through:
• A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
• Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
• Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in accounts with shared folders and is detectable on the client side as well.

Furthermore, not all data is private and most user-identifiable information is stored unencrypted.

Is all of my personal information subject to encryption? No. Only file data and file/folder names are encrypted. Information that we need operational access to, such as your e-mail address, IP address, folder structure, file ownership and payment credentials, are stored and processed unencrypted. Please see our privacy policy for details.

More detail can be had in their API documentation at https://mega.co.nz/#doc

12.2 Cryptography

All symmetric cryptographic operations are based on AES-128. It operates in cipher block chaining mode for the file and folder attribute blocks and in counter mode for the actual file data. Each file and each folder node uses its own randomly generated 128 bit key. File nodes use the same key for the attribute block and the file data, plus a 64 bit random counter start value and a 64 bit meta MAC to verify the file's integrity. Each user account uses a symmetric master key to ECB-encrypt all keys of the nodes it keeps in its own trees. This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password. File integrity is verified using chunked CBC-MAC. Chunk sizes start at 128 KB and increase to 1 MB, which is a reasonable balance between space required to store the chunk MACs and the average overhead for integrity-checking partial reads. In addition to the symmetric key, each user account has a 2048 bit RSA key pair to securely receive data such as share keys or file/folder keys. Its private component is stored encrypted with the user's symmetric master key.

12.3 Shared folders

The owner of the folder is solely responsible for managing access; shares are non-transitive (shares cannot be created on folders in incoming shares). All participants in a shared folder gain cryptographic access through a common share-specific key, which is passed from the owner (theoretically, from anyone participating in the share, but this would create a significant security risk in the event of a compromise of the core infrastructure) to new participants through RSA. All keys of the nodes in a shared folder, including its root node, are encrypted to this share key. The party adding a new node to a shared folder is responsible for supplying the appropriate node/share-specific key. Missing node/share-specific keys can only be supplied by the share owner.

12.4 Unauthenticated delivery

MEGA supports secure unauthenticated data delivery. Any fully registered user can receive files or folders in their inbox through their RSA public key.

Ultimately, you are trusting their javascript code which is verified authentic by HTTPS. Then you are trusting your javascript engine (web browser) to correctly handle the transaction. And finally you are trusting your operating system to not allow other running processes to sniff out the unencrypted private key in RAM (see https://nzkoz.github.io/MegaPWN/).

There are certainly precautions to take along the way, but it is one of the best options currently available. You can always encrypt your files before uploading to Mega with GPG to alleviate some of the issues outlined above.

这篇关于Mega的加密如何共享？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！