Multi Factor Encryption?

Question

I got an alert last night to the keywords above and was curious, so took a look at the tor site flagged which is the following one:
http://nsrz5iogimqwgeax3clpp6hvfy6viom2woy7dghgxes4sqk63r7svoqd.onion. Obviously you need TOR to access it or a service like Tor2Web though reachability is spotty.

I'm asking SE because these guys are claiming to offer a cipher strength I've never heard of. I'd like to ask if you think it's even possible.

This question is about the encryption scheme "Blobby" presented on their site and the security claims surrounding it.

The first notation they use is $10^{yM}$ which I didn't get, but just below is an example $10^{41485806}$, which seems obscene with the unit to of the previous number being "operations", which can be inferred from them stating a relative strength of $10^{38}$ for AES-128 which is roughly $2^{128}$.

Now that I've have longer to look at it, it feels less impossible (though still a stretch), I think the key size and password length are important, but I suspect they're using a third mutagen.

The key claim of novelty for this encryption scheme is that both a nearly-arbitrary sized password (20-$2^{12}$ chars) and an arbitrary sized key ($2^{16}$-$\infty$ bit) are necessary for symmetric operation yielding "multi-factor security" with their custom encryption scheme. The precise quote is

Blobby is fundamentally different, the password is used in conjunction with the key, meaning that each is useless without the other, and attacking the key's password won't get you any closer to the message password.

If their claim is solid, would this be quantum resistant?

I have now downloaded the 3 sample files and looked at them, they are clearly encrypted. I've been trying the first sample for over 24hours now with not a whisper of joy.

Answer 1

Oh boy. Snakeoil at its finest.

This question is about the encryption scheme "Blobby" presented on their site and the security claims surrounding it.

Inventing and selling completely new symmetric encryption? One of the best indicators for snakeoil.

The first notation they use is $10^{yM}$ which I didn't get, but just below is an example $10^{41485806}$, which seems obscene with the unit to of the previous number being "operations", which can be inferred from them stating a relative strength of $10^{38}$ for AES-128 which is roughly $2^{128}$.

It seems they use big numbers for the sake of using big numbers and impressing people. For all practical purposes nothing beyond 256-bit security matters unless you want to invest the entire energy of the sun for most of its lifespan into breaking it. Double that number if you want to go "sure" against quantum computers thanks to Grovers provenly optimal search algorithm.

If their claim is solid, would this be quantum resistant?

It could be that their scheme is quantum-resistant. Symmetric crypto is rather easy to get quantum-resistant. But we don't know until they actually publish a description and even then we might not know because people won't care enough to analyze this scheme.

I'd like to ask if you think it's even possible.

Yes, you can build multi-factor encryption and you can build it nicely out of standard cryptographic primitives.

Now for the actual question you are probably having: "Ok, this is all snakeoil they're trying to sell me and you're saying that we don't need this, so how would you do it in practice?"

Well turns out people already did look at this problem, i.e. how to combine something that you know (like a password) with something that you have (i.e. a pre-generated key, a key-file or a security token).

My favourite three examples for this are the softwares VeraCrypt, BestCrypt and KeePass, which all handle this in a different way.

• VeraCrypt will essentially mix your keyfile(s) with your password using their funky custom hash function and then run this through standard password-based key derivation. A random salt from the ciphertext will still be used.
• BestCrypt will hash each of your keyfiles individually and then sort the hashes and prepend the hashes to the salt before key derivation.
• KeePass will hash your keyfile and concatenate it with your password before feeding that into the password-based key derivation. A random salt from the ciphertext will still be used.

Obviously you need both inputs in all three cases to mount a brute-force / dictionary attack. Also note that any attack that would allow you to recover the password-based key derivation input without actually doing the forward iteration would be considered a major publication-worthy break. And yes there are publications that show that for standard password-based encryptions the optimal strategy is to search the password space or guess a secret symmetric key, the best one of which is probably by Bellare, Ristenpart and Tessaro (Theorem 3.4).

Answer 2

This is a based on the page Blobby the multi-factor encryption engine as retrieved 2020-06-30T14:24Z from the Tor URL in the question.

