Löfberg Me – Löfberg's thougts on tech

Can I trust this binary? After downloading an executable file of pre-compiled code a sensible question to ask yourself before running it is, do I trust this code? Correction, even before downloading the executable you should probably already have asked yourself that question.

Trust, but Verify

How do we know if we can trust software? Let’s start by to categorizing the software into a couple of categories (closed source and open source software) to make it easier. The difference between these two is whether the source code is freely available (open) or not available (closed).

Closed Source

If it is closed source there is a lot of trust involved since it is a lot harder to verify that the software does what we’re told it should do and only does that. For this kind of software the reputation of the entity providing it becomes more important. Some things to consider are if they have a history of a lot of bugs, if they are well-known and trusted and if they are a business what is their business model?

Buggy software is not great but if the bugs are all resolved quickly that could be something which increase our trust in that software. It might also indicate that the software has a lot of technical debt and more bugs are going to be found (this is true for any software). Another factor is the severity of the bugs, are they just minor inconveniences or are they serious, for closed source software this can of course be harder to find out, if even possible.

Reputation might be easier to find information about, for example, is the software the de-facto software to use for that purpose? In that case it is to a certain extent trusted by many people and arguable somewhat capable of coding software which does something well.

If it is a business, how do they make a profit? If you’re not paying with money, you’re paying with something else most likely holds very true in this case. There is of course software which provides limited functionality and hoping for an up-sell to the paid version of the software. But if the whole software or service is free, how do they make money?

It is not so easy to verify that closed source software only does what it is suppose to do. However some approaches is to monitor the program when it is being run, you could take a memory dump, you could try to see run it with a debugger or monitor the network traffic for any packages it is sending and/or receiving. There are most certainly more methods than the ones I have mentioned here and I hope to explore more of them in the future.

Open source

When it comes to open source the source code to be scrutinized and anyone can try to make a contribution or in theory verify that it works as expected. This should make it a lot easier to verify that the software does what it is suppose to do. Given that you have the expertise it certainly is easier to validate the code but in practice how much of the software is checked? How much of it is maintained? Are you going to read hundreds or thousands of lines of code to verify the functionality? In other words, if the code is there to verify but nobody verifies it, is it really verified?

There certainly is quite a bit of trust involved for open source too since it is not feasible to check every software yourself. However, if you find a bug or suspect that the software has some side effects the source code is there for you to verify it. You could even fix it, submit a bug report and a suggested fix for it. This of course is not possible if the project is abandoned but in those cases it might be that it has been forked and is maintained by someone else or you could fork and maintain it yourself.

In Closing

Regardless of the software being open or closed source there is a certain amount of trust involved. Depending on how much you trust the software you might want to treat it in different ways. If you don’t trust the software a good option is to run it in a virtual machine where you can keep it isolated. Some other good practices is to verify the SHA-1 signature of the file to ensure the downloaded file is the same as the one provided.

These are some of the aspects I think are worth considering and there is assuredly aspects which I’ve missed. If I’ve made any obvious blunders or missed out on some important aspect let me know.

Atbash is a naive cypher for encrypting and decrypting a message by substituting each letter in the message with their reverse letter in an alphabet. The beauty of it is its simplicity, anyone can easily understand and use it.

To encrypt with atbash the only thing we need is an alphabet or a bit more formal.

A set of characters
In a defined order

Each character needs to be unique otherwise it is not possible to encode and decode the message in a deterministic way. Consider for example if we had the alphabet A B A C B D and the letters A and B, since both of them appear more than ones in the alphabet it is not possible to know which position of the letter we’re referring to. This is why it is important that each letter is unique.
The order of the alphabet is also important, since the first character maps to the last character, the second character maps to the second to last character, etc.. If we don’t care about the order the encryption and decryption won’t match up. Thus we need to either create an alphabet or use an alphabet which fulfils both of these rules.
As our luck would have it the Latin Alphabet fulfils both of these criteria (unique and ordered). It is of course possible to define your own alphabet by adding characters, changing the order of the characters or by removing any of the characters.

Example

If we have an alphabet with only upper-case letters we would end up with the following alphabet and reversed alphabet.
Alphabet A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Reveres Z Y X W V U T S R Q P O N M L K J I H G F E D C B A

To encrypt a message we would simply look at each letter in the alphabet and then replace it with the letter in the same position of the reversed alphabet, for example, A becomes Z, B becomes Y, C becomes X, etc..
To decrypt the message the reverse is applied.

Let’s encrypt the following message HELLO WORLD which then becomes SVOOL DLIOW. To decrypt it we would then do the same procedure but this time starting from the reverse and finding letters at the same position in the alphabet.

Message HELLO WORLDReversed SVOOL DLIOW

Limitations

There are some limitations to keep in mind when using Atbash. First of all, all the characters we want encrypt and have in the message needs to be part of the alphabet. This means that if we want to encrypt punctuation and numbers we need to make it part of the alphabet. If, however, we’re not interested in encrypting these characters they an be excluded from the alphabet.
Furthermore it is not a very safe encryption method since each encrypted letter only has as many possible encryptions as the number of characters in the alphabet minus one, since one character won’t map to itself. Given a big enough sample of an encrypted message the chance of every letter used in the alphabet increases. From there some usual methods of looking at how often characters appear and in what context can be used to decrypt the message.

Final Words

Atbash is has a beautiful simplicity to it. It can easily be understood and implemented. It is so simple that you most likely could use it when writing a message by hand. It is not to be considered to be a safe way of sending sensitive information but a fun thing to use. It will if nothing less leave the people who are not aware of it confused for a short while.