Comments for Aaron Toponce Linux. GNU. Freedom. Mon, 29 Apr 2019 05:01:59 +0000 hourly 1 Comment on Use A Good Password Generator by E Mon, 29 Apr 2019 05:01:59 +0000 Now that I think about it, KeePass isn't on that list either.

Now, I am aware that they are not technically pure password generators (they are also password managers), but they can still generate random passwords IIRC.

Comment on Use A Good Password Generator by E Mon, 29 Apr 2019 04:55:15 +0000 Where is Bitwarden? It is by far the most recommended FOSS password manager I have seen.

Comment on Your GnuPG Private Key by Alipha Mon, 08 Apr 2019 00:30:25 +0000 The ability to impersonate you and create signed messages under your GPG identity is two-factor in that I need your private key file and your passphrase in order to do so. If I told you the passphrase to my private key file, you would not be able to sign messages as me because you don't have my key file. You need both something I know and something I have.

Comment on Playing Card Ciphers by Spy Cards Shop Fri, 05 Apr 2019 06:45:11 +0000 You can buy the best quality Marked Playing Card Devices from Action India Home Products. We are the leading dealer, manufactures, importer, exporter, retailer, vendor or seller of the Marked Playing Card Devices.

Comment on The Ouroboros Card Shuffle by Ali Zamani Mon, 01 Apr 2019 20:16:15 +0000 Perfect Post About The Ouroboros Card Shuffle/

Comment on Digest Algorithms in Google Spreadsheets by Gerrit Houtman Sat, 09 Mar 2019 16:53:43 +0000 Thanks. I use it to turn student numbers (with salt) into anonymous keys that may be published under the General Data Protection Regulation (GDPR).

Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by yvain Fri, 08 Mar 2019 12:16:08 +0000 Wery well

Comment on Automating Debian/Ubuntu Installs With Preseed by LandMark Hospital Fri, 01 Mar 2019 06:10:40 +0000 thank you for installation guide.

Comment on Automating Debian/Ubuntu Installs With Preseed by chandu vepambattu Wed, 27 Feb 2019 06:20:49 +0000 I am Here to Get Learn Good Stuff About DevOps, Thanks For Sharing

Comment on Automating Debian/Ubuntu Installs With Preseed by Kalyan Sat, 23 Feb 2019 08:51:59 +0000 Nice! Visit here for learn Linux basic tutorials:

Comment on The Ouroboros Card Shuffle by orkideh Fri, 22 Feb 2019 22:18:48 +0000 I like this post.

Comment on The Ouroboros Card Shuffle by salonorkideh Fri, 22 Feb 2019 22:16:57 +0000 WOW. Perfect. This post gave man many information. specially in end of post.

Comment on The Physics of Brute Force by Honato Mon, 18 Feb 2019 07:35:14 +0000 Very cool article. You rock :):

Comment on Use A Good Password Generator by Bitreece Sat, 09 Feb 2019 07:15:06 +0000 In today's digital world where cyber crime is increasing day by day & hackers are looking for any possibility to hack your accounts asap. Then you need to be more & secure, using same passwords for all accounts or using passwords that are related to your personal life that can be hacked more easily. As said by the author use that password which take years to hack, so its good to use password generators which generates mix up of characters, upper & lower case letters, and numbers those are random passwords. And off course these are very difficult to remember at least i have tried once but its simply difficult so use some trust worthy Password Managers.

Comment on Breaking HMAC by Thomas Pornin Tue, 05 Feb 2019 14:51:14 +0000 Notwithstanding the point about collisions in the HMAC key space, the practice of applying HMAC on the ciphertext only has an inherent weakness: an active attacker can change the AES/CTR nonce without changing the ciphertext; this will modify the resulting plaintext, and the HMAC won't detect that. If you want to apply the HMAC in a robust way, you must do it over all the elements that ultimately impact the plaintext: the ciphertext, the encryption nonce, and also the symbolic identifier for the encryption system, in case you have some "algorithm agility" in your protocol.

Alternatively, derive the encryption key _and_ the MAC key from the "master key", using the per-message nonce. This would mean, for instance, using HKDF (the key derivation function based on HMAC): use HKDF-Extract with a per-message random "salt" value (transmitted along the encrypted message), then HKDF-Expand to obtain three elements: the key for encryption ("key1"), the IV for encryption, and the key for HMAC (key2). In that kind of setup, applying HMAC on the ciphertext only is secure; however, it also means that you'll have to use a new encryption key for every message, i.e. run the AES key schedule every time, which may be an issue for resource-constrained systems.

Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by Christopher K. Wed, 30 Jan 2019 21:27:43 +0000 Interesting article. Obviously, your recommendations are right. But still, your heading is largely misleading and - in my opinion- mostly click-bating. Where in your article do you explain why sha256crypt / sha512crypt are "dangerous"?