The claimed novelty for this encryption scheme (per that page and the question) is the combination of a nearly-arbitrary sized password and an arbitrary sized key. But there is no novelty there. A password-based key derivation function that hashes its inputs, followed by a standard cipher does that.

As rightly pointed in the question, the claims around $10^{41485806}$ makes it impossible that it is keys (see 3 below). That must be possible keystreams, and then that number is unsurprising.

On that page:

1. Standard ciphers are introduced, with unfortunate technical¹ and terminology² errors along the way.

2. It is argued AES-256 has insufficient keyspace, with math that turns against that claim if we care to actually perform the computations³.

3. Blobby boasts having 10^41,485,806 unstated things compared to possible keys in other ciphers. That's incompatible with the size stated for the corresponding key material: <50 kiB total, which can encode at most 256^50×1024 keys, less than 10^123,302. Which is still more than enough.
   

the attached files are encrypted with 10^41,485,806 and this demo is by no means blobby's higher end.

4. Still we get that Blobby is a symmetric cipher with a huge keyspace, and a key so large that it must be stored as a file (like GPG/OpenPGP asymmetric keys).

5. Most standard ciphers and many encryption tools have a key or a password. Blobby has both, which justifies «Multi Factor». That puts Blobby in the same category as encryption programs like TrueCrypt/VeraCrypt, BestCrypt, KeePass, and GPG/openPGP when asymmetric keys are password-protected.

6. Many standard ciphers and most encryption tools (with the exception of full disk encryption tools like TrueCrypt/VeraCrypt) do not attempt to hide the plaintext length, Blobby does, and seems to hide if there's activity in real time. The argumentation about that part is fine.

7. There is no description of the algorithms used, and that's claimed normal⁴. But that goes against the best established principle in >130 years of cryptographic academia: Kerckhoffs's (second) principle. And there is not a word about the critical stretching of the password.

8. An example of ciphertext is used as security argument, which is grossly inadequate for a falsifiable claim of security. That goes with the use of non-standard cryptographic terminology like «mutagen»⁵.

9. It's for sale on Tor:
   

If you wish to make an offer…

Conclusion: The principles in 5 and 6 have technical merit. The rest is characteristic of snake oil cryptography in the password-based category.

---

¹ Technical error:

Block (cipher): The clear text is broken into fixed size 'blocks' according to the chosen ciphers' spec, and each block is encrypted with the full strength of the key. Data leftover from the final operation is padded to ensure it meets the block size and then encrypted.

Yes.

Each cipher has it's own methods of mutating the key, to avoid any repeating patterns.

No. That's not how block ciphers are operated, and has not changed since 1975. It is used the same key for all blocks in a message, and often for multiple messages, per a block cipher mode (e.g. CTR). Under the assumption the the block cipher is secure, this demonstrably gives security under chosen plaintext attack.

---

² Terminology error:

One Touch Pad (OTP):

The acronym really stands for One Time Pad. The discussion made of it is fine.

---

³ Attempt to discredit AES-256 for insufficient key space:

The gentle art of breaking cryptographic keys, cracking step 3:…
So start at zero and increment by one, testing each number against the cipher before moving on. There are of course, a lot of numbers that would never be used in production. They can be excluded, but as AES256 rounds out at ~1.15*10⁷⁷ it'll still take a while.

This «a while» is the mother of all euphemisms!

newer ARM servers can run 748 (threads…) each one able to make over a million guesses a second.

Make that a billion guesses per second, because that's only a few times more than what's routinely achieved for AES by a single thread.

Consider that the largest BOTNET, discovered to date, had slaved over 1.5 million machines.

I'll make it 10 million machines each with 748 threads running at a billion keys per second for a century, because imagination is cheap (if not electricity). We get 10⁷×748×10⁹×86400×365.25×100 keys enumerated. That is n = 2.4×10²⁸. Probability to have hit the right key, if it was chosen secretly and at random, is n/2²⁵⁶, that is ≈2×10^-49. Less than throwing a fair coin and getting 161 consecutive heads.

All that and we haven't even mentioned, the now commercially available Quantum computers. Which love parallel processing and make the botnet look like a row boat.

They are not ready for prime time, and so far have not performed anything useful for cryptanalysis. On that standpoint, their are beaten by pencil and back of an envelope. But in the wildest dreams (if not pipes) there's hope QC can replace the 256 by 256/2 = 128. Probability that the key is found becomes, ultra-conservatively, less than throwing a fair coin and getting 33 consecutive heads.

