via RSS

We had a cool discussion on full-disk encryption🔏 with @Szabo, Krisztian, @Menyhart, Zsolt and @Bordas Istvan. Let me share some of my takeaways.

Background: In corporate environments, employees use laptops, and when these laptops get inevitably lost/stolen, gigabytes of sensitive/customer data can be leaked. You are required to notify customers&regulators, who get pissed off, fines and lawsuits follow, etc. Therefore, it is a no-brainer encrypt to the whole drive of laptops. This protects against a thief using highly advanced technologies (e.g. screwdriver🪛😄) for removing the drive, inserting it in another machine, and thus circumventing OS level protection. If the thief cannot decrypt the data, you did not leak your sensitive/customer data. No compliance nightmare, you just lost some hardware. Of course, encryption does not count, if you put the decryption key in clear right next to the encrypted data.

Traditional full-disk encryption schemes (often used in Linux native LUKS) ask for a password before booting the OS:

• The machine boots from a small unencrypted part of the drive, and prompts for your password (or token, etc).
• A key is derived from the password; the rest of the drive is encrypted, and can be decrypted using this key.
• Going forward, data read from the drive is decrypted, data written to the drive is encrypted with this key transparently.
• Thus can the OS boot up, so you can login.

You may have seen BitLocker+TPM first boot an OS and then ask for a password. It works as follows:

• The master key is stored in the machine's TPM chip (Trusted Platform Module).
• During boot-up, TPM validates if key components of the machine have changed.
• If the hardware is the same, TPM gives access to the decryption key and the OS boots up and you can log in.

IMO this latter is fishy🐟:

• 👉 In the traditional setup the decryption key is not there, this forces the thief to break cryptography (considered impossible unless they have unrealistic resources).
• 👉 In case of TPM, it is a fair assumption that extracting the key from the TPM chip is beyond the capabilities of most attackers. However, in this TPM setup the thief can get to a running OS which has access to the decrypted data. Attacking such an OS when you have physical access to the machine is MUCH easier.

This is not a BitLocker vs LUKS thing; both can function in both setups.

This is not a TPM thing either; TPM can be set up to ask for a password before the OS boots up.

There are pros and cons for both the user entering the password and for storing it in the TPM chip; e.g. TPM chip's integrity check can 'lock' the drive to the given machine, and may even defend vs the 'evil maid' attack.

However, if a lost laptop's OS can boot up without any credentials, I am not sure on can confidently say: 'no worries, the drive was encrypted, no data is leaked'. Even if the thief cannot remove the drive, an OS login's security is just not in the same league as encryption.

What do you think?

This post was first published on Linkedin here on 2026-04-01.

This week was my last full week at Citi. It was more than thirteen years ago when I first walked in through the company's doors, and it was an incredible journey.

I am truly grateful to Citi. I have learned and grown a lot during all these years, I will always remember them as a beautiful and exciting period of my career. I would also like to thank all who supported, helped, mentored, challenged and inspired me throughout these years and thank all the great people I have come to know, and I have worked with.

Now it is time to move on and bid farewell, as new challenges await... Stay tuned! 😉

This post was first published on Linkedin here on 2026-03-23.

You may have seen news on vulnerabilities in password managers 🔐, posted in an Ars Technica article based on an ETH Zurich research paper.
Let me share some thoughts on these.

It is good practice to use password managers, they allow you to have unique passwords everywhere and the password manager keeps them safe. Today's mainstream password managers are online services, where many claim to be 'zero-knowledge' which means (while not a precise crypto term in this context) that no one, including the password manager company can access your passwords, even if they had a malicious employee or if they were hacked (or compelled by government, etc).

The researchers reverse engineered and analyzed multiple password manager services (including Bitwarden, Lastpass and Dashlane) and showed attacks where the above claim was not true.

• 👉 Some of the attacks are really nasty, resulting in e.g. full vault compromise (bad guy gets all passwords).

• 👉 Most attacks target not-so-core password manager features, such as key escrow, shared vaults or account recovery. When you are not using these or have these disabled, you are safe.

• 👉 The attacks rely on the password manager server being malicious. Some services claimed they don't adopt this kind of threat model (i.e. they don't assume that their own service can be malicious), but this sounds contradictory. If a company claims they cannot access the users' password vaults (see zero-knowledge claims above), this should cover the case when they are trying to do so.

The researchers proposed countermeasures for their attacks, and many of these have been already implemented by the services (as the researchers contacted them before going public).

I am somewhat skeptical here. While I don't think there is a fundamental conflict between security and efficiency, encrypting data at rest is an exception. Good encryption may outright prevent certain operations (like certain forms of sharing or recovery). On the long term, one inevitably needs to decide if they want social media features in a cloud service and allow it to access their data or have zero-knowledge (whatever it means). If a password manager starts including features like 'sharing', 'invites' and 'recovery', there will forever be vulnerabilities.

I would not advise anyone to stop using password managers, including those mentioned in the paper. Using a password manager, is way better than any other alternative.

Still, I prefer password managers to be offline tools and not password-manager-as-a-service, accumulating social media's sharing features. When it is about passwords, I really don't like sharing. 😁

Ars Technica article: https://arstechnica.com/security/2026/02/password-managers-promise-that-they-cant-see-your-vaults-isnt-always-true/

Research paper: https://eprint.iacr.org/2026/058.pdf

I prefer offline password managers which run locally and store the password vault in an encrypted file. This file can be synced with any cloud storage (dropbox / google drive / onedrive / etc). This makes the password manager more lean and focused, and the password manager does not have access to your encrypted vault, while the cloud storage provider does not know your master password.

Examples: password safe, keepass (open source, cross-platform), enpass, password gorilla.

I also know people who run a self-hosted bitwarden instance.

Note that I do not necessarily reject cloud / online password managers either, I just put them into a different bucket.

I have also experimented with Google's cloud password manager (also built into Chrome) and I think it has become pretty good in its own class. If one wants to get started with minimal effort, it might be a good solution.

/Passwords may have many flaws, but they are supported everywhere. I am not deep into tools - both hardware or services - that promise you to get rid of passwords, but my experience is that when you try something like that you will eventually run into a technology that doest not work with it.../

This post was first published on Linkedin here on 2026-03-08.

I teach in a cryptography course at AIT Budapest 🎓, where I have a set of lab demos on PKI and TLS. I wrote some terraform code to spin up a couple of websites on Google Cloud with various states of TLS (no TLS, cert for a different domain, incorrectly set up TLS, good TLS, etc) and demonstrating certain attacks. The code is very simple and basic: create VM ➡️ register DNS name ➡️ obtain cert using certbot ➡️ install demo PHP app and configure the TLS site the way I need it. Terraform is handy as it allows me to do & undo all these quickly as bulk and only pay Google for a few days of use.

I have been using this for many years (started pre-covid), I mostly run it once each semester and sometimes a few extra times when I am experimenting.

In theory, infrastructure-as-code (IaC) allows you to write code once, and use it infinitely for recreating the same environment later. In theory, theory and practice are the same. In practice they are not. Sometimes:

• 👉 CSP settings change, and e.g. the Google VM I had been going for is no longer 'free tier' and starts charging money.

• 👉 Software/packages come and go, and e.g. the Debian version I used to install a few years ago is no longer available, so you need to adjust your IaC to use different software.

• 👉 Libraries/languages may change their syntax (e.g. PHP😡), so the same code you had years ago no longer runs on a new PHP version.

• 👉 Sometimes default configuration settings change. For example, when certbot made the Strict-Transport-Security mainstream (webserver tells browser never to allow plain http for the site), it was a great security improvement, so this is good... unless it is a vulnerability you want to demonstrate.

• 👉 Sometimes browsers start behaving differently (and e.g. refuse to connect to the sites where you would demo broken TLS).

IaC is great, terraform is fun, this all works and saves a lot of time. I just want to highlight that it is not 'write once, infinitely reuse', but you need to maintain it.

TL;DR: Infrastructure-as-code still requires you to spend time maintaining your infra; you no longer need to maintain your legacy tech stack you know, but you maintain a complex system of ever changing dynamic tech stacks. 😆

Our course at AIT Budapest.

This post was first published on Linkedin here on 2026-03-01.

In his novel Player Piano, Kurt Vonnegut shows a dystopian society split into an upper class of engineers (who make machines which make further machines, etc) and a lower class of people who... just don't matter. The extremely mechanized/automated economy requires very few engineers to operate, and those not smart enough to engineer and build improved machines have bullshit jobs like perpetual road reconstructions, or they can join the army or devote themselves fully to alcoholism. The lower class who makes most of the population are not left to starve, but it is made very clear to them that they cannot contribute and don't matter at all. https://en.wikipedia.org/wiki/Player_Piano_(novel)

With today's massive push for AI, the doomed revolution in Player Piano comes into my mind increasingly often. This book has become surprisingly relevant...

Are we really heading this way?

"The function of science fiction is not always to predict the future but sometimes to prevent it." (Frank Herbert? Ray Bradbury?)

Looking backwards, the dystopian sci-fi of the past just too often turns out to be an accurate description of what happened later.

This post was first published on Linkedin here on 2026-02-09.

More entries...