The Side Channel

12:41 AM

@Gilles I'm sure there's a lot I don't know about RSA. :P

Although it looks like RSA-KEM as I mentioned before doesn't require padding, but it is far more fragile. It makes sense that people would just pad it so it can't go wrong.

@bdegnan It might be. See the first quote in:

7

A: How were the number of rounds for different key sizes of AES selected?

Some quotes from The Design of Rijndael (pdf, see Section 3.5 "The Number of Rounds"): For Rijndael with a block length and key length of 128 bits, no shortcut attacks had been found for reduced versions with more than six rounds. We added four rounds as a security margin. The addition of ...

Maeher

8:57 AM

@Gilles I suppose that is correct. I'm personally happy with the current resolution.

Even though the author apparently still does not understand that AES-GCM is not the same as their construction.

Maeher

9:22 AM

And there they go again. -.-

forest

wat

kelalaka

yes

forest

Why is he asking this?

It just seems unnecessary.

Maeher

11:40 AM

That's 10 minutes of my life I'm never getting back...

forest

hahaha

How much you wanna bet he won't understand the notation and claim his design is still as secure as GCM? Though at least he added more detail in the question...

I really want to edit that answer with \mathbin\| instead of \| to provide better formatting, but there's so many concatenations...

kelalaka

It is easy, copy into a text editor, find and replace?

done

forest

I don't copy from browsers to my text editor for security reasons. And I keep putting off fixing the bugs in my xclip patch to strip out non-printing characters...

kelalaka

What is the risk?

forest

@kelalaka Non-printing characters can be embedded in a webpage that are interpreted when pasted into a terminal. See the popular PoC: thejh.net/misc/website-terminal-copy-paste

It could easily contain :! to execute code directly from vim.

(I mean yeah I use -R but still, don't want to risk it)

kelalaka

11:55 AM

I see. What about just a simple text editors.

forest

Assuming you can exit the text editor from within it, it's still a risk.

Maeher

It highly depends on how the editor actually implements pasting.

kelalaka

There is always that risk, however the examples that you show are using the properties of the applications or terminal

forest

@Maeher All the ones I've used are vulnerable to it.

@kelalaka Sure, and pasting into Geddit or something would likely be fine.

kelalaka

Exactly, however, I remember the camera watching the groove solution on the Godel/Escher/Bach

forest

11:59 AM

wat

kelalaka

reddit.com/r/GEB/comments/3uvz19/contracrostipunctus

I cannot find the full text.

forest

Maybe I'm just too high but my brain is throwing serious parse errors right now.

kelalaka

There were an ultimate record player that plays every record

>You know this from CS, this is different approach

forest

Ok I am seriously confused.

Maeher

@forest You are not alone.

kelalaka

12:03 PM

Haven't you read it? en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach

forest

I mean

I don't get what that has to do with anything.

kelalaka

Even the finest of the editors can somehow be used to exit?

Maeher

Now I just hope that my special friend does not notice that that specific attack no longer works if you use a short nonce plus separate counter as some standards do.

forest

heh

I doubt he will.

@kelalaka Well if it's in a terminal, then most likely, yes.

SEJPM

WTF the Q is 3 hours old and already accumulated 20+ comments

forest

12:14 PM

Well it's mostly him posting 2 or 3 messages for every one I made.

Maeher

It's not looking good for the comment thread under my answer, either. :(

forest

@Maeher I honestly think he has no clue what you are saying.

Maeher

@forest Sadly you are probably right. And even if he concedes that it's boken he will be back tomorrow with a new convoluted "better than GCM" construction.

forest

I mean to be fair, there are more ignorant people here...

Maeher

@SEJPM can you move that comment chain under my answer to chat?

SEJPM

12:22 PM

@Maeher I could, but it wouldn't change much because the user has 1 rep and you need 20 to chat

Maeher

ah...

then that would be unfortunate

Ok... now I have to prepare for teaching some people who are actually trying to learn.

kelalaka

Good to have for you to have such students.

SEJPM

I think I understand this guy now

Because I don't have a good intuitive explanation either why the GHash prevents forgeries

So if they get an answer explaininng what special properties the polynomial multiplication of GHash has that makes this secure they might be satisfied

forest

It's not like this is that hard to understand.

SEJPM

12:39 PM

@forest oh, what happens isn't hard to understand

what makes this user trouble is understanding why replacing the mult operations with a standard hash doesn't work

forest

Ah

SEJPM

and in turn what makes mult so special that it works for GCM

and that's a question I can't answer

forest

Is that what he's trying to do? Replace the multiplications with just a PRF?

SEJPM

@forest yes, replace the chained multiplications with a public hash / RO

kelalaka

iacr.org/archive/eurocrypt2005/34940166/34940166.pdf

@SEJPM This proves the bound ecrypt.eu.org/hash2011/proceedings/hash2011_03.pdf

SEJPM

1:06 PM

ahhh, now I see

X_i = (X_{i-1} + S_i) \cdot H

the last X_i is the tag

and the graphic on wikipedia is highly missleading

because it makes it appear that essentially you compute a public function of public inputs and XOR that with E_K(0)

but instead H is E_K(0)!

Therefore the "update" function of the "hash" is secret-dependent which separates it from a standard public hash

kelalaka

1:27 PM

is this better

SEJPM

@kelalaka technically yes, but it has the drawback of looking more complex than the wikipedia version and being less nicely colored

kelalaka

plus should be x-or, right?

SEJPM

@kelalaka + is XOR if you work with polynomials (over a characteristic 2 field) ;)

