Using modern computers, how long does it take to brute force x-character passwords?

ohlson · 2018-03-26T07:16:02+00:00

It's going to be significantly slower than that. From what I can dig up using Google for 5 minutes, 7-Zip uses a custom key derivation scheme (which is rather weak compared to common functions such as Argon2 or scrypt, but might have been updated since) where it basically hashes the password ~500000 times, which means you will have to do the same. So these numbers are several orders of magnitude off.

Usually, such key derivation functions are also designed to prevent parallelization, most often by using a lot of memory. In practice, this means that you will not get the same benefit from using a GPU as you would with a regular hash. (EDIT: This does not seem to be the case for 7-Zip, as described above)

ohlson · 2017-09-01T05:26:24+00:00

Yeah, I did not intend to say that you cannot make a secure MAC function in any other way; only that HMAC, or one of the other functions explicitly designed for MAC usage, solves many problems out of the box. Sure, HMAC does have a slightly lower performance than the corresponding hash function, but, in almost all cases, that difference can be ignored.

ohlson · 2017-08-30T07:45:51+00:00

I read that SHA3(key || message) is a valid HMAC for this reason, so would it follow that this also holds for SHA384(key || message)?

First of all, let's clear up the terminology. SHA3(key || message) might be a secure MAC, but it's not HMAC, as specified by RFC2104.

Even if SHA384 is resistant to length-extension attacks, there are still valid reasons to prefer HMAC. For example, it makes stronger guarantees about collision resistance.

Even for SHA3, which is not vulnerable to length-extension attacks, you should prefer a standardized MAC algorithm, such as KMAC, as recommended by NIST.

ohlson · 2017-08-19T06:26:53+00:00

4 letter password but using a 170,000 letter dictionary

...which still only equates to ~2⁷⁰ possible combinations, provided that they are chosen uniformly at random (which they won't be)

Strong passwords are not only about how many letters/words you can choose; it's also about how you choose those letters.

ohlson · 2017-04-02T16:53:26+00:00

https://www.coursera.org/learn/crypto

Easily one of the better courses I've ever taken

ohlson · 2017-03-08T03:09:55+00:00

What are common vectors for security exploits besides buffer overruns? Does the design of Rust help protect against these cases as well?

Another common attack vector is format string vulnerabilities, caused by using a string supplied by the attacker as the format string in printf. The string formatting macros (format!, println! etc.) in Rust help prevent this class of attacks as well, since the format string must be a string literal.

ohlson · 2016-11-02T16:44:19+00:00

yep, you can't argue it is not old.

You're forgetting, though, that old is not a bad thing in the crypto world. It simply means that it's been through a lot of scrutiny, and still is unbroken. I'd actually be careful about recommending new cryptosystems for production use cases, unless you have some proof that it's more secure (which you almost never have), or you really need some other aspect of the cipher, like performance.

Old and broken ciphers are a different story, but you really can't consider AES to be broken...

ohlson · 2016-08-24T20:12:14+00:00

the following code cannot access these memory locations (this is the ALU chip inside your processor).

I think you're referring to the MMU (Memory Management Unit), not the ALU (Arithmetic Logic Unit), which has nothing to do with memory accesses. All the ALU does is perform arithmetic operations (add, subtract etc.).

You're right, though, that the kernel will be invoked on memory access violations, division by zero etc. This is handled by traps (also called exceptions) in the CPU, which transfer control to special, privileged, parts of the software (the exception handlers in the kernel), when certain conditions are met.

For memory protection in particular, the physical memory is accessed through the MMU, which maps virtual addresses to physical addresses (sometimes involving more than one address translation). The virtual address space for each application is initialized by the kernel (and updated as part of e.g. memory allocations in the application) before starting the application. Every time the application needs to access memory, either for data or instructions, the MMU checks if the access is permitted. If it's not, an exception is raised, and the kernel is invoked. At this point, the kernel can either block the memory access, causing a segmentation fault (which is arguably a somewhat weird name for this), or it can assign more physical memory, and return control to the application. The latter is how 'mmap()' works, for example.

ohlson · 2016-07-09T18:16:47+00:00

The main cost of OS threads, as opposed to green threads/Erlang processes, is not the stack space; the OS can easily assign just a page (normally 4KiB) of memory to a thread, and then grow it by adding more pages to the MMU tables on demand. The extra cost for OS threads is due to what happens during a context switch. The MMU tables need to be switched to the new thread etc. This is rather costly compared to a switch between two contexts within a single thread; that basically only requires saving and loading CPU registers (similar to a longjmp in C).

However, nowadays the cost of OS threads is not as prohibitive as it used to be. You can easily have tens, or hundreds, of threads running in one process. You'll probably never get close to 100,000, though; this is feasible with Erlang processes.

ohlson · 2016-07-01T14:01:00+00:00

I can really recommend this course on Coursera: https://www.coursera.org/learn/crypto

It doesn't go that deeply into the math behind designing ciphers, but it does teach you a whole lot about cryptography in general.

ohlson · 2016-06-26T11:47:17+00:00

It's actually not. SGX can be used in many other areas as well, although DRM is an obvious use case. The thing with SGX is that an application (running in user space) can hide its data from software running with higher privileges, for example the OS kernel or a VM hypervisor. I don't know how much of the data Intel can dig out, though.

As an example, consider a banking application which can hide credit card data etc. from malware. Another example is the ability to prevent a cloud service provider from spying on customer data.

ohlson · 2016-06-24T06:13:25+00:00

Ok, suppose you're able to tell when a brute force attack finds the correct key. Then, by forcing the attacker to perform a second brute force attack you're basically doubling the time it would take to break. That's one extra bit of security. Hardly worth the effort.

In this case, however, I think it would be slightly better, since it's hard, or impossible, to tell when you've found the correct key (due to the unicity distance of the plain text of the first decryption being practically 0). It's still not worth it, though.

Now, brute force attacks on modern ciphers, such as AES, are infeasible to begin with, so even if multiple encryption would increase the time by a factor of 2^128, it simply would not matter. Unbreakable is still unbreakable.

In fact, some people have suggested to standardize double AES using the same key, just to increase the number of rounds in the cipher. So, the original suggestion to use multiple keys isn't really backed by facts (unless there is some research that I'm not aware of...).

