Zamicol

More businesses need to hear this message. Google has proven time and time again they cannot be trusted as a service provider, exactly because of this problem.

Very impressive work. Well done on the blog.

This reminds of of the sort of work Nayuki does: https://www.nayuki.io

That is excellent. I'm putting that in my notes.

I'm glad someone is saying this.

This makes zero business sense to me.

{ "pay": { "msg": "There are also other options.", "alg": "ES256", "iat": 1748248973, "tmb": "9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk", "typ": "cyphr.me/msg/create" }, "sig": "sHyMrykhsta5etjqH1e5oho0EpEs2FrblQ0DFHQo0aMgKd2V__SQ2Fl2EOSKt8wl65iLmKgIaMVEgCmhtvbUcg" }

Verify: https://cozejson.com

Spec: https://github.com/Cyphrme/Coze

The Cat in the Hat Comes Back engineering.

Can't fix problems in a project? Increase the scope to make more problems elsewhere. Soon tentacles emerge, everything has problems, and your project doesn't look as relatively bad.

It doesn't, and the problems have only become more problematic over time, but it's the least bad hypothesis that's broadly accepted. I suspect a generational succession is required for new paradigms to be contemplated.

There are many researchers proposing simpler, novel, and testable solutions that seem to go unnoticed. For example, I'm a fan of Alexandre Deur's work. He has some simple and elegant solutions that I've never seen discussed even though they appear "obvious". For example, from 21 years ago: https://arxiv.org/pdf/2004.05905

That paper is suggesting that one of the reasons why galaxies are spinning faster than some calculations expect is because they're failing to account for the gravitational lensing of gravity itself, which bends gravity down towards the disk.

Bingo.

On this exact issue my work did extensive testing and researching various standards.

Although we found browsers were out of alignment with standards on all sorts of matters, we found broad compatibility with upper case. (Of course, meaning everything before the path. The interpretation of the path is delegated to the server which may or may not be case sensitive, up until octothorpe, #, which is then solely interpreted by the browser.)

Base45 does not use all 45 characters

Huh? I don't necessarily care about an exact "base45", I care about QR code alphanumeric, which just so happens to be a (generic) base 45 character set. For QR code, two characters are encoded into 11 bits.

in every slot.

I've worked with the QR code standards pretty seriously and I am unfamiliar with the term "slots" being used by the standards. This is why I suspect your referring specifically to RFC base45 (although the term isn't used there either), which QR code doesn't care about. I also don't care about RFC Base 45 and would prefer to use a more bit space efficient method, such as using the iterative divide by radix method, which I also call "natural base conversion".

base45 takes 32 source bits For QR code alphanumeric, 6 characters use 33 bits, not 32. way to calculate efficiency

The way we calculate this, for example, 2025/2048, we've termed "bit space efficiency". I'm not sure how commonly adopted this term is used in the rest of the industry. On the matter, I thought I had read "the iterative divide by radix algorithm" in industry, but after searching it turns out to be a term novel to our work.

This is also similar to the way Shannon originally calculated entropy and appears to be a fundamental representation of information. Of course log is useful, but it often results in partial bits or rounding, 5.5 in the case of alphanumeric, which is somewhat absurd considering that the bit is the quantum of information, again as shown by Shannon. There is no such thing as a partial bit that can be communicated, since information is fundamental to communication, so the fractional representation we've found to be more informative and easier to work with.

Granted, in all of this, when I have done the math (and I done a lot of math on this particular issue) there appeared to be some very extreme edge cases at the end result of the QR code where some arbitrary data encoded into QR numeric was slightly more efficient than alphanumeric, but overall alphanumeric was more efficient almost all the time. There are other considerations, like padding and escaping, that makes exact calculation more difficult than it's worth. I just needed to "most of the time" calculation and that's where I stopped.

For more detail of my work, my BASE45 predates the RFC by 2 years in 2019, then I published a base 45 alphabet, BASE45, by March 1, 2020, a whole year before the RFC. A patent including BASE45 was submitted June 22, 2021: https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...

Matter of fact, because of the issues and confusion surrounding base conversion, I wrote this tool in 2019:

https://convert.zamicol.com

It is the first arbitrary base conversion tool on the web. It also was essential for our work with QR code and other base conversion issues.

The big lesson from 1936 Turing:

Anything can run DOOM...

...as long as it's Turing complete.

base45 is less efficient

Not according to my math:

Numeric: 1000/1024 = 98%

Alphanum: 2025/2048 = 99%

Byte: 191/256 = 75%

Kanji: 13/16 = 81%*

Alphanumeric is the most efficient QR code encoding mode.

(Just to further make this clear, for QR Byte encoding uses ISO/IEC 8859-1, where 65 characters are undefined, so 191/256, which is ~75%. If character encoding isn't an issue, than byte encoding is the most efficient, 256/256, 100%, but that's a very rare edge case. Also, last time I did the math on Kanji it was about 81% efficient. *I have not dug too deep into Kanji and there may be a way to make it more efficient than I'm aware of. I've never considered it useful for my applications so I have not looked.)

The problem with using base10 is that it cannot encode a URL. Alphanumeric is the simplest QR code encoding mode that can encode a URL.

Also, when I do the math alphanumeric is the most efficient QR mode, although just barely.

I was going to reply to point that out. I'm not surprised you're the one to point it out first!

You'll create an open-source alternative to a popular cloud service that charges too much, saving fellow hackers thousands in subscription fees while earning you enough karma to retire from HN forever.

I'm curious!

There's dozens of us!

One of your comments about the absurdity of centralized authentication will spark a 300+ comment thread and lead to a new open standard for federated identity.

Hmmm...

A cryptography enthusiast who created Coze and spends their days defending proper base encoding practices while reminding everyone about the forgotten 33rd ASCII control character.

The nerd humor was hilariously unexpected.

Your deep dives into quantum mechanics will lead you to publish a paper reconciling quantum eraser experiments with your cryptographic work, confusing physicists and cryptographers alike.

That is one hell of a Magic 8 Ball.

https://hn-wrapped.kadoa.com/Zamicol

That's correct.

Coze uses base64 encoding for binary values such as `tmb` and `sig`. `tmb` isn't a problem since digests are designed to be short, but signatures for some primitive might be very large.

When compared to encoding a value directly in binary, base64 has about a 25% overhead (6 bits /8 bits, 3/4). As far as the concern about using better encoding, base64 is just about as good as it gets while being maximally compatible. If using base 128 (7 bit ASCII), there's too many incompatible special characters for a human readable format. The full 8/8 bits, extended ASCII, isn't generally possible as systems use UTF-8 which begins using multiple bytes. (I've done a lot of work in this area, including a patent on base conversion. See also convert.zamicol.com) An advantage of a binary format is that there is minimal encoding overhead for binary values (escaping/padding is typically the only overhead, so usually around 99% efficient compared to base64's 75%.)

This isn't too much of a concern when signatures are small as encoding inefficiency is small compared to the payload's overall size, but if signatures are in the kilobytes or even megabytes, that extra 25% becomes meaningful for some hyper-efficient applications, like high cost blockchains. Our thought is using post quantum is already much more massive than existing elliptic curve, so any future applications of post quantum are going to have to deal with much larger signatures anyways. The signatures can also be stored on disk using binary or compressed which also makes it not a concern.

We picked the name Coze as a play on words on JOSE ("Cypher JOSE", when Jose is typically pronounced in Spanish, "ho-zay". The English word coze meaning a friendly chat was too perfect for the name of a messaging specification). I somewhat regret not using the three letter "coz".

Cose also picked its name while thinking of JOSE. Cose is binary oriented, and attempts to be as similar to JOSE as possible.

Coze is a first principles reimagining of signing JSON.

As an exercise, we've played around with creating a binary format, (which we're calling Booze, Binary Oriented cOZE) but since Coze is already much more space efficient, it's not as beneficial. It may become more relevant with post quantum, as currently post quantum systems are much larger than ECDSA. The only other advantage would be removing the JSON semantics, but that's at the cost of implementing a binary format. The human readability aspect is paramount for our application, and we feel it's generally better practice.

We addressed these concerns while developing Coze, a cryptographic JSON messaging specification. The specification details how we chose to address these concerns.

https://github.com/Cyphrme/Coze

Password hash functions are intentionally designed to be extremely slow (at an exponential scale). While this makes perfect sense for password hashing, it is nonsensical to have such an intentional, configurable slowdown mechanism in KDFs. KDFs have computational cost, but having the kind of extreme slowdown that password hash functions have makes no sense for purpose designed KDFs, especially when needing to derive many keys.

I wrote the blackout system for Comcast TV scheduling. My understanding was that blackouts were used mostly for sports where games need to be available in one area and not others. Contractually, they were required to use zip codes, so I used the US Post office's zip code data to enforce blackouts.

Password hash functions are designed to be slow, are designed to be use with salts, and may have low entropy inputs.

Hash functions themselves are general purpose and don't protect against low entropy inputs (low entropy passwords). They also don't protect against rainbow tables (pre-calculated digests for common or popular passwords). For password hashing you want something slow and something with unique entropy for each user's password to prevent rainbow attacks.

It doesn't solve the problem of weak passwords, but it's the best that can be done with weak passwords. The only improvement is to enforce strong passwords.

Password hash functions are designed to be slow, are designed to be use with salts, and may have low entropy inputs. Being slow is a waste for (true) KDFs, salts aren't relevant (although nonces may be), and are designed for high entropy inputs.

The naming overlap between the two is bad, so the industry has tried to move towards naming the two differently. Password hashing functions are not ideal KDFs, even though a particular primitive may be secure for use as a KDF. That's a root of some of the confusion.

Unfortunately the industry defined Bcrypt as a KDF for some time, even though it is better named as a "password hashing function". Cryptography has a history of being bad at picking good names for new work.

In addition to (true) KDFs, people often want a HKDF (HMAC-based Key Derivation Function) or hierarchical deterministic key derivation function (HDK).

If China is undermining the West by lifting up humanity, for free, while ProprietaryAI continues to use closed source AI for censorship and control, then go team China.

There's something wrong with the West's ethos if we think contributing significantly to the progress of humanity is malicious. The West's sickness is our own fault; we should take responsibility for our own disease, look critically to understand its root, and take appropriate cures, even if radical, to resolve our ailments.

I canceled my paid sub stack subscriptions because they started to send me unsolicited political advertisements.

That crosses a red line for me and I will not support their business.

You're right that WebAuthn was much more public, but passkey was not.

I personally tried to stay apprised of passkey's development. After asking several developers and poking around the best I could, I was told several times that it was being primarily developed behind closed doors for corporate interests, invite-only, and wasn't ready for release. The only information available was the WebAuthn forums.

Even now the documentation is still poor, and there's essentially no rationale to understand design and architectural decisions. We're just given a spec and expected to adhere to it.