It looks like you're using an Ad Blocker.
Please white-list or disable AboveTopSecret.com in your ad-blocking tool.
Thank you.
Some features of ATS will be disabled while you continue to use an ad-blocker.
Originally posted by Maxatoria
sounds good over all but i'm sure that like most things it can be broken given enough interest and the fact that the server will have to agree with the client over version details will allow compromised systems to be fooled.
and at the end of the day does it matter if the person you want to keep the data from can just turn up with a warrant and access the target system as its like anything if a judge can sign a form to give access then it don't matter what encryption you used to transfer the data as they can read it native format at the other end.
AT&T-Mozilla “WebPhone” gives a glimpse of the dumb pipe future
By combining Firefox's new WebRTC support, Ericsson's Web Communication Gateway, and AT&T's API Platform, Mozilla has demonstrated calls, text messages, and video calls all being made from within the browser. It's all in a proof-of-concept application AT&T calls WebPhone, and Mozilla will demonstrate WebPhone next week at the Mobile World Congress conference.
With the right phone operator support, the plugin-free technology can potentially offer a full range of telephony services through the browser. This decouples traditional phone services from the phone itself, potentially enabling access to the phone and text messages from anywhere with an Internet connection and WebRTC-enabled browser. The demo is currently limited in scope, with AT&T planning to roll out an alpha version of the full API "in the near future."
AT&T describes WebPhone as a "vision for the future of seamlessly integrated communication." More than that, however, it's a vision for the network operator as dumb pipe provider. Put that browser on a phone—perhaps one running Firefox OS—and you can do away with the voice connection entirely. Just place everything, voice and data alike, over the data connection.
Originally posted by Maxatoria
Personally it probably won't take off due to there being no 'admin' oops I've forgotten my password can i get at my data so it will be a niche market thing for people who are willing to keep their data secret even if they forget the password and are willing to take the risk where as in the IT business passwords are expected to be changed etc by the sysadmin
Originally posted by jimmyx
as an old machine code programmer, that was a slow, and inaccurate keyboard jock (reason i quit and went into networking)....there is an equally old adage that still applies today...."what can be written, can be read"....if you can show logically, and/or diagramed.... "how" this UCE... CAN'T BE...backdoored, hacked, or a website with the details...i might take it seriously
Originally posted by Violater1
There are some encryption programs that you can use.
AES
en.wikipedia.org...
PGP
en.wikipedia.org...
and GnuPG
en.wikipedia.org...
There is one from an old Soviet Block country that is illegal to use, I just can't think of it.
Originally posted by PhoenixOD
Isnt this the encryption they use on the new site 'mega'. Ive seen some articles explaining how the encryption on mega is very unsafe.
Originally posted by PhoenixOD
reply to post by XPLodER
Im no expert in encryption but what do you make of this ;
fail0verflow.com...
You can then select the forged file in the file picker above again, to verify that it still has the same hash. If you were hosting one of Mega’s CDN nodes (or you were a government official of the CDN hoster’s jurisdiction), you could now take over Mega and steal users’ encryption keys. While Mega’s sales pitch is impressive, and their ideas are interesting, the implementation suffers from fatal flaws. This casts serious doubts over their entire operation and the competence of those behind it.
Update (2013-01-24): Mega has now switched to using SHA-256. They get points for fixing it quickly, but I wonder what other subtle or not-so-subtle security problems remain.
The Results
Severity class VI: Fundamental and generally exploitable cryptographic design flaws
Class V and VI vulnerabilities:
- none reported -
Class IV vulnerabilities:
Invalid application of CBC-MAC as a secure hash to integrity-check active content loaded from the distributed static content cluster. Mitigating factors: No static content servers had been operating in untrusted data centres at that time, thus no elevated exploitability relative to the root servers, apart from a man-in-the-middle risk due to the use of a 1024 bit SSL key on the static content servers. Fixed within hours.
Class III vulnerabilities:
XSS through file and folder names. Mitigating factors: None. Fixed within hours.
XSS on the file download page. Mitigating factors: Chrome not vulnerable. Fixed within hours.
XSS in a third-party component (ZeroClipboard.swf). Mitigating factors: None. Fixed within hours.
Class II vulnerabilities:
XSS through strings passed from the API server to the download page (through three different vectors), the account page and the link export functionality. Mitigating factors – apart from the need to control an API server or successfully mounting a man-in-the-middle attack –: None. Fixed within hours.
Class I vulnerabilities:
HTTP Strict Transport Security header was missing. Fixed. Also, mega.co.nz and *.api.mega.co.nz will be HSTS-preloaded in Chrome.
X-Frame-Options header was missing, causing a clickjacking/UI redressing risk. Fixed.
We believe that it would be premature to draw any conclusions at this time — barely three weeks after our launch and one week into the program. It is clear that the vulnerabilities identified so far could all be found by checking only a few lines of code at a time; none of them required any analysis at a higher level of abstraction. Needless to mention that nobody cracked any of the brute-force challenges yet (please check back in a few billion billion years).
a user goes to a web sight with UCE and the web page requests an encrypted secure connection to be established between the server and the user, this HTTPS encryption allows for the secure delivery of an encryption program to the web browser, this program then loads "inside" the web browser, and encrypts everything coming and going from the end users PC over the encrypted HTTPS connection
Originally posted by ChaoticOrder
reply to post by XPLodER
a user goes to a web sight with UCE and the web page requests an encrypted secure connection to be established between the server and the user, this HTTPS encryption allows for the secure delivery of an encryption program to the web browser, this program then loads "inside" the web browser, and encrypts everything coming and going from the end users PC over the encrypted HTTPS connection
But this still relies on SLL/HTTPS... so nothing has really changed. I want to take security certificates out of the picture as well. And I believe it's possible, I'm working on ways to do it with JavaScript based public key cryptography handled by the browser.
SSL/HTTPS security model is well studied, and reliable.
are you looking at user to user encryption, end to end in the browser?
Originally posted by kwakakev
To safely store private information on the internet, UCE is the most common sense method. A big problem with encryption is how to safely transfer keys. If the key does not need to go anywhere and just remain with the user then there is no need to transfer it and risk potential exposure of it.
If the users system has been compromised with key loggers, packet sniffers and other system monitors then there is still a risk of the key being stolen. For Mega's system it does provide an added level of safety as each users system will need to be hacked to decrypt the whole lot. With a 2048 bit key it is going to take a lot of grunt to brute force it. If Mores law is still in effect, but the latest developments are under a national security blanket then the exponential growth of computer power will hack it some time in the future. With some of the proposed claims of quantum computing power, new algorithms and techniques will have to be developed. But the core concept of the key and encryption taking place on the users machine will remain strong.