kelalaka

of cource

If you have the bandwidth or If you have a limited bandwidth?

SEJPM

@kelalaka I'm not sure what your question is?

kelalaka

1:35 PM

Its ok. forget it

@SEJPM since GASH provide only 2^64 security against forgery in TLS 1.3, and we cannot change, is there any suite that provides information theoretical security against forgery. CCM?

SEJPM

@kelalaka yes, CCM should do the trick

kelalaka

Would you let me add this to the question also?

SEJPM

@kelalaka sure

give me a ping after the update

kelalaka

Sure

@SEJPM added

OMG

0

Q: cipherText = aes-ctr(key, ++iv, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData))); is it secure?

Proposed Cipher suite: cipherText = aes-ctr(key, ++iv, (plainText)); & authTag= aes-ctr(key, iv, aes-ecb(key, sha-1(cipherText+authData))); Security targets achieved: Encryption of the cipherText. Integrity of the cipherText & authData. Authenticity of the cipherText & authData. Used compo...

We are under DOS attack

SEJPM

2:01 PM

@kelalaka added

Future Security

3:35 PM

Nope. Not ready to read Paul's answer to "Cryptography's random number problem?" I really don't want to facepalm so hard that it requires an emergency room visit.

Maeher

4:41 PM

@FutureSecurity It's fine. He correctly points out that the article's premise is bullshit.

Ella Rose

It actually wasn't that bad. But I'm not sure it added anything useful that the other answer didn't state already either.

b degnan

4:54 PM

I don't understand the issues with random number generators. The ones I made were based on the fact that channel noise is provably two-way shot noise, which was totally random. You just make the integrator follow temperature so it takes longer to make a random number when you try to freeze out the ICs. Thermal noise doesn't actually exist in semiconductor channels as it's shot noise, and the military solved this problem in the 80s. It's just so weird from the IC perspective. It's marketing.

Future Security

6:58 PM

@bdegnan Two things. Random number generators having a lot of "moving parts". (Which is bad because it's really hard to convince people to do things the right way or even get them to agree.) And people have a genuine belief in the mystical side of "randomness".

I skimmed the linked article. I think I remember reading something about existing HWRNGs being "bad" because they could break (with age or use). In another part of the same article it says that the experimental quantum thingy breaks frequently. (Face + palm).

b degnan

@FutureSecurity Things are only as complicated as you choose to make them. I feel generally that people just "add junk" to make things complex when they cannot handle the math. I'm not really sure how things break if designed well, but silicon does have a cycle life. I have a nice first-principles random number generator that is temperature robust. I feel that cryptography is more held to lore than physics. We in device physics definitely have less probability to deal with.

@FutureSecurity It's definitely harder to be a cryptographer than a physicist.

Future Security

7:22 PM

I wouldn't trust any circuit I might come up with to not drift or change probability distributions. But then I would just put any raw input through a hash or sponge so it wouldn't matter if that happened. In that sense the problem of random number generation has been solved. All that's left besides latency, bandwidth, and power consumption is entropy estimation.

And self-tests to look for pathological states, short circuits, interference, tampering, etc.

Future Security

7:43 PM

@bdegnan Which type of RNG is that? And do ring oscillators count as temperature robust?

Future Security

8:51 PM

@SEJPM What would happen if the server key in PRF(master_key, user_name) was leaked? That feels like using a site-wide salt instead of a per user salt. (H(user_salt, user_password) vs H(shared_salt, user_name, user_password)

b degnan

@FutureSecurity The channel of a semiconductor can have provable randomness in subthreshold. You can make two ring oscillators that are capacitively linked that will guarantee random behavior when latched by a clock. My Ph.D. was over temperature robust circuits, so if you chose to make things temperature robust, they can be. Alternatively, Chua's circuit is also provably chaotic, which is another good choice. Basically, 0th-order, symmetry makes circuits temperature robust.

SEJPM

@FutureSecurity you would be back to the security guarantees of standard PAKEs that leak the salt

(ie an attacker can pre-compute for each user the salt and for that salt a dictionary of likely passwords and perform a log_2(dictionary size) attack once the hashes leak)

Future Security

Would changing the per-user server key be like changing a per-user salt? (Assuming the user changes their password as well as the salt, whether the salt is known to the server or not.)

I have a scenario in my head where you want to defend against people probing the server waiting for a sign that the server side key has changed and using that to signal when a new user with a specific email address or username.

Say some politician uses one email address known to the public to register. Suppose it would be a scandal if the public found out a politician uses a website. By probing a specific email, looking for signs of the server-side key changing, which would tell them that a specific politician uses the website. (Because either they're a new user or they change their password.)

If you're using DH-OPRF you can tell if the server's key has changed (I think) because the server's response is deterministic.

I'm hoping there is an even more magical OPRF algorithm that wouldn't have that property. But that could be expecting too much. Don't know if it's possible.

SEJPM

9:12 PM

@FutureSecurity yes, if you rotate the server-wide-salt-master-key you need user interaction or the password

Future Security

Right. So just like rotating a site-wide salt in traditional password login systems?

SEJPM

@FutureSecurity the server's response has to be deterministic for OPAQUE / OPRF-based auth to work as the ciphertext to be decrypted is static

@FutureSecurity yes

hmm

maybe the CFRG draft mitigation for the anti-user enumeration via the ciphertext could be adapted

to also work for the OPRF-based auth

hmm, I don't think this works

because you still need to derive the symmetric key

and I think this inherently requires deterministic server-side interaction

Future Security

That's the train of thought I had. But I think I need to wait until I can think more clearly to prove it or satisfy my curiosity

I thought about using Socialist Millionaire Protocol, and only use the real key if the unsalted password is correct, but that defeats the purpose of password stretching later.

SEJPM

@FutureSecurity well, you can always try and ask on the main site so it doesn't get lost in the ongoing transcript ;)

@FutureSecurity the beauty of OPRF is that the server doesn't know whether the correct password was used when it applies the server-side key

(because the value was blinded)

Future Security

I'll have to put something on the web after I research and think and question this topic more. Not sure if SE is a good place to post because I don't have a concrete question yet.

SMP wouldn't work without user interaction I figured.

Can the OPRF output instead be used by the client to decrypt a salt encrypted by the server? Decryption would be deterministic, but the server would use a random key or split the message up in such a way that it's only recoverable with the OPRF output and the password.

SEJPM

9:36 PM

@FutureSecurity sure but you would still be able to tell from the server's response to OPRF requests whether the user exists as per the above attack

(?)

Future Security

What if you use the PRF(master_key, user_name) for OPRF but have a secondary per-user salt stored plaintext by the server?

Server picks random c, encrypt salt with c, send the client ciphertext of the salt, send c encrypted using public key encryption. Use OPRF output to encrypt another user-specific key pair. Client decrypts their private key. Decrypts c. Then decrypted the secondary salt. (Just thinking aloud. I may have made mistakes.)

Future Security

9:52 PM

Still thinking aloud... KEM(salt, random nonce) using stored user-specific public key. store user-specific private key with symmetric encryption using Rwd as key

Oh... That might not be much different than full OPAQUE (OPRF + KE)

Future Security

10:10 PM

Doing novice crypto while sleepy no doubt leads to chicken-or-egg logic. In this version the OPRF still either uses a static key or leaks when it changes. But now the user can change their salt. Instead of stretch(pwd, H(x, v, H'(x)^k)) do stetch(pwd, H(x, v, H'(x), plain modifiable salt)). But then is a user private key in danger if the server master key leaks...

Future Security

10:23 PM

The new private key is only as secure as the password is with public-knowledge salt. Private key can be changed only with user interaction. Whether the private key is changed or unchanged is leaked to people without database read access... when? ... That's a loop I think because there is no way for the server to re-encrypt the user's private key without OPRF password knowledge.

Then there is also no point of switching symmetric encryption because then we just add an extra layer without gaining something...

Sorry guys. Is this appropriate use of chat?

Future Security

11:25 PM

Huh. So if you leak the master key in user-enumeration-mitigated OPAQUE you leak the equivalent of every user's salt. You can rotate master keys periodically, but then you leak the last time a user logged in because you need user interaction to update. (With precision of whatever the time between master key updates is.)

Transcript for