Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rune Programming Language

github.com

Post reply on HN
Print view View original

161–170 of 203 posts

Re: The Rune Programming Language

#161

Post by aflag »

henrydark wrote: post #145
aflag wrote: post #124

Earlier quoted context omitted.

You could overload computeHmac's return value so that it would return either a string or a secret, then you could use it directly with checkHmac, if you wanted, or as a string in other applications.

Consider this: I don't even know what hmac is, and it's implemented in a library. Also, I can't overload return values on their own in C++, I would have to overload the whole signature. In fact, to get the same monadic result, I need 2^n-1 overloads for a function with n arguments (one for each subset of the arguments except the empty one). Of course monads' advantages can be coded directly, just as functions can be…

I was just considering a nicer interface for computeHmac at a library level, but if you don't have that, you could still just implement checkHmac using your Secret class and call it with checkHmac(Secret(str), message, mac).

Re: The Rune Programming Language

#162

Post by cormacrelf »

taspeotis wrote: post #53

> The only close competitor is C++, where the author uses the little-known MemoryPool class from the library. I was like I know C++ and I’ve never heard of MemoryPool. Turns out that MemoryPool doesn’t exist in . In the source code they’re talking about it’s an alias to std::pmr::monotonic_buffer_resource. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Why would the struct-of-arrays layout be beneficial in a binary tree where every single node is visited, and the left + right arrays constitute all of the data in the tree? The previous example they gave was touching 75% less memory. In the binary tree it's the same amount of memory. Is the order it's touched better somehow?

Re: The Rune Programming Language

#163

Post by joshuamorton »

halpmeh wrote: post #83
TylerE wrote: post #58

Earlier quoted context omitted.

Seems kind of odd that you’re arguing “just do it in C” and “nothing stops you from forgetting” in the same post.

Why is that odd? You could provide a typed API in other languages that leverages a suite of different side-channel proof algorithms. In order to provide such an API, you need a portable language compatible with the C calling convention for FFI support in other languages. The only language that meets such criteria is C.

You can't provide an API that gives the security features they want in c. The core feature here is a generic secret type. In c that's a void*, defeating the purpose of the typed, safe, API.

Re: The Rune Programming Language

#164

Post by mhh__ »

As per usual with benchmark results they are measuring how much effort or knowledge the authors of the code had.

For example, in D you can write a container that automatically switches from AoS to SoA but most benchmarks are just copy-pasted C++

Re: The Rune Programming Language

#165

Post by henrydark »

aflag wrote: post #161
henrydark wrote: post #145

Earlier quoted context omitted.

Consider this: I don't even know what hmac is, and it's implemented in a library. Also, I can't overload return values on their own in C++, I would have to overload the whole signature. In fact, to get the same monadic result, I need 2^n-1 overloads for a function with n arguments (one for each subset of the arguments except the empty one). Of course monads' advantages can be coded directly, just as functions can be…

I was just considering a nicer interface for computeHmac at a library level, but if you don't have that, you could still just implement checkHmac using your Secret class and call it with checkHmac(Secret(str), message, mac).

It's turtles all the way down. Without the secrets monad support in the language, at some point I have to be the one enforcing secrets in multiple places: if I implement checkHmac(secret(str),...) that calls computeHmac(str)->str then I must both "unbox" the secret(str) _and_ "box" the return value of computeHmac.

I can do this, sure, and if I forget then I'll have a security bug. This is similar to the situation with c++ destructors over c's manual malloc+free. If you're happy freeing at every function's end, then this secrets thing adds nothing for you, and that's cool. It's your own choice what language to use.

Re: The Rune Programming Language

#167

Post by AlotOfReading »

namkt wrote: post #66
ithkuil wrote: post #34

Earlier quoted context omitted.

Google still sells ads, doesn't it?

Didn't they originally claim to never show ads in search given that it is in direct opposition to search results quality? Back in the days when Pagerank was hot.

That was in the original pagerank publications. Google had lots of other early attempts to make money that avoided advertising (like the search appliance [0]), but the firehose of money from ads dwarfed anything else they could ever find and that early Google didn't last long.

[0] https://en.wikipedia.org/wiki/Google_Search_Appliance

Re: The Rune Programming Language

#168

Post by ithkuil »

namkt wrote: post #66
ithkuil wrote: post #34

Earlier quoted context omitted.

Google still sells ads, doesn't it?

Didn't they originally claim to never show ads in search given that it is in direct opposition to search results quality? Back in the days when Pagerank was hot.

Was that a "business commitment" or a "user commitment"?

Re: The Rune Programming Language

#169

Post by fweimer »

wolfwyrd wrote: post #22
WhiteBlueSkies wrote: post #13

Can someone explain how this works: "Assume the attacker can tell how long it takes for mac == computedMac to run. If the first byte of an attacker-chosen mac is wrong for the attacker-chosen message, the loop terminates after just one comparison. With 256 attempts, the attacker can find the first byte of the expected MAC for the attacker-controlled message. Repeating this process, the attacker can forge an entire MA…

This is a timing attack or timing oracle. Lets assume a mac represented in an array of 32 bytes. If we had a pseudocode method like: byte [32] (actualMac, expectedMac) for int x = 0..31 if (actualMac[x] != expectedMac[x]) return false; fi end return true; We return false as soon as we hit an invalid byte in our calculated mac. If the time taken to execute one iteration of the loop is Y and the attacker is able to tim…

Isn't it sufficient to compare 64 bits at a time? Then the oracle becomes rather useless.

Many current memcmp implementations use such large comparisons because they avoid hard-to-predict data-dependent branches for extracting the specific point of mismatch.

Re: The Rune Programming Language

#170

Post by mumblemumble »

aflag wrote: post #159
mumblemumble wrote: post #138

Earlier quoted context omitted.

It seems like we're focusing way too much on just the very first example, instead of the feature list as a whole? There are plenty of other interesting features, such as disallowing conditional branching on the contents of secrets, all the way down to enforcing Spectre and Meltdown mitigations around secrets without necessarily globally taking that performance hit on sensitive and non-sensitive data alike.

I think I'm just not creative enough to think of features that need to be implemented by the language and not easily done at a library level. You could prevent the access to secret's contents by creating the appropriate class, but I suppose it would be harder or impossible to allow the user to peak into the contents but disallowing using them for branching specifically. Though, I'm not sure where that can be useful i…

I'm no expert here, but the arguments I can think of a couple possible arguments. One is that it's not always possible for libraries to ensure that programmers use them correctly. This may be particularly true for systems programming languages that often permit low-level features such as pointers. The second is that the compiler can do things that a library can't.

Spectre/Meltdown mitigation is a great example of the latter. The compiler can be careful to emit instructions that don't permit speculative branching, or disable other optimizations that might expose a security risk. Libraries don't typically get the kind of access that would permit them to do that, and it's not clear to me that a language that does permit such access would be appropriate for safety- or security-critical applications.

As for why if statements are a security risk, they give a tidy little example of that at the bottom of their overview page, under the heading, "Can you see the security flaw in this code?" I can't say I understand it terribly well. I personally take that as a sign that, while I can speculate about why they're doing things this way, and even be arrogant enough to do so in public on the Internet, I'm very, very, very far from being qualified to suggest that their basic approach is wrong. Chesterton's Fence sometimes strikes me as being overblown, but Chesterton's Safety Belt is no joke.

Post reply on HN