Still feeling safe with AES?

Safe from brute force key search for AES-256, positively. There's safety in the numbers.

Since there is an open crypto community (1975), there has been quite a consensus on the necessary key size for symmetric cryptography (like Blobby is) to resist brute force attack (the only kind considered on the web page). The 56-bit DES key was clearly not enough, that was immediately apparent. It is now declassified it was that low to allow brute force attack. The frontier for minimum reasonable (absent stretching) long was 80-bit, now is 96-bit or 112-bit, with 128-bit the standard for commercial crypto. There's consensus 256-bit is fine including against quantum computers, and 512-bit overkill. Anything more is pointless, can be counterproductive, and is indicative of not understanding where the real difficulties are: cryptanalysis other than brute force, key leak, side channels.

---

⁴ Quoting a Q&A:

Are there other mutagens⁵ in use?   Of course, but it's not likely we'll detail them here, now is it?

---

⁵ Perhaps «mutagen» is standard terminology in the crypto Tor world after all: it's also in the question, posted thru Tor like the article and the two answers by user Blobbly.

Answer 3

We built a multifactor encryption product, so I have some experience with best practices, at least for elliptic curves:

• Use a proven secure ECDKG method to generate a multifactor private key.
  The simplest way can be thought of as: rolling random numbers on each device, publishing commitments to the public parts, publishing the public parts, computing the final key, and publishing the agreement. If a minority DOS attack isn't a concern, best to fail fast and start over if something goes wrong.

• Care must be taken during commitment rounds in order to ensure an attacker on one device cannot control the final key. You should be aware of the known attacks here, and use a standard method.

• Once you have the DKG public key, encryption is just ECIES.

• Decryption can be done on a threshold by computing partial decryptions (think of this as just ECDH with each device) and combining the components (can be linear or polynomial combination, depending on the use case)

• Care must be taken to publish and verify POSK for all public components for which partial decryptions are computed, otherwise an attacker can gain access to private keys.

• Typically it's easiest to use these more complex public/private cryptosystems to encrypt an AES key, and use straight AES on your data.

Answer 4

@Greeny: To answer your questions.

1: Yes the numbers are possible.

Justification:

A BasicHex(0-F) Grid 16x16 gets you 16²⁵⁶ or in decimal 1.797x10³⁰⁸

A BasicHex(0-F) Grid 32x32 gets you 16¹⁰²⁴ or in decimal 8x10¹²³²

The formula we provided on the site, was simple enough, CharTypeCount^{(BlockSize x BlockCount)}.

_{Does anyone disagree with the structure of this math?}

The sample files burned over 100,000 blocks each, and we use more than just basic hex char’s. But in truth the numbers are irrelevant, see answer 2.

2: Yes it should be quantum resistant.

https://en.wikipedia.org/wiki/One-time_pad

How is the One Time Pad (OTP) perfectly secure?

Both of the above links consider the OTP to be ‘Perfectly Secure’ , it was however abandoned in favor of modern ciphers for 2 reasons:

1. Key transportation became impractical as data volumes increased.
2. Truly random keys are incredibly difficult to produce.

We solved the first by improving the efficiency of block generation/usage, and quite by accident appear to have solved the second as well (NO we are not claiming to have created a next gen RNG, this we would have published) .

That said we’ve been testing it for some months now without any persistent patterns being detected. Still, we accept that without a lot more testing, any claim to have completely solved the random challenge would be pointless.

3: No. Joe public has no real need for it, unless they’re involved in the sort of activities where they probably shouldn’t have it. As we state on the site, it’s intended for players with data that NEEDS, to stay secret for a protracted period, be that on storage or in transit.

Lastly we would ask you to remove the second tag from the thread:

Why?

1. Blobby doesn’t claim to be a new cipher, it’s a new engine. One based on OTP instead of the Boolean of modern ciphers.

2. It works! The sample files are provided as proof, it might also be worth noting that a 10KB key (+PW) encrypted 5MB of data using OTP principles, and it did it without repeating.

3. If it’s snake-oil, why make it clear from the beginning that it is not suitable (overkill) for 90% of the market?