All information herein is the view of the author. Use at your own risk, no warenty of any kind is provided.
Intro and Contents:

This page is intended to help point out some of the issues with information security when using the internet. The goal is not to scare anyone, though rather it is to help inform people of what they can do to improve the safety of there information when using the internet, or a computer that is connected to the internet or connected to a system or network with a system that is connected to the internet.

Many people think that it is safe to send encrypted information around the internet, relying on public key private key encryption to send semetric keys around. This is not as true as most people think it is, as the public/private key encryption is far from 100% and there are other attacks that can get around the issue of encryption. There are still ways to keep secure and send secure data over the internet, which will be looked at in this document, it takes more work and relies on the person recieving the data taking equal levels of extra work in order to be secure. For online commerce there is also one solution given in this document, that protects your financial information.

There will be those that will be very vocal, and attempt to say that indeed systems are more secure for communications. The problem is that this is just a restating of what the security selling companies want you to hear. They go to great lengths to assure there customers and all others that the systems provide true security (they are in business to make money after all), this has been proven to be untrue so many times it is not even funny. If you wish, take the time to do your own research, find out what exploits exist for what areas, compare with what I say herein, you will likely be surprised that everything here is indeed well researched.

CONTENTS:

  • Why Online Encryption Is not Secure
  • How to Securely Send Information Over the InterNet
  • Rules of Conduct to Stay Safe Online.

TODO: Relicense this page under permisive license.


Why Online Encryption Is not Secure:

There are a number of issues with the way that online encryption is normally done. The most significant being that it relies on Public Key Private Key encryption to exchange keys to use with the better semetric key encryption algorithms. Even with the added security of a key exchange algorithm, this is still not enough. Then even with the more secure semetric key encryption algorithms, they are only as secure as is possible by how long it takes to brute force reverse there message in, which is dependant on the processing power of computers, thus all currently secure algorithms will one day be non-secure as the performance of computing continues to improve at exponential rates.

Also remember that no mater how you transmit your data, an attacker is likely to just capture the entire stream of communications in order to later figure it out. This is true regardless of if you are using a VPN or TOR network or any other. An atacker that is able to capture the entire stream you are sending and recieving at the node that is your local network will have tools available to them to figure out the rest.

The biggest part of the problem is that the means for exchanging keys is not very secure. This is a problem as the encryption methods that are very secure are all semetric key encryption algorithms (that is the same key is needed to decrypt the message as was used to encrypt it).

From the Side:

There is the issue that the data being sent, even if sent encrypted, exists in at least two places completely plaintext (without encryption). One is on your computer, the other is on the recieving computer, in both cases at least somewhere in the system RAM for a time, then likely in files on both ends. Thus if an attacker were to gain administrative / superuser access to either of these systems they would not need to worry about the encryption at all.

As a direct side effect of how complex modern Operating Systems and other Software Systems have become, there are bugs that provide security holes (unintentional back doors) being descovered all the time. Do to the complexity of these systems, it is unlikely that every security hole will ever vannish, as the complexity makes it likely that while fixing other bugs, and adding features more bugs will be introduced, and some of these will allow for security holes.

It is easy to look through the past exploited security holes to see how bad this situation is. There have been three major ones in the Linux kernel over time, one in the bash shell (that was there for 25 years before it was found), and many more. Most of these made administrative level access by unauthorised parties possible. There have also been many on other platforms, most notably a decent number in the Win NT line of OSes by MS (including 2000, XP, Vista, 7, 10, 11).

Public Key Private Key Problems:

The issue with using public key private key encryption is that it is based on arithmatic relationships, and relies on the complexity of solving the method as its security. Currently there do not exist any publicaly known public key private key encryption algorithms that are secure enough not to be easily calculated by a modern personal computer in a reasonable period of time.

Even if there did exist an algorithm for public key private key encryption that was currently secure, we as humans are good at figuring out more effecient ways to solve problems of arithmatic. Thus it is that it would not be likely to remain secure for very long.

