A Note On Playing Back Commercially-Recorded Blu-rays

Just as it was with DVDs, when movies first started to be distributed in that format, commercially-recorded Blu-ray disks today use an encryption system, which is sometimes referred to as ‘content scrambling’, to prevent people from making unauthorized copies. It’s actually named ‘aacs’.

Experts already know about this, but I’m putting this in layman’s terms for anybody who might not.

Basically, Blu-ray playback-devices have a hidden store of public keys, which the users are not allowed to access, and this time, the company is able to update that store of keys via the Internet, because most Blu-ray players today are also online devices.

Unlike how it is with Blu-rays, the content-scrambling system of DVDs was famously hacked. This means that Linux computers are well-able to play back Movie-DVDs. OTOH, the ability to play back commercial Blu-rays, is mainly unsuccessful on Linux computers, or on any other unauthorized devices, because the content-scrambling which gets used – was never hacked. As long as the encryption continues to work, Linux users and pirates will not be able to play back or rip Blu-rays.

As it stands, the company is able to revoke public keys which it was once using.

This is a shame, because some Linux users might only be wanting to view Blu-ray movies which they purchased and paid for. But the main fear of the industry remains, that as a platform, a Linux computer is more susceptible to an unauthorized copy being made of anything, which that Linux computer would also be able to perform authorized playback of.

Therefore, when I gave instructions on how people can record Blu-rays privately, my assumption was that we would not be using any encryption. I don’t see encryption as being important in any way, for home-movies which people might shoot. But, the Blu-ray folder must nevertheless contain a sub-folder named ‘CERTIFICATES’. In the example I wrote about, this sub-folder will simply remain empty.

Further, the mere use of the Blu-ray (single-layer) disk, as a step-up from DVD+Rs, where a Blu-ray can store up to 25GB of pure data instead of 4.7GB, is unfettered for Linux users to use as they wish. All we need is an external Blu-ray burner, and we’re all set to burn pure data. But as soon as we want to burn something using ‘UDF’, which is the approved file-system of Blu-ray players, the level of difficulty already increases, even though no encryption has been used yet.

(Updated 09/19/2017 : )

Continue reading A Note On Playing Back Commercially-Recorded Blu-rays

K-9 Mail is the way to go!

In this earlier posting, I had started to document, how under Android, I had been using the email-client “Kaiten”, which years ago, when I had started using it, was a paid-for alternative to the program “K-9″, in return for which I had expected regular updates.

But as it happened, Kaiten has stopped receiving support, while K-9 continued to receive the updates.

One of the features sorely lacking in Kaiten, was PGP/MIME support. Kaiten was limited to signing or encrypting emails using Inline Signatures, while the modern way to go about it is using PGP/MIME. Also, I’ve been receiving emails, which have also progressed to being signed with PGP/MIME, which Kaiten could not interpret.

And so just this morning, I made the switch on some of my Android devices, to K-9, which has PGP/MIME Support.

When using K-9, one no longer uses the companion app ‘APG’, but rather the companion app “OpenKeyChain“, to perform the cryptography.

Because K-9 actually accepts the configuration files exported by Kaiten, the switch was easy to carry out.



Bluetooth Dissed

One argument I hear often from laypeople, is that they don’t like Bluetooth, because at the user-level, Bluetooth Pairing is hard.

People who are knowledgeable in Computing understand, that every time we create a Bluetooth Pairing, our devices are establishing a communications channel, which is as secure as the authors of Bluetooth can make it, due to Advanced Encryption. So we see that there is a potential benefit to this.

For example, in the case of a keyboard which is connected to a tablet – which means that a BT session is underway – it can happen at any time, that we type in our password to unlock the tablet, or to unlock any of our accounts on the Internet. That could be made a generic wireless link which is extremely easy to set up. But then, since we’re always weary of an eavesdropper, the link would be of an ideal format, to steal all our passwords from us through direct exploitation.

But because we’re using Bluetooth, in fact it’s an encrypted link. So even if the ones and zeroes that make up a communication were intercepted, the hypothetical eavesdropper would still not be able to exploit them.

And so I can empathize with knowledgeable people, who feel that the added difficulty in establishing a Bluetooth Pairing, is well worth the effort.

Continue reading Bluetooth Dissed

Some Notes on the Merits of Hybrid Encryption

In my most recent postings, I sort of took the perspective, that ‘RSA’ is the only form of public key cryptography. But in reality, this is far from true.

As far as the actual public-key methods go, there is also ‘El-Gamal’ and ‘Diffie-Hellman’ in public use, as well as ‘DSA’. The last of those is only useful for signing, not for encrypting. But what that means in practice, requires that people understand another concept in public-key cryptography, which is called ‘hybrid encryption’, which marries one of the public key exchanges with strong, symmetrical encryption. Symmetrical encryption is any scheme where the same key can be used to decrypt, which was used to encrypt. Symmetrical methods in use include ‘AES’ and ‘Blowfish’, and several others.

A concept which exists purely with RSA, is that a sender of a message can use the public key of the recipient to encrypt, so that only the recipient will be able to decrypt, using his own private key.

Well, if we consider SSL-secured Web-sites, we do not see that our Web-browser needs to build any public and private key-pairs. And so according to that, it might be imaginable that the server has a public key to receive data with securely, but it is not obvious how the browser receives data securely from the server. And what actually happens with SSL, is that a pseudo-random key is built essentially by the client, and is then sent to the server securely via RSA. That key is then used by both peers, to send and receive the actual user data via strong, symmetrical encryption. And this idea, of only using public key-exchange to encrypt a strong, symmetrical key once per session, is referred to as hybrid encryption.

This also makes sense from the standpoint, that a single public-key, RSA encryption requires much more CPU time, than the repeated use of AES aor Blowfish.

TLS key exchange is based on methods, that more closely resemble Diffie-Hellman than RSA, but again forms a basis of hybrid encryption.

And this is also why SSH, which is also known as ‘Secure Shell Protocol’, only requires that the client have a DSA key. Given that an SSH client uses his public key to authenticate himself, in theory an SSH server can be set to allow RSA authentication, but then all the client must do is to encrypt a piece of data which he cannot control, using his private key, to prove to the server that he is in fact the owner of a stated public key.

Hence, for SSH authentication, DSA works just as well for the client to use.