Drew
Banned
An interesting essay, thought y'all might peruse & enjoy...
Check Out the Article Here
Cheers,
Drew
Check Out the Article Here
Cheers,
Drew
📎 AI Summary:
The thread revolves around skepticism of encryption security, with Drew sharing an article and later clarifying its content. A contributor with expertise strongly criticizes closed-source and hardware-based encryption, arguing they are inherently insecure due to potential backdoors and lack of transparency, and highlights concerns about Windows 7's handling of decrypted data in RAM. The overall sentiment emphasizes distrust of proprietary encryption methods, advocating for open-source encryption as a more reliable option, and ends with a reminder to trust no one regarding encryption security.
The thread revolves around skepticism of encryption security, with Drew sharing an article and later clarifying its content. A contributor with expertise strongly criticizes closed-source and hardware-based encryption, arguing they are inherently insecure due to potential backdoors and lack of transparency, and highlights concerns about Windows 7's handling of decrypted data in RAM. The overall sentiment emphasizes distrust of proprietary encryption methods, advocating for open-source encryption as a more reliable option, and ends with a reminder to trust no one regarding encryption security.
19ramman85
New Member
Well, now I'm more confused than ever about encryption! lol
Very unexplanatory of you Drew
Let me help
There is no such thing as secure encryption when using closed source proprietary or hardware based encryption
The fact is, if security professionals are not allowed to see the sourcecode, then there is no possibility of knowing whether or not the source has been backdoored by a Corp/Gov agency
Hardware based encryption is even more deceptive and dangerous than merely closed source software because if the hardware is backdoored, the bad encryption cannot be later changed to good encryption unless you want software in addition to hardware encryption
Hardware encryption gives the end user a false sense of security because of its ease of use and impressive sounding security specs that may be irrelevant
A good example is a popular AES hardware based thumbdrive that was on the market a few years back.
It was advertised as secure, yet a simple firmware update left the contents of the drive in the clear and unencrypted
The fact is, that there is no possible way that a firmware update could decrypt the contents without the password unless they were already decrypted
It appears that the hardware simply prevented the end user from accessing their data untill the correct password was entered and the firmware update simply showed the end users the fallacy of manufacturers claims
Windows 7 users can install older versions of Drivecrypt correctly without errors, make encrypted containers correctly without errors and open the container correctly without errors...
HOWEVER,
Once the container is opened and the decryption key is in RAM, Microsoft issues a BSOD error and copies the contents of RAM to your hard drive, then reboots the computer
You will never know that your decryption key in RAM has been copied to disk because the BSOD error reboots your computer within 1 second of seeing the blue screen so that you never have time to read the error
You can read the error by aiming a videocamera at your screen just before you open the encrypted container but immediately after the reboot you had better be disconnected from the Internet because the contents of RAM with your decryption key are immediately sent to Microsoft after the reboot
The question we all should be asking is that...
If the program installed without errors, made an encrypted volume without errors and opened the container without errors...then
WHAT EXACTLY IS THE PROBLEM that requires Microsoft to gain access to my decryption key?
If you are old enough to remember DOS, then you might remember PKZip v2.04G
PKZip v2.04G was alledgedly secure encryption as long as you entered a password longer than 12 digits (At the time)
It was also open source encryption and I still have a copy of the source here somewhere
The point is..
If PKZip could be validated as secure by the end users, then why did they switch to closed source after that?
Trust No One when it comes to encryption
That is the very best advice you will ever get on the subject
Other than that, I would double encrypt sensitive contents with open source encryption
It may not be the most secure encryption and the NSA can most likely crack a single round with ease, but it is far better than closed source that makes wild claims of unbreakable security yet more likely than not has a backdoor (For National Security Reasons "of course")
Let me help
There is no such thing as secure encryption when using closed source proprietary or hardware based encryption
The fact is, if security professionals are not allowed to see the sourcecode, then there is no possibility of knowing whether or not the source has been backdoored by a Corp/Gov agency
Hardware based encryption is even more deceptive and dangerous than merely closed source software because if the hardware is backdoored, the bad encryption cannot be later changed to good encryption unless you want software in addition to hardware encryption
Hardware encryption gives the end user a false sense of security because of its ease of use and impressive sounding security specs that may be irrelevant
A good example is a popular AES hardware based thumbdrive that was on the market a few years back.
It was advertised as secure, yet a simple firmware update left the contents of the drive in the clear and unencrypted
The fact is, that there is no possible way that a firmware update could decrypt the contents without the password unless they were already decrypted
It appears that the hardware simply prevented the end user from accessing their data untill the correct password was entered and the firmware update simply showed the end users the fallacy of manufacturers claims
Windows 7 users can install older versions of Drivecrypt correctly without errors, make encrypted containers correctly without errors and open the container correctly without errors...
HOWEVER,
Once the container is opened and the decryption key is in RAM, Microsoft issues a BSOD error and copies the contents of RAM to your hard drive, then reboots the computer
You will never know that your decryption key in RAM has been copied to disk because the BSOD error reboots your computer within 1 second of seeing the blue screen so that you never have time to read the error
You can read the error by aiming a videocamera at your screen just before you open the encrypted container but immediately after the reboot you had better be disconnected from the Internet because the contents of RAM with your decryption key are immediately sent to Microsoft after the reboot
The question we all should be asking is that...
If the program installed without errors, made an encrypted volume without errors and opened the container without errors...then
WHAT EXACTLY IS THE PROBLEM that requires Microsoft to gain access to my decryption key?
If you are old enough to remember DOS, then you might remember PKZip v2.04G
PKZip v2.04G was alledgedly secure encryption as long as you entered a password longer than 12 digits (At the time)
It was also open source encryption and I still have a copy of the source here somewhere
The point is..
If PKZip could be validated as secure by the end users, then why did they switch to closed source after that?
Trust No One when it comes to encryption
That is the very best advice you will ever get on the subject
Other than that, I would double encrypt sensitive contents with open source encryption
It may not be the most secure encryption and the NSA can most likely crack a single round with ease, but it is far better than closed source that makes wild claims of unbreakable security yet more likely than not has a backdoor (For National Security Reasons "of course")