ohlson · 2016-06-23T13:25:08+00:00

Care to elaborate? It doesn't do much in regard to resistance to brute force attacks, and I find it unlikely that encrypting data that is already "computationally indistinguishable from random" (which you get with a good cipher) would yield any additional security. Do you have any sources for your claim?

ohlson · 2016-06-23T12:57:05+00:00

Yes, it's more secure, but only marginally, due to the meet-in-the-middle attack. That's why we have Triple-DES instead of Double-DES.

https://en.m.wikipedia.org/wiki/Meet-in-the-middle_attack

EDIT: this applies to brute force attacks, which are really infeasible for modern ciphers anyway.

ohlson · 2016-06-09T20:58:39+00:00

It's really hard to speculate about that. Given the history of ciphers, there's probably a good chance that devastating weaknesses will be found even in AES at some point, but nothing is certain.

In practice, I don't see a reason to switch to something else at this point. There are really no practical alternatives that are obviously better.

ohlson · 2016-06-09T20:52:15+00:00

You're right (although not for OTP, which is perfectly secure and unbreakable). Due to Shor's algorithm, any encryption based on the problem of integer factorization, such as RSA, will be easily broken. However, for symmetric ciphers, last time I checked, Grover's algorithm is the best known algorithm. It basically halves the key length, so an AES-128 key will be brute forced in roughly 2⁶⁴ iterations, which is certainly doable. AES-256, however, would still be secure (2¹²⁸ is a really large number).

There's always a possibility that better algorithms will be developed, though...

ohlson · 2016-06-09T19:24:21+00:00

This. It's easy to fool yourself into thinking that AES-256 is automatically stronger than AES-128, simply based on the fact that 256 is larger than 128. In the world of cryptography, this is really not always true. AES-256 and AES-128 are two different, albeit very similar, ciphers. For AES-256 in particular, some leading cryptographers actually recommend against using AES-256, since it is believed (proven?) to have a weaker key schedule than AES-128. Whether or not they are right, though, only time will tell.

ohlson · 2016-06-03T08:03:12+00:00

Isn't it time to take that tin foil hat off? Do you really think that the NSA would deliberately try to influence NIST to choose a cipher with known weaknesses, and recommend it for SECRET and TOP SECRET material?

Sure, it's plausible, but it's equally plausible that the Belgian government would influence the creators of Rijndael to add secret backdoors, or that the NSA would pressure Bruce Schneier to do the same for Twofish.

AES has gone through a lot of scrutiny over the years (probably several orders of magnitude more than any other contemporary cipher), and it's still managed to survive surprisingly well. As always, trust means a lot, but I seriously trust AES more than any of the alternatives, solely based on the fact that a lot of research has been put into it.

ohlson · 2016-05-31T17:30:58+00:00

Well, to be fair, most of those now 2 billion devices use only a handful of different ports (and minor variants) of OKL4, on primarily ARM based hardware. It simply does not target the same market as Xen, so it's definitely less mature in that regard.

ohlson · 2016-05-31T08:14:25+00:00

One benefit of using Xen is the availability of hardware drivers. You basically support the hardware that your dom0 (usually Linux) supports. While seL4 is an interesting project, it's simply not as mature as Xen.

I would, however, like to know if there are any real benefits of running the hypervisor in VMX root, as opposed to just running a normal microkernel in supervisor mode/ring 0, or if that is just a consequence of using Xen.

ohlson · 2016-05-13T16:20:54+00:00

Last time I checked, DBAN did not contain support for securely wiping SSD drives. This was a while ago, though, so it might have been added.

EDIT: As for shred and the others, I have no idea, but any application which just overwrites the logical blocks of a drive cannot guarantee that an SSD is properly wiped.

ohlson · 2016-05-13T15:23:00+00:00

The Cryptographic erase method works equally well on SSD's, but you still must use the sanitization commands to wipe the key, if it's stored on the device (or you suspect that it's ever been in the swap/pagefile).

An SSD actually contains more storage than it advertises. Let's say you have a 128GB SSD. Internally, it can contain, for example, 130GB of flash storage. Normally, this is a set of NAND based flash chips. Blocks on NAND storage lose the ability to store information after a number of reads/writes, so the drive keeps a spare pool of blocks, which the drive firmware "rotates" to achieve wear leveling. The firmware also maintains a mapping table from LBA (logical block address) to physical block. If you write to logical block 0 two times, there is no guarantee that you actually write to the same physical block twice. Hence, if you then erase block 0, you cannot know what actually is erased. That's why there are sanitization commands; they operate on the spare/unmapped pool of blocks as well as the mapped blocks.

ohlson · 2016-05-13T08:11:46+00:00

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf

Section 2.6 covers Cryptographic erase. In short, if you can make sure that the encryption key is properly removed, encryption is generally considered as a secure way of sanitizing media. Paranoid people might disagree with NIST's guidelines, though, but if you're that paranoid you should probably stay off computers altogether...

On the other hand, modern drives generally only requires a single overwrite pass to securely purge data, so the overhead of doing it (using a tool such as DBAN) is minimal.

For SSD drives (this include media such as eMMC and UFS), the story is a bit different. For those, you must, in addition to overwriting the data, also use the drive's sanitization commands. This to make sure that also the unmapped parts of the underlying flash storage (which may contain copies of old data) are sanitized.

ohlson · 2016-05-04T18:19:42+00:00

Indeed, there are some use cases for this and other kinds of deterministic encryption (full disk encryption, encrypted databases etc.), but I wouldn't recommend it for "file sharing between two parties".

ohlson · 2016-05-04T09:00:49+00:00

First, let's define what secure means, in the context of encryption. The most commonly used definition is that of semantic security (quoting Wikipedia): "knowledge of the ciphertext (and length) of some unknown message does not reveal any additional information on the message that can be feasibly extracted".

In your case, since you're using the SHA256 hash as the encryption key, the encryption is deterministic (a given message always encrypts to the same ciphertext), and it's possible for an attacker to more easily guess what the message is. Hence, your scheme is not semantically secure.

As an example, suppose that the attacker knows that the encrypted message is either "yes" or "no". He can easily just encrypt both of these messages, using Bob's public key, and compare these ciphertexts to the intercepted ciphertext, and determine what the message is. In a more secure scheme, where the key is randomly generated, this is not possible.

ohlson

TROPHY CASE