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

21–30 of 203 posts

Re: The Rune Programming Language

#21

Post by wolf550e »

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…

You guess the MAC tag value of the message and measure how long it takes the server to return "bad MAC" error or behave in a way that means the MAC was bad. In 1/256 cases, it takes longer because the first byte was correct. You may need to send many queries to get the value because timing is noisy, but with statistics you'll find that value. Now you try all 256 possible values of the second byte and one of them will take longer because both 2 first bytes are correct. Repeat.

For the normal way to safely compare MAC values, see for example: https://docs.python.org/3/library/hmac.html#hmac.compare_dig...

Re: The Rune Programming Language

#22

Post by wolfwyrd »

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 time this method accurately they will be able to tell what the value of actualMac is by feeding known inputs. They will know because the return time will be 2Y when they have bailed after the first byte. 3Y after the second, 4Y after the third etc.

This is why we should check the arrays in constant time - compare every byte in both arrays before returning. We do not return early so we can’t leak information

Re: The Rune Programming Language

#23

Post by nmadden »

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…

Coda Hale’s old article on the topic is still good: https://codahale.com/a-lesson-in-timing-attacks/

(Note that Java’s MessageDigest.isEqual has been constant time since shortly after that article and you should use it rather than writing your own in Java).

Re: The Rune Programming Language

#24

Post by pharmakom »

nmadden wrote: post #23
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…

Coda Hale’s old article on the topic is still good: https://codahale.com/a-lesson-in-timing-attacks/ (Note that Java’s MessageDigest.isEqual has been constant time since shortly after that article and you should use it rather than writing your own in Java).

Freddy the Pig?

Re: The Rune Programming Language

#25

Post by subtra3t »

FreeFull wrote: post #14
pkolaczk wrote: post #9

There already exists Rune programming language and that one was earlier: https://rune-rs.github.io/ They should be more careful picking the name.

There already was a GO programming language before Google decided to use the name, too.

That doesn't justify them choosing an already chosen name now, does it?

Re: The Rune Programming Language

#27

Post by nmadden »

pharmakom wrote: post #24
nmadden wrote: post #23

Earlier quoted context omitted.

Coda Hale’s old article on the topic is still good: https://codahale.com/a-lesson-in-timing-attacks/ (Note that Java’s MessageDigest.isEqual has been constant time since shortly after that article and you should use it rather than writing your own in Java).

Freddy the Pig?

Ha! Wow, looks like there is a redirect when the referrer is HN…

Re: The Rune Programming Language

#28

Post by tmtvl »

FreeFull wrote: post #14
pkolaczk wrote: post #9

There already exists Rune programming language and that one was earlier: https://rune-rs.github.io/ They should be more careful picking the name.

There already was a GO programming language before Google decided to use the name, too.

Ah, so they're repeat offenders. How's it go again? Cache invalidation, naming tconcurrencyhings, , and off-by-one errors?

Re: The Rune Programming Language

#30

Post by vore »

simonebrunozzi wrote: post #2

> This is not an officially supported Google product. Then why is it under github.com/google ?

I believe Google has a practice where all projects that are copyright assigned to them are under github.com/google: https://opensource.google/documentation/reference/releasing
Post reply on HN