Racing to the End: Encrypting, Creating, Reflecting (Week 10)

Apr 27, 2019

Hello blog readers to week 10!

From last week’s choices of encryption libraries, I decided to go with BouncyCastle. Moreover, it turns out that it is an extension of Java’s native classes, meaning that we have to use it in accordance with javax.crypto. I was unable to use Tink (by Google) as it lacked support for RSA encryption, which would entail using different standards for this application. Since this application is fairly modularized, anyone should be able to pick it up and add a new replacement class for Tink or any other library, if need be in the near future. As in all applications, constant updates are necessary, and it is nice that we have this feature built into the application.

As the clock ticks to the finale of the project (Week 12), I am racing against time and attempting to finish everything to be able to present a working demo to Mrs. Bhattacharya and the other senior project administrators. It will take a while, but I am confident I will be able to show something to them. With the limited time remaining, I decided to spend the most time on the underlying code itself and make a basic GUI for now. If I have time, I’ll be improving the GUI as well.

I also worked on creating a socket listener and receiver between two machines. It looks like it seems to work. I would like to look at the WebSockets standard in the future, but for now my simple implementation should suffice for this prototype.


While reading an article, I came upon an important piece of advice. While I wasn’t able to use the actual code part of this website, it mentioned that 256-bit and smaller keys are not suitable for encryption. In encryption, there is usually a key that is used to garble the text and that key is the only way it can be reversed. The article mentioned it is not favorable to use “small” key sizes as it “takes less than 30 minutes to crack on a standard desktop PC”. In cryptography, even 256-bits is a big key, enough to overflow a basic Java “int” and to take an extra few seconds when encrypting/decrypting on normal computers (unfavorable for people using encrypted hard disks on their computers). The more surprising thing is that 256-bit used to be a standard just around 10 years ago.

To look at this, we can look at Moore’s Law. As predicted by Moore, once CEO of Intel, transistors in a computer circuit double every few years. This observation can be extended to processing power and the ability to hold large amounts of data. With more and more computers (including phones) becoming exponentially faster than a high-powered PC of just a few years ago, we see old standards not working today. Additionally, cloud computing and rising internet speeds has allowed users to offload tasks very easily onlineĀ to the big data centersĀ of Amazon Web Services and Microsoft Azure. As cryptography is not 100% unbreakable, and in fact just a time-consuming process to crack (in the hundreds/millions of years), it is very possible that a certain quantum computer or even normal upgraded machine can crack today’s military encryption standards. After all, previously known standards from the 1990s and early 2000s such as MD5, DES, and SHA1 have been rendered insecure and vulnerable against the most novice hackers.

While this may seem like a long explanation, it is one of the biggest reasons why constant upgrades and easily upgradability is stressed in the cryptography world. It also shows us that one cannot be comfortable with a particular algorithm, as it will be cracked by new advances in computing just in a few years.

Leave a Reply

Your email address will not be published.