Blog

I was really keen to attend one of the (ISC)2 SecureEvents: The SecureCEE Conference 2016 in Prague. Read on if you are interested in current security trends!

As our latest project has progressed we encountered a strange obstacle: there is no portable way to determine file inode number in Racket. That would not be much of a problem, but as we tried to dynamically link stat-like functions from libc using ffi, we found that each platform and glibc version has different ABI - including the sizes of various stat structure fields. So we dived into writing extensions in the C programming language.

In one of our recent projects we are working hard to be able to detect filesystem changes that may indicate substantiate increase in the number of encrypted files. There may be several hints that given file contains encrypted data and one of the most prominent properties of such file is its high entropy. But how to measure it? And how to measure it effectively? In this post we will look into a relatively simple statistical analysis of file data that can shed light on its entropy. The only problem here is there are no readily available software solutions to do this.

As I have had to give a talk about elliptic curve cryptography for the testing community in Czech Republic at the regular pro[test] event held in Prague two weeks ago, I wondered what could be actually tested about ECC in real-world scenarios. As I was digging through my notes, I realized there is something everybody really hates - waiting for web page to load. And with HTTPs everywhere now the crucial part slowing the whole browsing experience down is how fast the connection can be established. That is because encrypted connection requires exchanging quite a lot of information at the beginning and can go on without much overhead afterwards.

Striving for high-availability of some software systems requires ensuring their individual components are reliable and usually redundant. A typical example of such component is a SQL database - MariaDB being the case we had to handle this time.

We decided to go for MariaDB Galera cluster on CentOS and I would like to write about our experience here. We have chosen active-active (master-master) design with two nodes called nodeA and nodeB having IP addresses 192.168.0.1 and 192.168.0.2 respectively.