The Side Channel - 2019-08-07

« first day (2947 days earlier) ← previous day next day → last day (1729 days later) »

5:46 AM

@Maeher You are quite right. But the strangeness was interesting; for example, consider the obviously correct statement "two identical messages will always result in an identical hash" ... yes... clearly... it's a fact... until you find an identical pair that doesn't in some strange scenario! — Patriot 19 mins ago

@Patriot ???

I can't tell if you're joking or not. Why would a hash ever do that?

Also unrelated, but @Patriot I know you don't like SHA-1. Have you looked into RIPEMD-160? Although I'd definitely recommend moving entirely to SHA-2/SHA-3 even if only for the larger output size (80-bit collision resistance is worrying), RIPEMD-160 is a viable drop-in replacement.

6:23 AM

@forest Thanks!

I know it is impossible.

Re. quantum mechanics from that comment, all that does is affect physics, not math. A hash is an abstract mathematical concept, like "2 + 2". Quantum mechanics can't change that.

It can, however, cause a glitch in the CPU processing a hash implementation.

But my point was this: the impossible is impossible, until it isn't.

In this case, it is always impossible and never will be possible. It's not like a fast preimage against SHA-512 which is very, very, very, very, very unlikely, but not necessarily impossible.

@forest Back to work. :)

It's exactly as possible as violating the confidentiality of a perfect OTP implementation.

aight, cya

6:25 AM

I got it.

6:54 AM

@NicHartley The discussion was about the hash algorithm itself.

Steven Hatzakis

7:10 AM

I just saw the EFF's wordlist, didn't even realize they had one https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt But I like the BIP39 wordlist better as there are no two words that start with the same first four characters, so it is sufficient to only retain the first four characters (even though the list is smaller). For example, in the EFF list the following words are too similar: 11551 ample
11552 amplifier
11553 amplify
11554 amply

But a shorter wordlist would require you remember more words.

Steven Hatzakis

@forest Indeed, 2048 words is only 2^11, for every doubling you need one less word, so 4096 words would be a savings of one word (if the underlying bits were 132) I believe. I wonder if it would be feasible to use something like UTF16 which has 65k characters or 2**16 or even UTF32, that would make mnemonics much shorter.

Not all 65k characters are in use.

It would be very, very hard to memorize a string of truly random UTF16.

Steven Hatzakis

@forest ah, like non-printable control characters right? (i.e. carriage return)

For that matter, you could use UTF8 as well. It can expand to any number of characters.

The only difference is that the minimum size is smaller.

@StevenHatzakis Well I meant more like emoji, kanji, etc.

If you don't speak Japanese, you aren't going to remember distinct kanji.

Steven Hatzakis

7:16 AM

I've actually heard ideas of people wanting to create mnemonics from emojis :)

@forest arigato

どういたしまして

That's horrifying.

Steven Hatzakis

There are probably some experimental mnemonic emoji software scripts out there somewhere on github.. hehe

3 hours later…

10:01 AM

@StevenHatzakis like cyrillic A vs latin A (which I think usually are rendered the same despite having different unicode code points)

4 hours later…

1:42 PM

@forest my old AIX password was 僕の犬nameisRon

(my dogs name is Ron)

Firstly, my dog's name was not Ron. AIX was the only system that let me have a UTF8 encoding for a password. MacOS will let me have a username as UTF8, but I've never tried UTF8 for a password as not everything I'm on supports it.

goo.gl/maps/kD2Ss16om48sprn26

2:37 PM

@SEJPM And a billion and one other homoglyphs.

A bunch of different encodings of "A". What a nightmare.

of course, it's as ridiculous as most password rules.

I prefer plain 7-bit ASCII for passwords.

Completely unambiguous.

It was the novelty of it.

Random question, but @bdegnan would you happen to know how much faster Whirlpool is in dedicated silicon than SHA-512? The former is AES-based with recursive 4-bit S-boxes. The latter is ARX and 64-bit transpositions.

I don't know off the top of my head. Let me glance at some docs and see if I can make a guess.

2:50 PM

I'm fairly sure that Whirlpool is faster, but no idea how much faster.

It uses 8-bit operations, has a recursive S-box structure, and otherwise is basically AES with a 512-bit block, 10 rounds, and a different polynomial. Whereas SHA-512 uses 80 rounds involving 64-bit addition, rotations, XOR, and a few boolean functions.

Wondering because SHA-512 might be better for PBKDF2 than Whirlpool in that case.

This is all very "touchy feely"; however, Whirlpool seems to be about 10x faster than SHA-512. This speed is on-par with BLAKE2, but Blake takes 1/2 the power compared to Whirlpool

I have a document from a project where these were done on 90nm.

I say it's "touchy feely" as it was semicustom silicon. it was FPGAs retargetted to ASICs.

Oh wow, that is fast.

Seems Whirlpool is bad for PBKDF2 just as SHA-3 is.

One sec... let me see what else I can find

Since Whirlpool is slower than SHA-512 in software, that increases the gap even further.

So, I have a document, but I don't have the specs of anything. It's very vague as the source was a past collaborator and this is the "cleaned" version of the document.

2:57 PM

"cleaned"?

Just guessing, I believe this data to be ballpark. The unclassified academic, remember. I get a lot of stuff that's missing the scope, etc.

Sure, but the ballpark is all I needed.

█████████ ███████████ ████ ████████████ waterboarding. :P

( ͡° ͜ʖ ͡°)

Future Security

@StevenHatzakis The are 3 such lists. In one of them no two words share the same 3 letter prefix. It's a shorter list than the original.

RE Unicode passwords, applications should use "compatibility" canonicalization before hashing passwords.

Future Security

3:35 PM

NFKD specifically. You lose some of the original data in the string, but it does things like convert Ⅶ to VII, 𝔸 to A, ² to 2. Besides normalizing codepoint sequences. (Accents and other modifiers are expanded and put in the right order.)

It's preferable to NFD because it makes transformations that help cover input errors or differences in keyboards and software. NFKC composes instead of decomposes codepoint sequences... The only reason you don't use compose is because new codepoint shortcuts may be added to the unicode standard, so it's not as backwards compatible as decomposition.

4:08 PM

@Patriot Just a notice: I'm purging my PGP key. Don't have time to save it. Sorry.

(was stored in tmpfs and can't get it on another computer, but computer is going down)

ack, sounds like terrible things.

What's NFKD?

4:27 PM

@forest OK. I will destroy my copy. I saw that message you put on it--don't put it on a server.

I just spent six hours of my life reading about the Enigma machine.

One little weakness. One mistake. Kaput.

7 hours later…

Future Security

11:33 PM

Just Unicode terminology bdegnan. One of a bajillion things under the tip of the iceberg.

Unicode is huge. Lots of subtle confusing details that no one has the capability to fully understand. Not fun to program around stuff like that if you worry about security.

There is useful software, though. For example there's an official Unicode project which includes code for detecting "confusable" character sequences. (Like using Cyrillic mixed with ASCII in URLs)

"wikipediа.org" != "wikipedia.org" :-/

« first day (2947 days earlier) ← previous day next day → last day (1729 days later) »

Transcript for

Aug '197

The Side Channel

Mostly randomly generated noise. – crypto.stackexchange.com

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile