Waiting for background tasks to finish using the CompletableFuture class in Java


In this post we saw how to wait for a number background tasks to finish using the CountDownLatch class. The starting point for the discussion was the following situation:

Imagine that you execute a number of long running methods. Also, let’s say that the very last time consuming process depends on the previous processes, let’s call them prerequisites. The dependence is “sequential” meaning that the final stage should only run if the prerequisites have all completed and returned. The first implementation may very well be sequential where the long running methods are called one after the other and each of them blocks the main thread.

However, in case the prerequisites can be executed independently then there’s a much better solution: we can execute them in parallel instead. Independence in this case means that prerequisite A doesn’t need any return value from prerequisite B in which case parallel execution of A and B is not an option.

In this post we’ll look at an alternative solution using the CompletableFuture class. It is way more versatile than CountDownLatch which is really only sort of like a simple lock object. CompletableFuture offers a wide range of possibilities to organise your threads with a fluent API. Here we’ll start off easy with a simple application of this class.

Read more of this post

Sharing primitives across threads in Java using atomic objects

Threading and parallel execution are popular choices when making applications more responsive and resource-efficient. Various tasks are carried out on separate threads where they either produce some result relevant to the main thread or just run in the background “unnoticed”. Often these tasks work autonomously meaning they have their own set of dependencies and variables. That is they do not interfere with a resource that is common to 2 or more threads.

However, that’s not always the case. Imagine that multiple threads are trying to update the same primitive like an integer counter. They perform some action and then update this counter. In this post we’ll see what can go wrong.

Read more of this post

How to hash passwords with a salt in .NET

In this post we learnt about using hashing in .NET. We also saw one of its basic functions in the same post which is message verification. In this post we saw how hashing coupled with a random key can be used for message authentication.

We also mentioned another common usage of hashing which is password storage. A password should never be stored as clear text in your system. Instead we save its hash value and when a user enters a password in a login field then we compare the hashed values instead of the plain string passwords. However, a simple one-way hash is generally still not good enough.

Read more of this post

Using HMACs to authenticate a hash in .NET

In this post we learnt about using hashing in .NET. Hashes provide a one-way encryption of a message where the hash value ideally cannot be “unhashed”, i.e. we cannot build the original string from it. A hash or message digest helps us verify whether the message has been tampered with by a third party after it was sent to us.

We can take a step further and add an extra layer of security on our hashes. After all a message and its hash could originate from anyone. How can we verify the authenticity of the message as well? That’s where Hashed Message Authentication Codes, also called HashMACs or HMACs enter the picture.

Read more of this post

Hashing messages using various hash algorithms in .NET

A hash of a message can be viewed as its unique identifier. A series of bytes, such as a string, can be converted into hash, also called a message digest. A message digest is also a byte array that can be converted into a base 64 string for better readability. There are various hashing algorithms out there that can calculate the hash of a message. Ideally each algorithm should produce a different digest for each message, i.e. “Hello world” should yield a different hash from what “H3llo world” produces. I.e. a single change in the byte sequence will change the resulting hash. Also, it should be impossible to calculate the original message from a hash. Therefore hashing is a one-way cryptographic operation.

Read more of this post

How to store the asymmetric keys in the Windows key store with C#


In this post we briefly looked through asymmetric encryption in .NET. This encryption type requires two keys as opposed to symmetric encryption where the same key is used for encryption and decryption. In asymmetric encryption we have a public and a private key. The public key can be distributed so that other people can encrypt their messages to us. Then we use our private key to decrypt the ciphertext and read the original message. Therefore we don’t have to worry about the public key getting into the wrong hands. On the other hand asymmetric encryption is significantly slower than symmetric encryption due to the higher mathematical complexity.

In the post referenced above we saw how to store the asymmetric key-pair in an XML string. You can save this string in a file or database for later retrieval. There’s at least one more option for storage which is the cryptographic key store on Windows. We’ll go through how to use it in this post.

Read more of this post

Overview of asymmetric encryption in .NET


Asymmetric encryption is based on a pair of cryptographic keys. One of the keys is public, i.e. anyone can have access to it. The other key is private which should be kept secret. The keys are complementary which means that they go hand in hand, they are not independent of each other. If a value is calculated as the public key then the private key cannot be calculated independently otherwise the encryption process will fail. Normally the public key is used to encrypt a message and the private key is there for the decryption process but they can be used in the opposite direction as well. Asymmetric algorithms are also called Public Key Cryptography.

The most important advantage of asymmetric over symmetric encryption is that we don’t need to worry about distributing the public key. The key used in symmetric encryption must be known to all parties taking part in the encryption/decryption process which increases the chances of the key landing in the wrong hands. With asymmetric encryption we only need to worry about storing the private key, the public key can be freely distributed. For a hacker it is not practical to attempt to calculate the private key based on the public key, that is close to impossible to achieve.

However, asymmetric encryption is a very complex mathematical process which is a lot slower than symmetric encryption. Also, storing the private key can still be problematic.

Read more of this post

Overview of symmetric encryption in .NET


A symmetric encryption algorithm is one where the cryptographic key is the same for both encryption and decryption and is shared among the parties involved in the process.

Ideally only a small group of reliable people should have access to this key. Attackers decipher an encrypted message rather than trying to defeat the algorithm itself. The key can vary in size so the attacker will need to know this first. Once they know this then they will try combinations of possible key characters.

A clear disadvantage with this approach is that distributing and storing keys in a safe and reliable manner is difficult. On the other hand symmetric algorithms are fast.

In this short overview we’ll look at the symmetric encryption algorithms currently supported in .NET.

Read more of this post

An overview of digital signatures in .NET


A digital signature in software has about the same role as a real signature on a document. It proves that a certain person has signed the document thereby authenticating it. A signature increases security around a document for both parties involved, i.e. the one who signed the document – the signee – and the one that uses the document afterwards. The one who signed can claim that the document belongs to them, i.e. it originates from them and cannot be used by another person. If you sign a bank loan request then you should receive the loan and not someone else. Also, the party that takes the document for further processing can be sure that it really originates from the person who signed it. The signee cannot claim that the signature belongs to some other person and they have nothing to do with the document. This latter is called non-repudiation. The signee cannot deny that the document originates from him or her.

Digital signatures in software are used to enhance messaging security. The receiver must be able to know for sure that the message originated with one specific sender and that the sender cannot claim that it was someone else who sent the message. While it is quite possible to copy someone’s signature on a paper document it is much harder to forge a strong digital signature.

In this post we’ll review how digital signatures are implemented in .NET

Read more of this post

Sharing numeric values across threads using Java 8 LongAdder

In this post we saw how to share primitive values across threads using the various atomic objects in the java.util.concurrent.atomic package. The example code demonstrated the AtomicInteger object which is the thread-safe variant of a “normal” integer. Mathematical operations like adding a value to an integer are carried out atomically for that object. This means that the low-level instructions involved in adding two integers are carried out as one unit without the risk of another interfering thread. The same package includes atomic versions of other primitive values such as AtomicBoolean or AtomicLong.

In this post we’ll take a quick look at an addition in Java 8 relevant to sharing integers, longs and doubles.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

HarsH ReaLiTy

A Good Blog is Hard to Find

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: