OK, everyone, started off with the nomination page. Don't forget to vote! Tomorrow I'll try and finish the questionnaire on my computer.

@MaartenBodewes good job!

I suspect that if they try to cite how "chaotic cryptography" is an improvement on, well, anything, they won't be able to...

So this question got posted. crypto.stackexchange.com/questions/64662/…

Linked to a verifiable theta inversion github.com/CamMacFarlane/SHA3/blob/master/thetaInverse.py

Now the solution is verifiable but there is not any bit wise rotation in the definition of theta. Which is a talking point if someone is trying to update initial vectors or documentation

@RicheFrame

Ah then checked the code and it runs perfect out of the box, and the sources match with a strange definition of theta. I don't know what a collapsing function is but it feels like something is tweaking bits. and new definitions to tinker with

@EllaRose Can you guess how mad I get when I see the word "chaos" anywhere near "cryptography"?

I don't even know what they mean by chaotic cryptography.

All crypto is supposed to be "chaotic" in that the core of the primitives are deterministic functional algorithms where small changes in the initial state lead to large changes in the final state (pretty much anything that a sponge function can replace could be called "chaotic" or whatever).

Haven't heard of it as a specific technique.

I would expect that they're trying to base cryptography on chaos theory?

Maybe? But chaos theory itself isn't a trapdoor function. The state of some chaotic attractors can be predicted with more or less computation than others.

I didn't say that it's a useful approach. (Though you don't need trapdoor functions to instantiate symmetric crypto.)

@forest universetoday.com/36302/atoms-in-the-universe

of course all estimates

I suppose the estimate is broad enough that it doesn't change substantially regardless of how close the average atom's atomic mass is to 1.

I think so.

I just remembering reading in a biochem textbook a long time ago that the mass of the observable universe is something like 10^80 daltons, and that always stuck with me.

@forest Chaotic cryptography is thrown around as a term in analog hardware when you use chaotic oscillators (ex: Chua's circuit) to encrypt old analog signal lines. As an example: apps.dtic.mil/dtic/tr/fulltext/u2/a503411.pdf The brain reconstructs the noisy line.

Oh huh, that's interesting.

So kind of like audio scrambling for old secure phones?

@forest Yep. The interesting thing is getting the oscillators synchronized and temperature compensated. They are pretty challenging from the circuit perspective, but they work. I've made a few just to demonstrate my temperature compensated circuits. I have no idea how the synchronization is done in actual field implementations. I always had physical access to both boards.

@kelalaka & all. I'm pretty sure that Chaotic Crypto would relate to Chaos Theory most of the time. It always struck me as a rather weird idea; just because there are similarities between chaos theory and crypto doesn't mean that one can use one to accomplish the other.

From Wikipedia "From a wider perspective, without loss of generality, the similarities between the chaotic maps and the cryptographic systems is the main motivation for the design of chaos based cryptographic algorithms."

@MaartenBodewes I don't remember that I said anything about it, :)

Whoops, that was @forest!

Or should have been anyway.

here my opinion: maybe one can achieve with a clever idea. Who knows?

@MaartenBodewes could you give an answer to this

On the internet chaotic encryption is the type of thing people who aren't smart enough to realize they're not a genius believe they can use to jump into the field of cryptography and fix everything.

@FutureSecurity Never mind the fact that - at least for symmetric crypto - the algorithms themselves are not the part that needs to be fixed in the first place.

@FutureSecurity I'm unsure Maarten can give good information about massages...

@kelalaka Poncho beat me to it. I'll do some mod work, and then get dinner.

yeah I saw

"The IV should be unique for each 128 bit text or for each massage?" What kind of massage place gives you an IV?

Sounds like a health hazard.

I just put spelling fixes into the review queue.

...and yes, health hazard

IV reuse turns out to be dangerous in both medicine and crypto.

Doctor: Take one of these pills once a day

Patient: Right. Multiple times per day.

@bdegnan Sorry, beat you to it and the "Community" mod rejected it because of that. Adjusted "pepended". Fixed is fixed :)

I suspect many of the interweb people who think the world needs to know about chaotic encryption are engineers or engineering students that can't be thinking anything deeper than "Chaotic systems are unpredictable therefore..."

← 5 messages moved from December 2018 Cryptography Moderator Election Chat

OK, cool, didn't know that was possible :)

@MaartenBodewes I think only for room owners (=chat room mini mods) and mods

What do you do if library calls can be executed incorrectly without explicit error? Well, you fix the library :)

What fix was applied to what problem?

@FutureSecurity While we're on the subject of medicine: people use fermented mistletoe extract to treat cancer "because it looks like tree cancer". People are very good at finding similarities. That's OK, but we're also very good at jumping to conclusions :)

@MaartenBodewes Assuming mistletoe was tree cancer, the conclusion that drinking tree-cancer would be helpful in any way for anything is quite a leap.

facepalm

Some people believe mistletoe cures cancer, others believe signing is encrypting with a private key. Every field has its weirdos.

Time to hurt everyone's feelings and let the world know that magic isn't real.

@Maeher Uh, see RFC 2313, chapter 10, last section. Those weirdos would include RSA :)

Fair enough, they fixed that in v2 of the document.

@FutureSecurity Sorry, missed that one: in the current branch you should not be able to perform decryption operations on a context initialized for encryption, or vice versa. This is about EVP_DecryptInit and the update / final functions.

Currently you can, and it may correctly run for one mode of operation (like OFB in the linked to SO question) and fail for others (ECB / CBC).

@MaartenBodewes That doesn't make it any better. That and claiming that RSA by itself is anything but a trapdoor permutation are two of the worst sins committed by people claiming to teach crypto.

Though it does serve a purpose to identify people who don't know what they're talking about.

Oh. I think I see. So there were separate "encrypt" and "decrypt" functions and they weren't doing the checks they were supposed to. Then OpenSSL's solution was to rename the function instead of fix the bug? @MaartenBodewes

@FutureSecurity No, somebody delivered a fix, they ignored it for 2 years, then asked the same person to deliver a new fix, the person declined, and then they closed the issue. Now they've restarted it and fixed it (within a day). They were org. asking me for a fix now (one or two if statements) if I wanted it to be reopened.

@FutureSecurity I think I can, it probably approximates how I feel about the subject too!

the election is on!

Yay

Voted ;)

So in Java there's the idiom where you commonly see method overloads func(byte[] buffer) and func(byte[] buffer, int offset, int len) where func(buffer) is equivalent to func(buffer, 0, buffer.length).

The standard MessageDigest class has one digest(byte[] buf) function where buf is the end of the message being hashed and returns a new byte array with the digest value.

But there's also a digest(buf, offset, len) method. In the latter the digest is written into buf...

Seems useful

One is an input parameter. The other is an output.

Legacy APIs guys... It was designed before 1997 and still looks that way.

If It was like digest(buf, offset, len) from the offset, digest len byte, write the result into offset+len

It will be usefull

The method headers should look like byte[] updateAndGetResult(byte[] msgbuf) if you want the former behavior. Or void getResult(byte[] output, int offset) for the latter.

What's also ridiculous is the len parameter to the write out version. If len is smaller than the full digest (output) length then it throws an exception. If you set it to larger than the output length then it only writes as many bytes as are in normal output.

Actually, I don't know that that behavior is universal. The class-level and method-level documentation doesn't specify the intended behavior if len is smaller or larger than expected.

Java version?

@FutureSecurity That latter function with the len parameter is not very common in Java at all, not even in the classes. Yes, it is old. Nowadays you would use ByteBuffer anyway, to have a single parameter for input and output.

But yeah, just use the digest(): byte[] function; the few bytes it produces wont impact performance; objects are created and destroyed all the time. The other one is only interesting because you don't need to create a new buffer all the time.

@kelalaka I think versions 1.1 through 11

@MaartenBodewes I don't know whether crypto API users use the len version or not. I assume that in general array-based APIs are used at least as much as ByteBuffer-based APIs.

MessageDigest doesn't have a digest method that uses ByteBuffers. (For input or output.)

Oh, yes, for certain. ByteBuffers are tricky until you get to know them. MessageDigest only uses ByteBuffer for input data. That makes sense, as that's the one wheere optimization makes sense.

docs.oracle.com/javase/7/docs/api/java/security/…

Note that a ByteBuffer may wrap a "native" buffer, one that is retrieved from a memory mapped file for instance.

Ya. I'm familiar with the nio API.

byte[] is also horrible when it comes to calculating offsets / end of buffer because everything in Java is a signed integer, and unchecked integer overflows are possible. ByteBuffer fixes that.

How? Both use signed int indexes

It's about the calculations. As long as ByteBuffer performs them correctly everything is OK. Just like the memory protection of Java, where buffer overruns are possible, but they are centralized in the JVM.

If you use absolute indexing for bytes you're not gaining anything. Types larger than a byte on a ByteBuffer maybe but overflow isn't much of a problem when you're using KB or MB sized buffers.

And now I remember that ByteBuffer's naming is bad too. Relative operations should have been given names like readShort. Absolute indexing operations should have been named like getDoubleAt.

The problems aren't as serious as those in other languages. But how do these obvious little problems slip through? It's not like Sun or Oracle just had a couple of dudes to review each other's work.

Maybe they did in the early days.

I'm not sure about that. I agree at least that overloading them is not very nice. readShort also doesn't clearly indicate that the cursor (position) is moved, but at least it would be compatible with InputStream. Yes, there are horrible things in Java, but I think it still has one of the best base API's around.

@FutureSecurity Generally you use variables for many things. An adversary may take advantage of that, just like it could take advantage of buffer overflows. Instead of checking at all the locations that receives a buffer, you can check the position, limit etc. in a single class. You don't want to computer on things like a negative length.

Hmm, or maybe read does indicate that. Yes, those are better names. They also forgot to make them generic by the way. ByteBuffer is far from perfect, but it is more OO, and it does prevent some particular mistakes.