Isaac Mok

 Hello there. Isaac here. So over the weekend I've been trying out Bun for a school project (a simple Koa API server from scratch). I didn't really have a project on hand I could benchmark against to compare Bun to Node. Any speed difference I felt could've just been placebo, really. I do enjoy using Bun though even if we disregard the speed part, but I wouldn't say that Bun is good enough to warrant replacing my existing projects using Node. Most of the pros I experienced boils down to convenience. Bun has many features bundled with it that would've taken some time to install using Node. Below is a list of said features and packages I would've needed to install in Node: Running TypeScript files ts-node typescript (Ended up installing it anyway for linting) Hot reload nodemon Running tests jest (I've only used mocha before, but I assume it's more similar to jest ) Password hashing argon2 (Never used this either) bcrypt Watching tests (Never attempt

Hello there. Isaac here. So I was trying to set up Thunderbird with external GnuPG on my Arch Linux machine, specifically with a keyring on the disk. The desktop environment is KDE Plasma. The ArchWiki's Thunderbird page wasn't the most detailed on the setup and troubleshooting, though you shouldn't encounter the problems I have if you've properly set up some stuff according to the GnuPG page on the ArchWiki. What I did up until the point of error is following the 4 steps in the wiki along with adding the public key to the OpenPGP Key Manager in Thunderbird ( https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards ). After doing all this I tried to send a signed email but Thunderbird kept returning an error without specifying what the problem is. All it says was that it is unable to sign the message. Using journalctl I was able to find out that the problem was with pinentry. Specifically: "command 'PKSIGN' failed: Inappropriate ioctl for device <Pinen

Hello there. Isaac here. If you don't know what Searchable Encryption (SE) is, do look up what it is first. The previous post is an introduction on SE, though it's just what I understand and might not be accurate. If you want more accurate answers I suggest you read the Wikipedia article on Searchable Symmetric Encryption (SSE). This post will pretty much talk about what I understand from this paper: "Search, Find and Resolve: Towards a Taxonomy for Searchable Encryption Schemes" by Ines Kramer, Silvia Schmidt, Mathias Tausig and Manuel Koschuch. Here is the DOI link to it: https://doi.org/10.5220/0007753804140421 What I love about this paper is how much easier it is to understand for a beginner compared to most papers. It provides a general overview on the categories SE can be divided into, which is really useful for someone trying to understand SE. I highly suggest you read the paper for yourself. Do note that quite a bit of this post is copied from the paper. Any

Hello there. Isaac here. So I'm currently doing research for my Master's program and am thinking of doing something on searchable encryption. Not sure what exactly I'm planning to do yet, but I'm sure it'll come as I read more. Since this is my first post on this topic, let me explain what I understand about searchable encryption. Searchable encryption (SE) is a scheme to solve a certain problem. Say we have sensitive data that we want to keep hidden from unauthorized parties. To do that, we can encrypt the data. The problem is that with the data encrypted, we can't really search through the data. This is where SE comes in. SE let's us search through data that has been encrypted. You might be wondering, if we can use SE to search through the data, doesn't this mean that SE itself isn't encrypted and can leak details on the data? Indeed it can. That is why whatever data that is used to be searched through has to be itself unreadable to unauthorized pa