Key Exchange Algorithm Problems:

UPDATE:

There exists a currently secure key exchange algorithm that is public knowledge. While it is true that the DiffieuHellman key exchange fails at this, there exists an alternative known as the Elliptic-curve Diffie-Hellman algorithm. The Elliptic-curve Diffie-Hellman implementation is computationally intense enough to be non-practical to crack at this time. There is also the Supersingular isogeny Diffie-Hellman key exchange, that is even less likely the be cracked.

Both the Elliptic-curve Diffie-Hellman and Supersingular isogeny Diffie-Hellman have the flaw that they are dificult to implement, and computationaly intensive to use, it takes a lot more CPU clocks than reasonable to achieve the desired goal with either of these algorithms. It is doubtful that any energy effecient HW implementations of these will be seen, do to the nature of the algorithms.

Also remember that just because they are currently secure does not mean they will remain so. They are based on arithmatic relationships, and as such eventually someone is likely to figure out an usably effecient algorithm to reverse them. Humans are very good at finding more effecient ways to figure out arithmatic problems, this is part of the the nature of our species.

END UPDATE

In a bit of irony this suffers from many of the same problems as public key private key encryption. Key exchange over an open media (like the internet) requires some shared known information. Thus there is no way that it can be maintained 100% secure and used accross many systems, it is not possible as the relation ship will be able to be calculated.

Block Ciphers:

Block ciphers suffer from the fact tha they can reasonably be reversed to find the original key. With an ideal block cipher this would take brute force computational time, which should be long enough to be impractical on current systems. Though systems will continue to improve in speed over time, thus reducing the security of block ciphers.

As these are a case of semetric key ciphers, you need a secure way to exchange the key between both ends of the communication. As shown above this can be problematic.

Stream Ciphers:

An ideal stream cipher, with an ideal PRNG would be truely uncrackable given well thought keys. This do to the fact that such a stream cipher would be an ideal emulation of a one time pad. Of course the currently known stream ciphers are not 100% ideal.

Of course all stream ciphers, including the ideal One Time Pad, suffer from one well known vulnerability. That is that if the message at a given point within the stream is known to the attacker they can reverse the key stream for only that part of the message and replace it with something of equal length without being detected. This does not break the cipher by any means, as it only applies to the part that the attacker knows the exact contents and offset in the stream. There is not as yet a publically known good way around this (there exist at least two ciphers that are technically stream ciphers that do more processing to prevent the order from being easily known, though neither is public knowledge at this time).

Again there is the issue of how to get the key over an unsecure media in a secure manner. This is the biggest part of the problem of all possibilities.


How to Securely Send Information Over the InterNet:

At this time there do exist secure encryption algorithms, and these will remain secure until computer processing power has increased by a good deal. The encryption algorithms that would take longer than 50 years to crack on the best high end super computers of today are those that are secure within block ciphers. Stream ciphers can be even more secure, so long as there is 0 possibility of an attacker knowing the offset in the stream of a given peice of information that may be important not to be changed.

Though the strong encryption algorithms are useless for normal use over the internet. The reason being that they are all semetric key ciphers, and thus the key needs to be sent. The only means of sending the key simi-securely are easy to crack for someone that captures the entire communication both ways, and has some basic understanding of cryptology and cryptoanalisis. So it would look pretty dim, though there is some hope.

There is also the issue that the information may be obtained from either of the systems where it exists as plain text.

If you wish to send protected information to someone that you trust with the information, you need to have a means to securely send the key without using the internet or other digital or electronic communications. This may be an agreed upon means of encoding it in a paper leter, or some other method. Then you would need to encrypt the information on a computer that is never attached to the internet, using a known extremely secure encryption algorithm (we avoid the external access to the plaintext version), and the person recieving the message would transfer it to a computer that is never attached to the internet in order to decrypt it.

Online Purchases: It is not possible to make online purchases and keep the information protected, for the reasons already descussed. Though you can have a reasonable level of security if you use only one time usage VISA or MasterCard gift cards that you purchase with just enough for the online purchase (purchasing the gift cards in person in store using cash). If you do not want potential listeners to know your physical address, get a PO box for purchases made over the internet.


Rules Of Conduct For Online Data Safety:

Here are some simple rules to help out.

No Private Information on The Internet: First and formost is the advice that many have repeated, and repeated often, do not put personal, private, or otherwise needing to remain protected information on any computer that is on a network that connects to the internet, or is otherwise accessable from the internet. This is the most important thing when it comes to the security of your information. Obviously if you folow this one you also follow the rule of   Never Send Personal or Protected information over the internet.

Take care in seperation of Encryption: If for some reason important information that requires security must be sent over the internet to someone you trust, then you should use a proven encryption algorithm, transmit the key directly witout using a computer, and encrypt the information on a computer that is not accessable to the internet in any way. Then the person recieving the information should take equal levels of precaution, and decrypt the data on a computer that is never accessable to the internet in any way shape or form, and never allow the data on a computer that is attached to the internet in any way shape or form. Even in this case keep in mind that it is possible for the data to be intercepted, it is just hoped that if someone intercepts it it will never get decrypted (hence never passing the key near a computer that has a net connection of any kind). Again in this situation be sure of the algorithms security, and transmit the key directly person to person, without using the internet or digital comms in any form for the key.

Do not Trust Key Servers: This should be obvious by now. I will repeat that the methods for sending keys that are simi-secure are still fairly easy to break. And even if new methods are developed that are more secure, they will rely on some form of known information or arithmatic relationship, and this will always provide a way for people to figure out how to make them easy to crack. There have been many examples demonstrated of how this can be done, it is not as difficult as the security selling companies want you to think.

Do not use an external program to process Internet Related Comms: For any program that provides internet comms of any form, do not allow any said program to ever use a third party program to process the information. It is possible that even a program as benign as a command shell could allow unwanted access. To be clear this is speaking of using applications that are not designed to be secure, or are not designed with internet communication security in mind. Unfortunately there is a lot of widely used server software that does call out to programs that are not internet oriented, and thus risk introducing bugs (like using shell commands and similar big no go code).

Never allow remote logins over the internet: Any software that allows remote login to the OS (VNC, SSH, etc) should never be allowed on any system, or network, that is connected to the internet, regardless if it is a server or just a client desktop. Any administration of serever software that requires OS acces is done at the physical terminal that is part of the server only. There should never be any software that includes the ability to remotely log in regardless of the user priveledge level (that is login to the OS or another equilivent that gives use of the OS directly).

Do not allow code that can modify: For server software; do not allow any code that is able to communicate over the internet to include code that can write to any part of the FS outside of the data subdirectories that compose the data being served. Verify and tripple check that there is no possible way that the software could be configured to break this rule, as it is a potential huge source of bugs.

Non-Net Software stays off the net: If a programs purpose is not related to the use of the internet, then it should have ZERO reason to access the internet. A program that does not need the internet for its purpose should never contain any code that access the internet, I do not care if it is just launching a web browser pointed at a net url, it should not be allowed to have such code. This is one area that increases the risk of bugs, allowing non-network applications to have access to the net is a very bad idea.

Verify: To what ever extent is possible for your level of computer usage and knowledge, please verify that the above rules are strictly followed by you and any software you use.

CLOUD is temporary and public: Regardless how 'secure' it may be advertised as being, cloud computing is still sending data over the internet. Thus it should only be public data on a cloud server, and it should be remembered that even they fail, and your data may be lost.

VPN and TOR only help with Anonymity: VPN can aid in staying anonymous in some situations, though it is a minimal help and does not add to the protection of data sent or recieved. TOR is even a better solution to help with anonyminity as it also aids in keeping your location anonyminous, though this is only helpful when a potential attacker is not able to capture the stream at the source.