Re : Pachyderm Squatters

I’m still wondering when “Robbins pentagons”[1] will be looked at as a candidate one way function đ

[1] Named after mathmetician David P. Robbins back in 2008, in the paper “Cyclic polygons with rational sides and area” authored by Ralph H. Buchholz and James A. MacDougall.

https://en.m.wikipedia.org/wiki/Robbins_pentagon

Robbins Pentagons have some interesting properties of which one springs out from the papers title, which is that every Robbins Pentagon is scaled from a base where it’s area and side lengths are all integers, less obvious is that there are also an infinite number of the bases. When you consider Crypto is after all being about integers and the mappings between them. Further consider that a circle of radius and center can be described by any three points (including the degenerate circle of zero area you might call a straight line). As some know the circle is a basic example of a secret sharing system that can be used for a key exchange system.

]]>Again, the issue here per young Clive, âThe research paper published over the weekend shows how SIDH is vulnerable to a theorem known as âglue-and-splitâ developed by mathematician Ernst Kani in 1997, as well as tools devised by fellow mathematicians Everett W. Howe, Franck LeprĂ©vost, and Bjorn Poonen in 2000. The new technique builds on whatâs known as the âGPST adaptive attack,â described in a 2016 paper.”

So, why didn’t the experts that NIST employ know that the proposal was flawed?

Standards involve trust of underlying expertise. Security standards… a lot more trust. If NIST doesn’t produce an autopsy plausibly explaining a mea culpa, that trust should not be deserved.

]]>One advantage of RSA and other classic algorithms is that they require little more than high school math. Using well-understood math reduces the places a flaw can hide, plus it also reduces the barriers to entry for budding cryptoanalysts. Looking at the lattice-based approaches, they aren’t exactly easy, but they appear approachable to anyone with a math major. It’s basically polynomial equations using integer constants. These are among the NIST finalists that are still in the running.

]]>Re : ROT N

Ahh the good old days pre the Web, of bad/course jokes on UseNet being obfuscated by ROT13 back in the 1980’s[1]. So common that many could read it by sight…

Apparently still in use by Microsoft in the Registry[2]…

But ROT like IntADD, XOR, and bit shifting with carry around are linear and will “sum up and roll over” just like the mechanical odometer and “trip-meter” in a car where those old enough used expressions like “Distance on the clock”.

But… Even if you mix ROT, IntADD and XOR operators up you end up with a simple mapping function, or substitution cipher. Therefor the only security gained on the map is to make the alphabet size to large to build look up tables, subtables, or their equivalent. So the usual way of getting security is to pre-mix or “whiten” either the input or output with one of the operators, and another value such that it changes with every use of the mapping function. You can see this if you draw it out, and it is the basic idea behind the Feistel Round[3] that is used in many block ciphers.

Whilst the Fiestel Round and it’s many variants are common, usually the “round subkeys” remain constant for any given block cipher key.

A little thought will make you realise that each round is a mixing function the same as used in a stream cipher… Thus you could ask yourself the question of “What if you actually used a stream generator for each function?”

One upside is you can significantly reduce the number of rounds. A second is that in hardware you can run stream generators in parallel and thus get a very high speed of operation…

[1] For those young enough not to know, the old jokes, the result of multiple ROTs is a single ROT of the sum of the individual rots mod the alphabet size.

So ROT13, ROT13 is ROT26 with the Latin alphabet size of 26 gives ROT0 or the ciphertext is the plaintext.

[2] Dider Stevens even wrote a decoder for it back in 2006,

https://blog.didierstevens.com/2006/07/24/rot13-is-used-in-windows-youâre-joking/

[3] See more on Horst Feistel’s work,

]]>I would go with ROT2, ROT3, ROT5, ROT7, ROT11, ROT13, ROT17, ROT19, and ROT23.

Your secret sauce is the order.

You may be able to get a Software Patent.

Magic đ

]]>re: how do Alice and Bob securely establish âthe rulesetâ?

This is the problem in a nutshell.

I realize this is a very hard problem.

I am just saying to not make the problem more complex.

Complexity is just going to add more attack surface, and more room for human error.

]]>Thanks for the info. I’m glad it is you. Someone impersonating you here would be worse than someone impersonating Bruce. Worse in the sense that I imagine a Bruce impersonator would be detected sooner. After all, I don’t come here just for the Schneier and the calamari. (Using my incorrect pronunciation, spoken out loud that sounds like a squid gave a blackeye to a cook when the squid refused to become an appetizer, which ironically is the basis for a new movie-plot threat.) ]]>

If I submitted ROT13, would that pass the gate and make the list?

]]>You’ve made a fatal assumption with,

“If Eve does not know what the ruleset is that Alice and Bob are using, Eve will have a difficult time.”

But with no prior contact how do Alice and Bob securely establish “the ruleset”? Which after all forms part of the root of trust…

If they can securely transfer part of the root of trust, then they can securely transfer all of it at the same time.

Remember three things,

1, PKI is assumed compromised / broken.

2, Alice and Bob have never ever met or interacted before, so have zero knowledge and zero trust.

3, They have no secure side channel.

re: Circle Points Crypto

While it could work, it is a non-starter to me.

It seems like it just makes the problem worse.

If Alice and Bob, need to have a shared secret key, they can do that with PKI. But, they have to hope it is not MITM-ed.

But, with the Circle Points Crypto, you have made it more complex to use, and created additional points for traffic analysis to come into play. Maybe Alice and Bob do not care if others know they are communicating, but maybe they do. It depends upon their respective threat models.

I can not justify turning a 1:1 problem into a 2:3 problem.

If I am Alice or Bob, how can I trust Larry, Moe, and Curly to flip coins and report results accurately?

Furthermore, how would it be coordinated without additional traffic? How would Larry know to send his Nonce to BOTH Alice and Bob? He would have to know, which then leads to a possible betrayal problem in that Larry could reveal that Alice and Bob are communicating.

Alternatively, it would make more sense for the Larry, Moe, and Curly to just broadcast al la Numbers Stations, and Alice and Bob have an agreed upon ruleset that says, for example, we will grab N bits from Larry every day at a certain time, N bits from Moe at a different time, and N bits from Curly at some time, and use them to construct their shared secret key.

If Eve does not know what the ruleset is that Alice and Bob are using, Eve will have a difficult time.

Security is recursive. I would not make the protocols more complex.

]]>