Your first argument is that you could DOS an authentication server with huge passwords. Have you ever heard of that? I believe most servers have other software that you can DOS a lot more easily, but let's consider that and compare to the alternatives. Assume I was an attacker trying to DOS your authentication server. What I could do, depending on your hashing algorithm (numbers taken/calculated from your plots, assuming they are comparable):

sha512crypt: send a 4kb password that causes 0.3s execution time and 1 "process" on the server and costs me 4kb of traffic to transfer the password

PBKDF2-HMAC-SHA512: send 167 passwords with one byte each that causes 0.3s execution time on the server (167 * 0.0018s), needs 167 "processes" on the server (threads, tcp connections, database connections, whatever that server does while checking authentication), and costs me 167 bytes of traffic to transfer passwords

bcrypt: send 137 passwords with one byte each that causes 0.3s execution time and 137 processes on the server and costs me 137 bytes of traffic to transfer passwords

scrypt: send 7 passwords with one byte each, 0.3s execution time, 7 processes used and 7 bytes of traffic

argon2: send 8 passwords with one byte each, 0.3s execution time, 8 processes used and 8 bytes of traffic

Sure, modern algorithms are better and more secure. But they need more execution time for small passwords and thus, make it easier to brute force, not more difficult. The attacker could more easily send 7 one byte passwords to scrypt than one 4kb to sha512crypt. Usually the uplink of the attacker is a bottleneck, so sending 4kb passwords seems to be a bad idea. Plus, which real-world authentication system supports 4kb passwords?

"moderately large passwords from staff, where such limits may not be imposed, could create a CPU denial of service on busy authentication servers."
Staff would most likely first use VPN/SSH with ("large") key files to get into the internal network and then passwords of normal length.

This is only "dangerous" in theory. And even in theory, other hashing functions seem to be more attractive in terms of DOSing them.

The second argument you mention are timing attacks. I would give this the bigger concern, because it really affects security. But as you mention yourself, it does not make much difference as most real-world passwords fall into the same category. Furthermore, it is difficult to do these kind of timing attacks on a server without getting blocked due to brute-forcing.

So in summary: Yes, modern algorithms are better, but what you write does not explain why sha256crypt/sha512crypt are *dangerous*.

Comment on Automating Debian/Ubuntu Installs With Preseed by Kelly Technologies Mon, 21 Jan 2019 11:12:29 +0000 Thanks a lot for a great blog your article is so expansive nice information on Automations. thanks again for wonderful knowledge with great organized. Take time to visit site at

Comment on ZFS Administration, Part IV- The Adjustable Replacement Cache by Peter Swiatkiewicz Thu, 10 Jan 2019 19:57:28 +0000 Is this OK in your article:

# zpool add tank cache \
/dev/disk/by-id/ata-OCZ-REVODRIVE_OCZ-33W9WE11E9X73Y41-part2 \
/dev/disk/by-id/ata-OCZ-REVODRIVE_OCZ-X5RG0EIY7MN7676K-part2 \
log mirror \
/dev/disk/by-id/ata-OCZ-REVODRIVE_OCZ-69ZO5475MT43KNTU-part1 \

And later on:

# zpool status tank


mirror-1 ONLINE 0 0 0
ata-OCZ-REVODRIVE_OCZ-9724MG8BII8G3255-part1 ONLINE 0 0 0
ata-OCZ-REVODRIVE_OCZ-9724MG8BII8G3255-part2 ONLINE 0 0 0

Looks like /dev/disk/by-id/* do NOT match... or... I am missing something?

Comment on Time Based One Time Passwords - How It Works by Vito Tue, 25 Dec 2018 22:26:29 +0000 Hi, Thanks for great explanation.
You should add that in TOTP has essential requirement: server and client app should be time synchronized. I suppose that for 2FA is good to show time on server to verify or configure(calibrate) TOTP application.

Comment on ZFS Administration, Part III- The ZFS Intent Log by Brandon Doyle Mon, 17 Dec 2018 02:18:19 +0000 Just a quick question - regarding your estimations of life-expectancy of the SSD, that's only for the ~several GB partition you're using, correct? So one 60 GB SSD with a 5 GB partition could last ~12 times that estimation for just a 5 GB partition. So every few years, create a new partition, remove that which is currently added to the pool, and add the new to start writing to a new portion of the space?

Or do the algorithms/code not work this way?

Comment on Playing Card Ciphers by Cosmin Fri, 07 Dec 2018 11:52:30 +0000 /6♥7♠8♣2♠6♣A♣2♣Q♠7♠5♣ 6♠3♠A♣A♠9♣6♠8♣5♠2♠6♠5♣2♣5♠5♣5♣4♣5♣5♠3♠5♣4♣5♠2♠ __ 5♠5♣K♣9♣6♣A♣6♠2♠Q♣Q♣A♣7♠9♣ __ 6♠A♣8♠Q♣8♣8♠4♣6♠2♠A♠ T♥T♥A♠9♣3♣J♣3♣A♣7♣5♣A♦ Do you have a clue about the coding message? should be a name]]> K♥/6♥7♠8♣2♠6♣A♣2♣Q♠7♠5♣
__ 5♠5♣K♣9♣6♣A♣6♠2♠Q♣Q♣A♣7♠9♣ __

Do you have a clue about the coding message? should be a name

Comment on ZFS Administration, Part XIV- ZVOLS by Aurélien DESBRIÈRES Thu, 06 Dec 2018 09:38:28 +0000 Impressive works!

Comment on ZFS Administration, Part XVII- Best Practices and Caveats by Stanley Wed, 28 Nov 2018 03:30:40 +0000 Thanks so much for such informative guide. I just set up my ZFS on Ubuntu with its help!

I have a question now though: there is a dataset that I want to split into 2. The split is just one of the directories. Is there a best practice on how to do it inside ZFS? I am hoping not to have to manually create a new dataset and do the move which will add unnecessary fragmentation on the underlying disks...

Thanks again!

Comment on Automating Debian/Ubuntu Installs With Preseed by akshay Tue, 20 Nov 2018 09:47:27 +0000 Great post.Thanks for sharing. keep going

Comment on Firewire Networking In Linux by Götz Sun, 18 Nov 2018 14:42:22 +0000 What does iperf say?

Comment on Let's Talk Password Hashing by Hans Sat, 10 Nov 2018 10:38:34 +0000 "Never roll your own" - see anything wrong with this?
1: sha2-384 hash the password
2: base64-encode the hash
3: bcrypt the 64-byte base64-encoded sha2-384 hash

why? primarily, it bypasses 2 issues, 1: bcrypt only support passwords up to 72 bytes, this scheme supports any length. 2: many popular bcrypt implementations stop at the first null-byte, which means binary passwords (which may be used by robots/scripts) may inadvertently become very weak, eg if the password is "x33\x00", on most bcrypt implementations, the password simply becomes `3` because hex 33 is ascii 3, and the 00 is treated as end of string.. base64 never emits null bytes, which means your robots/scripts which create their passwords based on /dev/urandom will be safe.

Comment on Automating Debian/Ubuntu Installs With Preseed by sadha onnisa Fri, 09 Nov 2018 12:18:43 +0000 I really appreciate information shared above. It’s of great help. If someone want to learn Online training, kindly contact us

Comment on Automating Debian/Ubuntu Installs With Preseed by michael techenoid Fri, 09 Nov 2018 08:36:05 +0000 really this post values for us

Comment on Real Life NTP by Matt Wed, 17 Oct 2018 06:05:10 +0000 Thanks Aaron, great article.

Comment on The Lagged Fibonacci Generator by Girkov Arpa Sun, 14 Oct 2018 17:10:00 +0000 Very interesting article!

Comment on The One-Time Pad Hard Drive by Hard Disk Price Wed, 10 Oct 2018 10:39:34 +0000 One time apd hard drive. Frankly speaking I was not understand when I start reading your article but once I tried to understand then I got exact information about what I want.

Comment on Latin Squares, Mathematics, and Cryptography by Girkov Arpa Mon, 24 Sep 2018 01:16:07 +0000 "First, suppose I give you a partially filled Latin square as a "public key", with instructions on how to encrypt with it. I could then use my fully filled Latin square "private key", of which the public is a subset of. Using this private key, with some other algorithm, I could then decrypt your message."

What 'instructions' and 'algorithm' could one use to get this cryptosystem to work?

Comment on Latin Squares, Mathematics, and Cryptography by Girkov Arpa Sun, 23 Sep 2018 20:38:40 +0000 "As such, this builds a good foundation for public key cryptography, as briefly outlined here."

I click on the link but it talks only about secret-sharing, not public key cryptography. Is secret-sharing somehow a type of public key cryptography?

Comment on Automating Debian/Ubuntu Installs With Preseed by Nancy nanck Mon, 10 Sep 2018 17:33:59 +0000 RPA training in Hyderabad. We are providing rpa training with real time industry expert,we also providing 100% job assistance.

Comment on ZFS Administration, Part VIII- Zpool Best Practices and Caveats by sherpa Tue, 04 Sep 2018 10:08:18 +0000 what is recommended way of creating data pool if i have 13 x 5TB disks ? i could see in zol blogs that large disks should not be used with raidz but its not clear enough

Comment on Getting Up To 8 Possibilities From A Single Coin Toss by Anonymous Sat, 11 Aug 2018 19:47:34 +0000 You should that (in an appropriate mathematical sense) most of probability theory can be constructed using sequences of coin tosses. More precisely, the most commonly used stochastic processes can be defined on a probability space that is "isomorphic" to the space of countably many coin tosses. In some sense, coin tosses aren't limiting at all!

Comment on Automating Debian/Ubuntu Installs With Preseed by Linux training Thu, 09 Aug 2018 09:00:21 +0000 Thanks for the awesome tutorial.

Comment on Use A Good Password Generator by Joshua Mertens Tue, 07 Aug 2018 07:07:35 +0000 Password should be not simple, because it's very simple anybody can crack it. There has to be a complex combination of numbers, characters and special characters. There are lot of online password generator tools available like which can be used to generate really strong passwords.

Comment on Use A Good Password Generator by Antony Kidless Thu, 02 Aug 2018 17:03:18 +0000 Recently I made a progressive web application that generates strong and random passwords in a click

Comment on CPU Jitter Entropy for the Linux Kernel by Alexander Tue, 17 Jul 2018 15:53:18 +0000 Although the code is in the kernel looks like jitterentropy does *not* feed into /dev/hwrng. Or am I missing something? But still jitterentropy-rngd [1] is useful as a pure user-space daemon.


Comment on Use A Good Password Generator by Peter Sun, 15 Jul 2018 15:00:40 +0000 Thanks for the very interesting page about password generation!

I'm chasing online for a pw generator to put in the hands of our users, but all I found so far is missing something. Gets the feeling that you would be the man to create the dream generator based on Stanford password policy and Diceware wordlists, generating four passwords to choose from:

9-11 characters containing mixed case letters, numbers and symbols.
12-15 characters (3 words) with mixed case letters and numbers.
16-19 characters (words) with mixed case letters.
20+ characters with just lowercase words.

Think many happily would pay to get it on their intranet. Right?

Comment on Use A Good Password Generator by Bo Kersey Wed, 13 Jun 2018 20:15:45 +0000 Aaron, as always your articles are informative, fairly concise and you do a great job of making the complex easier to understand.

one typo that I found..... s/eded/ed/ over the page and you'll fix it 🙂


Comment on Newsbeuter, Mutt and Google by sherrily6 Lane Wed, 13 Jun 2018 06:18:41 +0000 Formatting a hard drive allows you to use it on your computer to store files and install programs on. The format you choose for the drive determines the drive's compatibility. Formatting a drive will erase all of the data currently on the drive, so ensure you have everything you need backed up.

Comment on Use A Good Password Generator by Alexander Boese Wed, 13 Jun 2018 03:09:12 +0000 I created a password generator tool that uses cryptographically secure hashes for generation. Would you mind looking at it, and giving me feedback. If you think it's any good, I can share the generation code, though I'm trying to get more reviews prior to releasing as open source.

DyfynderX on iOS

Thank you.

-Alex Boese

Comment on ZFS Administration, Part III- The ZFS Intent Log by Michel Erb Wed, 30 May 2018 17:08:57 +0000 To confirm an assumption, if this statement is true "ZFS will wear the SSD correctly. The partition will move across the chips evenly, and every chip will get the same amount of wear as the rest.", that means a larger disk, with more chips, takes more time to wear out or the smallest disk, is not always the best option considering longevity.

Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by Poul-Henning Kamp Mon, 28 May 2018 07:16:20 +0000 A few factual corrections and deeper background:

MD5crypt() did not replace the traditional DES-derived UNIX crypt(), but rather an even worse stand-in which only existed because DES was under export-control from the USA at the time. We had the DEScrypt() source, we just could not distribute it without a DoD license.

I knew at the time that hardware implementations of DES were available, and from personal experience that you didn't really need them if you took the time to hand-tweak your assembly code, so DEScrypt was not particular desirable, even if we obtained an export-license.

The choice of MD5 was driven entirely by the source-distribution issue, MD5 was published in an RFC and licensed for any use (whereas the slower, and therefore more desirable MD2 was only licensed for email.) and there were no export-control on one-way algorithms.

The things I focused most on with MD5crypt increasing the runtime in a way which could not be trivially pipelined (ie: data dependence) and on improving the environment for crypt() implementations (ie: longer salt, longer passwords, longer stored results.)

The fact that the runtime depended on the length of the password was considered and ignored: I would be more than happy with the increased security if I could get people to use 8 or 10 char passwords, never mind 17 and up, instead of just eight.

The most important thing I did was the $1$ prefix, which allowed multiple password algorithms to coexist. I pointed out at the time, that allowed you to change the algorithm at any time, as long as you also supported the old algorithms until old passwords were changed (Best practice at the time was 3-6 month between forced password changes).

...and then people did the exact opposite, they all copied & pasted MD5crypt all through the dot-com madness until a researcher told me that he estimated most passwords in eCommerce and half of all passwords in the world were protected by MD5crypt.

As for the OpenBSD people trash-talking MD5crypt:

I never aspired to be or claimed to be a cryptographer, and the **only** reason I have ended up writing some rather consequential cryptographic source code, is that the real card-carrying cryptographers seldom do so and never in a timely fashion.

Bcrypt, scrypt and Aragon2 are without dispute superior to MD5crypt() on all metrics except the most important one: MD5crypt() were there in 1994, as open source and a readily usable software component, they were not.

So yes, I felt the OpenBSD people were a little bit too snotty when they came walzing in five years later, and pissing down on me from my own shoulders felt particular unfair: I paved the road they drove on.

Otherwise: A nice writeup, and sound advice for this day and time.

PS: Here is my own write-up of md5crypts history:

Comment on Use A Good Password Generator by guest Sun, 27 May 2018 17:52:36 +0000 I'd definitely suggest looking at 's idea of Readable Passphrases, which generates a syntactially valid (nonsense) sentence. It's my personal favorite that I've seen -- I find them EXTREMELY memorable, and I'd like to see more people use that.

Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by Aaron Toponce Fri, 25 May 2018 22:29:05 +0000 Polynomial functions are defined as a function that is quadratic, cubic, quartic, quintic, etc. that involve non-negative factors of x. In other words:

f(x) = anxn + an-1xn-1 + ... + a2x2 + a1x + a0

The sha256crypt and sha512crypt functions are polynomial, because it is quadratic function.

Exponential functions are defined as a function whose variable x appears as an exponent. In other words:

g(x) = bx
Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by Raphael M Fri, 25 May 2018 20:13:30 +0000 Great post but i have a question. Big-O's sha512 is polynomial, why is polynomial?

Comment on Do Not Use sha256crypt / sha512crypt - They're Dangerous by Aaron Toponce Fri, 25 May 2018 03:28:18 +0000 PBKDF2 is not exactly "10k iterations of SHA-256". First, PBKDF2 is an arbitrary length output function. A user may request any arbitrary amount of data. The typical usecase is to request key material, so 16 bytes, 32 bytes, and 64 bytes are most common. However, you could request 50 bytes of data, or 33 bytes, or 400 kilobytes if you wanted. SHA-256 is a fixed length digest function, that always outputs 256-bits or 32-bytes of data.

Second, PBKDF2 has a pluggable architecture. Any cryptographic hashing primitive may be used. Common functions are MD5, SHA-1, SHA-256, and SHA-512. PBKDF2 is typically used with HMAC, although if the cryptographic hashing function supports keying, like BLAKE2, then HMAC is unnecessary. SHA-256 is a static function, without any ability to plug something else into it. It's a foundational cryptographic primitive. Bruce Schneier called hashing functions the work horse of cryptography.

Thirdly, PBKDF2 requires salts to prevent rainbow table attacks on the generated output. SHA-256 does not. This doesn't prevent you from prepending or appending salts to your input, but this is something that you have to manually add as part of your application, as SHA-256 doesn't support it natively.

Finally, PBKDF2 is a complex "belt-and-suspenders" construction. The "H" in that diagram is your plugged-in hashing function (could be SHA-256, could be BLAKE2). However, SHA-256 uses the Merkle-Damgaard construction, which is a very different construction from PBKDF2.

And Chris C was correct- PBKDF2 is a sound cryptographic primitive. A homebrew design, such as "10k iterations of salted SHA-256", is not a sound cryptographic design.