The following text made me instantly ctrl-w close the browser tab I was on.

> We present Mercy, a new block cipher accepting large (4096-bit) blocks, which uses a key-dependent state machine to build a bijective F function for a Feistel cipher. Mercy achieves 9 cycles/byte on a Pentium compatible processor.

The 4096 block got my (skeptical) attention. Figured it would at least be interesting or funny. "Key-dependent state machine" made me lose interest immediately.

Just noticed there's a warning on the same page. Good on them for doing the minimum responsible thing. Kind of... It would have been better at the top of the page.

> Mercy is weak: a highly effective differential cryptanalysis-based distinguisher across all six rounds was presented by Scott Fluhrer at FSE 2001. A new version of Mercy resistant to this attack may be forthcoming at some point; until then, Mercy should definitely not see real use.

Thought I'd look at obscure block ciphers and see how many were designed to use blocks larger than 128 bits.

Red Pike is different. 1996 algorithm that uses modular addition, subtraction, and data dependent rotation. Round key's are generated using rk += const; sort of like TEA. Designed such that decryption is identical to encryption with a different key. 64 bit block size and key size.

@FutureSecurity A 256-bit block would be an improvement, because the birthday bound is so large as to be irrelevant for that. It's a shame AES was limited to 128-bit blocks.

That's what I was thinking. I'm interested in software efficient 256-bit block ciphers.

As for algorithms I might be confident in, I only know of Rijndael and Threefish.

Threefish, if I remember right, is kind of slow. I guess because it uses so many rounds. The fact that it also uses such a complex sequence of different rotate distances is kind of disappointing too. ARX constructs can be so simple, but not when done that way. (Not sure if it's like that because it needs to be or if it's like that because they were being cautious in their proposal.)

Rijndael I know supported more block sizes than just 128-bits, but I've never looked at how, specifically, those versions were different. :-/ A fast constant time implementation might not exist.

@J.J This is a US centric site. I find that most programming languages and such try and keep to US spelling. But besides that, changing the language of the asker is not what edits are about; they are to clarify the questions and making them more readable. You should not be trying to change the nationality of the poster if only because that's an act of futility.

So pleaze do avoid injecting such changes or I'll do this again ;)

Thanks for the edit; it was definitely needed.

Well, I was still talking about the one with the S -> Z, but the other edits as well :)

Uh, Z -> S

Uh, what's an edit curfew (mods don't have those)?

No, we can even do things like above :P

And revert them again

Cause that's abuse of mod power.

Linky?

Done.

But, uh, don't ping me for each one please.

@Maeher I like the last ones!

I certainly hope little things can make you feel happy as well...

Hey, quoting Snatch is always OK.

Or from Portugal. That's an entire nation that (used to) live on emo music.

It's called Fado music and you can still listen to it. If you like that stuff, plan a sunny holiday, spring is in the air here on the North side of the planet.

Actually, the sun is shining and for some reason I'm still inside. I'm out catching some rays. Some movement always brings out the right spirit in me.

(actually I also do go out and catch some rain some days, but I'm in too much).

On average it rains for 156.2 days per year (data from 1981 to 2010). So there's still 200 days without rain.

Buy outdoor stuff :)

We go kayaking in winter.

That won't make you happy, I guarantee you that. OK, enough, I'm going out now.

@FutureSecurity schneier.com/academic/skein/threefish.html advertises ~6 cpb on ten-year-old Intel hardware, and Threefish software will tend to run in constant time naturally, which beats the pants off AES.

The highly upvoted answers on crypto.stackexchange.com/q/419 are still wrong. Got nearly a decade of spurious upvotes to undo here.

Actually I guess crypto.stackexchange.com/a/435 isn't wrong because it doesn't address collision resistance at all, and strictly speaking the question only mentioned collision resistance but didn't ask about it. But the accepted answer is wrong.

@SqueamishOssifrage It looks like compared to AES speeds on 10 year old hardware is at least half that. Which makes Threefish look impressive. Especially since it's got larger keys, larger blocks, is tweakable, and should work as an ideal model block cipher.

crypto.stackexchange.com/a/1562 is hardly even an answer.

That is one of the issues I have with this site. Redundant HNQ answers that are at best half right. Down votes being so much less valuable than up votes. People being too quick to up vote. And old answers that are too up-voted for corrections to bubble up to be visible to visitors.

The voting thing I can see as being important for retaining users. It's still unfortunate. A solution to the last problem sounds pretty difficult.

I wonder if any other websites try and had success at the old popular misinformative post problem.

Maybe leave the up/down vote numbers intact but instead sort by which posts have the highest score considering on the last X votes. (For example, let new votes replace oldest ones for ranking purposes after receiving 25 votes.) Or look at the most recent votes on all answers and sort by which one has the best ratio.

It wouldn't solve the network-effect-like problem and has potential abuse problems. It might be useful in cases where a question gets more scrutiny either because it got more popular or if the community learns something that changes the validity of the answer. (Like if someone recommends an algorithm and then a surprising break gets announced.)

@kelalaka You minding chat?

No problem, Open a channel.

thanks

Moderators? Migrate to serverfault? crypto.stackexchange.com/q/68106