maybe this isn’t strictly Kotlin-related, but are ...

# random

[Shawn]

maybe this isn’t strictly Kotlin-related, but are there any Java or Kotlin libraries that make hashing less of a hassle? Python folks can just call hmac.digest(key, message, digest) whereas we have to directly manipulate hasher instance state and can’t even get a hex representation of digests without converting the byte[] ourselves or using Guava or Apache Commons to avoid leaky abstractions

[gildor]

without converting the byte[] ourselves

You can write a single extension that converts byte array to hex, nothing in stdlib or Java for more high level

[Shawn]

I mean, I sure could, even Ktor has its own little hex function https://github.com/ktorio/ktor/blob/77715e078fd40064e740325ad972c44fa76bcd55/ktor-utils/src/io/ktor/util/Crypto.kt#L29

but I mean, this is the kind of thing that most developers shouldn’t need to be concerned with implementing themselves. Ideally this ought to be part of the Kotlin stdlib but at this point I’d settle for a small wrapper library

[gildor]

I don’t think that it should be on Kotlin stdlib. Such function will be platform dependant and cannot be a part of stdlib-common

[gildor]

Or are you talking about hex?

[Shawn]

I was talking about the HMAC functions (ideally with an easy way to get a hex digest), but that’s actually a fair point - secure stuff is definitely going to be platform-dependent

[Shawn]

does the Kotlin stdlib not have any components that are JVM or JS only?

[gildor]

Yes, there are some widely used platform things

[gildor]

But HMAC is not on list of such functions

[gildor]

just write a one class library, if you think it would be useful

[gildor]

But I agree, maybe. ByteArray.toHex(): String would be useful

[Shawn]

lol, I was strongly considering it, but I figured I should ask to see if anyone else had solved this problem before reinventing the wheel

[gildor]

Problem with such things as hmac or any other cryptography, that it has much more than “hex string” or digest function

[Shawn]

I mean you’re not wrong, but it ought to be up to the consumer to decide whether or not they need to stick their hands in the gears, so to speak

[gildor]

My main point: It’s domain specific, platform specific API with a lot of settings and use cases, so shouldn’t be a part of Kotlin stdlib

[Shawn]

Sure, I don’t mean to contest that specific point

[Shawn]

perhaps kotlinx.crypto, to mirror how it’s handled in Java

[gildor]

Yeah, maybe, but it would be a big investment (you need compatible implementation on JVM, JS and different Native platforms) with pretty narrow use case.
I would say it could be a good area for community contribution but not for Kotlin Team, at least on current stage when we are waiting for multi-platform kotlinx.coroutines, http client, http server, serialization, IO and so on

[napperley]

HTTP Server is a big one especially for Kotlin Native.

[gildor]

Sure

[gildor]

And in case of http server it’s known set of features. But cryptography is super wide area, everyone use it for a different thing, in a different way

[napperley]

True however SSL is one of the exceptions.

[gildor]

Yes, but usually ssl used together with http client/server and wrapped to https as protocol

[Vsevolod Tolstopyatov [JB]]

Hi,

We don’t have any solutions for digesting yet and it unlikely finds its way in stdlib in the nearest future.
But hashing and digesting appear here and there, so at some point, I’ll introduce a common library for that. In my mind, it should be something between Guava and Apache Commons for Kotlin common, there is a lot of “simple” stuff which I’m missing in common/Native (UUIDs, hashing, specific collections, random strings etc.).

With crypto it’s a bit more complicated: it’s hard to satisfy everyone and not to become BouncyCastle 🙂 So advanced secure primitives probably will be out of the scope of any common hashing library.

For digesting complex classes, I have a prototype over Kotlin serialization: https://github.com/Kotlin/kotlinx.serialization/issues/163
It’s not exactly what you are looking for, but maybe it can solve more high-level problems, feel free to comment if you finds it useful or something is missing, it will help me to understand wether I should polish it and push it to release