Hacker News new | past | comments | ask | show | jobs | submit | kangalioo's comments login

But what's wrong with sending the number as a string? `"65537"` instead of `"AQAB"`


The question is how best to send the modulus, which is a much larger integer. For the reasons below, I'd argue that base64 is better. And if you're sending the modulus in base64, you may as well use the same approach for the exponent sent along with it.

For RSA-4096, the modulus is 4096 bits = 512 bytes in binary, which (for my test key) is 684 characters in base64 or 1233 characters in decimal. So the base64 version is much smaller.

Base64 is also more efficient to deal with. An RSA implementation will typically work with the numbers in binary form, so for the base64 encoding you just need to convert the bytes, which is a simple O(n) transformation. Converting the number between binary and decimal, on the other hand, is O(n^2) if done naively, or O(some complicated expression bigger than n log n) if done optimally.

Besides computational complexity, there's also implementation complexity. Base conversion is an algorithm that you normally don't have to implement as part of an RSA implementation. You might argue that it's not hard to find some library to do base conversion for you. Some programming languages even have built-in bigint types. But you typically want to avoid using general-purpose bigint implementations for cryptography. You want to stick to cryptographic libraries, which typically aim to make all operations constant-time to avoid timing side channels. Indeed, the apparent ease-of-use of decimal would arguably be a bad thing since it would encourage implementors to just use a standard bigint type to carry the values around.

You could argue that the same concern applies to base64, but it should be relatively safe to use a naive implementation of base64, since it's going to be a straightforward linear scan over the bytes with less room for timing side channels (though not none).


Ah OK so: readable, efficient, consistent; pick 2.


Converting large integers to decimal is nontrivial, especially when you don't trust languages to handle large numbers.

Why you wouldn't just use the hexadecimal that everyone else seems to use I don't know. There seems to be a rather arbitrary cutoff where people prefer base64 to hexadecimal.


Size: base 64 is 2/3 the number of bytes as hex.


This sounds like an XY problem to me. There is already an alternative that is at least as secure and only requires a single base-64 string: Ed25519.


PHP (at least old versions I worked with) treats "65537" and 65537 similarly.


That sounds horrible if you want to transmit a base64 string where the length is a multiple of 3 and for some cursed reason there's no letters or special characters involved. If "7777777777777777" is your encoded string because you're sending a string of periods encoded in BCD, you're going to have a fun time. Perhaps that's karma for doing something braindead in the first place though.


Cost.


Too likely that this would not work because silent conversion to number along the way


Then just prefixing it with an underscore or any random letter would've been fine but of course base64 encoding the binary representation in base 64 makes you look so much smarter.


Why does the specification specifically mention them, then?


To clarify that by the spec, double quotes are allowed in the cookie value, but only at the beginning and end.

As for why that is, I have no idea.


I'm afraid this introduces too much magic

Personally, "0%" doesn't mean "hasn't started" to me, it means "not enough progress has happened to reach 1%". Assuming I'm not alone with that, the rounding becomes a simple truncation `roundedPercent = int(percent)`

An implementation as simple as the concept, which is a good sign in my experience


Can be pretty fast if you know your tools well :)

Just tried in VSCode; 2:38min using its fabulous multiline editing. 1:34min on second try due to practice


I will never understand how people think like that. Sure, there are things computers cannot compute, but that's because those things are _uncomputable_ in general


It's obvious to you because of people like Church and Turing. Until their work on the Entscheidungsproblem was published, it was not only common, but mainstream to believe that nothing was inherently incomputable. They not only demonstrated that there were things that weren't, they did so by proving that the set of everything computable was the same set of things their approaches could compute and that certain problems were outside that set.


Yeah, that's definitely fair. What I'm annoyed about is the "checkmate, computers" stance, pretending like the problems computers cannot solve could be solved by other means


It was obvious to Turing and Church because of Gödel; incompleteness theorem restated.

Einstein, Gödel, and a few others verified work means the majority of us are coloring within the lines they drew until we die.


I don't believe only turing machines are capable of executing other turing machines... Surely lambda calculus can do the same? I was under the impression, lambda calculus can indeed execute itself with even less code than turing machines

There's several very dubious claims that are stated way too confidently like this in the article, like "Yep, virus scanners are almost completely useless"


They are equivalent per the Church-Turing thesis; how many instructions it takes doesn't factor in at all.


Author here.

Yes, the lambda calculus can. They are equivalent.

But Turing's machines gave us the model to think that way. In my opinion.


What does it for me is that turing machines can be thought of as physical. In a way it is more tangible than an electronic computer.

Btw: I think your site would look better with left justified text. Right justified looks best only for long paragraphs (books).


Yeah, I was told about left justification last week. Haven't gotten to it since I am in the middle of release crunch.


WebAssembly is not without tradeoffs either. I'm not an expert, but it's often heavier due to bundling the native language's stdlib; it's annoying to interop with the browser environment because that's still JavaScript-tailored; it's also just hard to write code that can be compiled into WASM (e.g. in Rust, it needs to be `#[no_std]`)


If you're doing real work, you don't interact with the browser.

If you're just glueing things together between APIs, then JavaScript is fine, and static typing would just get in the way.


Good point. When I'm going back and forth writing code and checking its assembly, I also reason about the compiler almost like an intelligent being:

"oh, it doesn't see this condition, so if I help it a little bit, then... Ah now it unrolled, and inlined, but accidentally trashed instruction cache, how will I convince it not to..."


In the linked answer, there's a two-word full answer phrase:

> So I would cut this down to something like nimium valedīxit or totiēns valedīxit: "she bade farewell too much before" or "she bade farewell so many times before".


Roughly 2x slower in my experience. The main annoyance are the many changes. Every change carries risk of missing the connecting train


For a recent family/friends get-together we had some people going routes using ICE trains (where possible) while others used the 49 Euro ticket. 2x slower is pretty spot on.


This observation does not correlate with my pop culture understanding of ruthless German efficiency.


There is no such thing. Most things in Germany generally are delayed. Wether it's construction projects, really ANY construction from an autobahn local repair to a house to large projects like BER airport or Stuttgart 21 or Zweite Stammstrecke in Munich to literally every Deutsche Bahn ride.

I've been on a Deutsche Bahn train for the first time in two decades when I visited Germany again last week. I had a short regional connection on an Regional Express train (RE) to make it to the 'high speed' ICE train. The RE train was 56 mins delayed or my generous 24 min connection. So I had to be driven by car instead to make it. The ICE 'high speed' train never hit more than 160kph and that only for minutes. A long time it was slowly creeping along at 40-50kph. My (on-time departure) 2 hour ICE train got me into Frankfurt 28 minutes late.

The air conditioning was too weak. The train (1st class) was extremely overbooked. People walked through the aisle continuously to try to grab a seat from someone. The noise level as defeaning (even with noise cancelling Bose) and the service was well... not in service. Food that was advertised couldn't be ordered. The internet connection via WiFI wasn't working either.

Hopeless. Next time I visit the country I'll rent a car again.


It is a pop culture thing, I really wonder when such misconceptions will end. German are striking as often and sometimes more than the French, and their train are very often late, meaning a high chance of missing your connection. When I can I take a train without connection. Even in my very limited use of German trains, I still average around 50% missing connections.

I had to take 3 trains a few weeks ago, the first one was 20min late, meaning I missed my first connection. It turned out no big deal because the train I was supposed to get into didn't leave: it was broken! I had to wait an hour at the station, then I had the chance to jump into a packed train (remember the previous train which did not come?). It was such a pleasure.


That's the typical Deutsche Bahn experience. Haven't seen anything else for the 27 years I lived there


It's a thing from the past. Last year the punctuality of Deutsche Bahn long range trains dropped to 65%.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: