MEGA file system - Revision history

Jsummers at 19:05, 11 January 2015

2015-01-11T19:05:15Z

Dan Tobias: /* References */

2013-10-19T12:27:22Z

‎References

Dan Tobias: /* References */

2013-10-19T12:27:12Z

‎References

Dan Tobias at 23:43, 21 May 2013

2013-05-21T23:43:03Z

Jsummers at 23:04, 21 May 2013

2013-05-21T23:04:13Z

Dan Tobias: /* References */

2013-05-08T01:13:37Z

‎References

Dan Tobias at 13:08, 7 April 2013

2013-04-07T13:08:20Z

Dan Tobias: /* References */

2013-01-31T00:55:03Z

‎References

Dan Tobias: /* References */

2013-01-29T12:58:06Z

‎References

Dan Tobias at 02:57, 23 January 2013

2013-01-23T02:57:35Z

@@ Line 9: / Line 9: @@
 Since the actual storage and implementation is on MEGA's servers, the only file-format details knowable by the public are whatever is exposed in the interfaces (both user-level web interfaces and developer APIs) by which users and third-party developers can access data stored in the system.
-Based on the API documentation, MEGA is a virtual filesystem consisting of hierarchical folders (directories) and files, each pointing to a parent node except for three parentless nodes per account: a personal-files root folder, a file-delivery inbox, and a trash bin. Each node has two segments, a data segment with the actual file contents, and an attribute segment with the filename and whatever other metadata is stored with it (at present none, but some use of metadata is planned in the future, in particular for user-to-user messages). Each segment is separately encrypted with the [[Advanced Encryption Standard|AES-128]] symmetric encryption system; "symmetric" in this case means that encrypting and decrypting is done with the same secret key, in contrast to asymmetric systems where there is a private key and a public key, so somebody with just one of the keys can only encrypt a message without being able to decrypt it (or vice versa). However, MEGA also issues each user account a public and private key for a separate encryption system that is used for inter-user messages.
+Based on the API documentation, MEGA is a virtual filesystem consisting of hierarchical folders (directories) and files, each pointing to a parent node except for three parentless nodes per account: a personal-files root folder, a file-delivery inbox, and a trash bin. Each node has two segments, a data segment with the actual file contents, and an attribute segment with the filename and whatever other metadata is stored with it (at present none, but some use of metadata is planned in the future, in particular for user-to-user messages). Each segment is separately encrypted with the [[AES|AES-128]] symmetric encryption system; "symmetric" in this case means that encrypting and decrypting is done with the same secret key, in contrast to asymmetric systems where there is a private key and a public key, so somebody with just one of the keys can only encrypt a message without being able to decrypt it (or vice versa). However, MEGA also issues each user account a public and private key for a separate encryption system that is used for inter-user messages.
 The MEGA system reportedly has what appear to be contradictory attributes: the encryption/decryption is done at the client end so that MEGA has no way of knowing the contents of the files stored on its service, but they also claim that their system has "de-duping" built in whereby multiple copies of the same data uploaded by different users would be merged in order to save storage space.

@@ Line 20: / Line 20: @@
 * [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]
 * [http://torrentfreak.com/images/WP-KIMDOTCOM.pdf Kim's white paper on Megaupload, the Copyright Lobby, and the Future of Digital Rights]
-* [http://torrentfreak.com/megaupload-raid-destroyed-more-than-10000000-legal-files-131018/
+* [http://torrentfreak.com/megaupload-raid-destroyed-more-than-10000000-legal-files-131018/ Megaupload Raid ‘Destroyed’ (Way) More Than 10,000,000 Legal Files]
 Megaupload Raid ‘Destroyed’ (Way) More Than 10,000,000 Legal Files]

← Older revision		Revision as of 12:27, 19 October 2013
Line 20:		Line 20:
	* [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]		* [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]
	* [http://torrentfreak.com/images/WP-KIMDOTCOM.pdf Kim's white paper on Megaupload, the Copyright Lobby, and the Future of Digital Rights]		* [http://torrentfreak.com/images/WP-KIMDOTCOM.pdf Kim's white paper on Megaupload, the Copyright Lobby, and the Future of Digital Rights]
		+	* [http://torrentfreak.com/megaupload-raid-destroyed-more-than-10000000-legal-files-131018/
		+	Megaupload Raid ‘Destroyed’ (Way) More Than 10,000,000 Legal Files]

@@ Line 5: / Line 5: @@
 }}
-The '''MEGA file system''' is the filesystem used in the cloud-based encrypted virtual disks made available to users of the MEGA system, unveiled on January 19, 2013 by the controversial Kim Dotcom (whose surname is now a misnomer, since he no longer uses the .com top-level domain name due to its being under the jurisdiction of the U.S. government, which is prone to prosecute him and confiscate his sites such as the earlier MegaUpload). (Which Kim is more notorious now, Dotcom, Jong-un, or Kardashian?)
+The '''MEGA file system''' is the filesystem used in the cloud-based encrypted virtual disks made available to users of the MEGA system, unveiled on January 19, 2013 by the controversial Kim Dotcom (whose surname is now a misnomer, since he no longer uses the .com top-level [[domain name]] due to its being under the jurisdiction of the U.S. government, which is prone to prosecute him and confiscate his sites such as the earlier MegaUpload). (Which Kim is more notorious now, Dotcom, Jong-un, or Kardashian?)
 Since the actual storage and implementation is on MEGA's servers, the only file-format details knowable by the public are whatever is exposed in the interfaces (both user-level web interfaces and developer APIs) by which users and third-party developers can access data stored in the system.

@@ Line 9: / Line 9: @@
 Since the actual storage and implementation is on MEGA's servers, the only file-format details knowable by the public are whatever is exposed in the interfaces (both user-level web interfaces and developer APIs) by which users and third-party developers can access data stored in the system.
-Based on the API documentation, MEGA is a virtual filesystem consisting of hierarchical folders (directories) and files, each pointing to a parent node except for three parentless nodes per account: a personal-files root folder, a file-delivery inbox, and a trash bin. Each node has two segments, a data segment with the actual file contents, and an attribute segment with the filename and whatever other metadata is stored with it (at present none, but some use of metadata is planned in the future, in particular for user-to-user messages). Each segment is separately encrypted with the [[AES-128]] symmetric encryption system; "symmetric" in this case means that encrypting and decrypting is done with the same secret key, in contrast to asymmetric systems where there is a private key and a public key, so somebody with just one of the keys can only encrypt a message without being able to decrypt it (or vice versa). However, MEGA also issues each user account a public and private key for a separate encryption system that is used for inter-user messages.
+Based on the API documentation, MEGA is a virtual filesystem consisting of hierarchical folders (directories) and files, each pointing to a parent node except for three parentless nodes per account: a personal-files root folder, a file-delivery inbox, and a trash bin. Each node has two segments, a data segment with the actual file contents, and an attribute segment with the filename and whatever other metadata is stored with it (at present none, but some use of metadata is planned in the future, in particular for user-to-user messages). Each segment is separately encrypted with the [[Advanced Encryption Standard|AES-128]] symmetric encryption system; "symmetric" in this case means that encrypting and decrypting is done with the same secret key, in contrast to asymmetric systems where there is a private key and a public key, so somebody with just one of the keys can only encrypt a message without being able to decrypt it (or vice versa). However, MEGA also issues each user account a public and private key for a separate encryption system that is used for inter-user messages.
 The MEGA system reportedly has what appear to be contradictory attributes: the encryption/decryption is done at the client end so that MEGA has no way of knowing the contents of the files stored on its service, but they also claim that their system has "de-duping" built in whereby multiple copies of the same data uploaded by different users would be merged in order to save storage space.

← Older revision		Revision as of 01:13, 8 May 2013
Line 19:		Line 19:
	* [http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ Discussion on Ars Technica]		* [http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ Discussion on Ars Technica]
	* [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]		* [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]
		+	* [http://torrentfreak.com/images/WP-KIMDOTCOM.pdf Kim's white paper on Megaupload, the Copyright Lobby, and the Future of Digital Rights]

@@ Line 16: / Line 16: @@
 * [https://mega.co.nz/ MEGA home page]
 * [https://mega.co.nz/#developers MEGA developer API documentation]
 * [http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ Discussion on Ars Technica]
 * [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]

← Older revision		Revision as of 12:58, 29 January 2013
Line 17:		Line 17:
	* [https://mega.co.nz/#developers MEGA developer API documentation]		* [https://mega.co.nz/#developers MEGA developer API documentation]
	* [http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ Discussion on Ars Technica]		* [http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ Discussion on Ars Technica]
		+	* [http://robertamsterdam.com/2013/01/whos-afraid-of-kim-dotcom/ Who's afraid of Kim Dotcom?]