3 ms·

I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so us

I would recommend using a 24-hours clock, not AM/PM 256-hourglasses. There is also the outrageously absurd idea of putting units next to your entry fields so users know to enter metric values instead of furlongs.

3pt14159 6y ago
Are you being sarcastic? The title is clearly chosen so that it makes the number 25519 in reference to the algorithm.
- chrisseaton 6y ago
  But what has anything got to do with time here?
  - V99 6y ago
    The title is a reference to public service commercials that ran decades ago: https://en.wikipedia.org/wiki/Do_you_know_where_your_children_are%3F https://en.wikipedia.org/wiki/Do_you_know_where_your_childre...
    - deleted 6y ago
      [deleted]
- floatingatoll 6y ago
  Wait, seriously? checks Okay, that's funny. I totally did not realize that at all until I found your comment.
suprfsat 6y ago
I would simply take 255 modulo 24 and use 15 rather than require the user to enter a so-called "canonical" encoding of an hour.
nullc 6y ago
It's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated. Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24. In many kinds of programs it isn't too critical exactly how you handle unreasonable inputs. Garbage in Garbage out. In consensus systems, however, any difference in behaviour can be a fatal vulnerability. Some might find the motivation section of Bitcoin's BIP340 informative: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#Motivation https://github.com/bitcoin/bips/blob/master/bip-0340.mediawi... Or this earlier publication: https://slowli.github.io/ed25519-quirks/ https://slowli.github.io/ed25519-quirks/ (which has more explanation for the S value related issues that the parent article mostly skips over-- but lacks the breadth and the amazing illustration of the incompatibility train-wreak).
- im3w1l 6y ago
  > In consensus systems, however, any difference in behaviour can be a fatal vulnerability. Another issue can come if you have code like this, and different validations are used. if (signature_valid()) { // Safe because we already verified signature. use_signed_message_or_die(); } In practice the check and usage could be very far apart in the code (maybe using the type system to keep track of verified signatures), or even in different programs.

3pt14159 6y ago

Are you being sarcastic? The title is clearly chosen so that it makes the number 25519 in reference to the algorithm.

chrisseaton 6y ago
But what has anything got to do with time here?
- V99 6y ago
  The title is a reference to public service commercials that ran decades ago: https://en.wikipedia.org/wiki/Do_you_know_where_your_children_are%3F https://en.wikipedia.org/wiki/Do_you_know_where_your_childre...
  - deleted 6y ago
    [deleted]
floatingatoll 6y ago
Wait, seriously? checks Okay, that's funny. I totally did not realize that at all until I found your comment.

suprfsat 6y ago

I would simply take 255 modulo 24 and use 15 rather than require the user to enter a so-called "canonical" encoding of an hour.

nullc 6y ago

It's also relevant to the topic because some of the issues its discussing relate to how over full inputs are validated. Do you reduce the 255 mod 24 to decide if the time is acceptable, or do you just reject anything over 23 as unreasonable... or maybe you only reject larger than 99 (because two digits is enough) but from 23 and 99 you reduce mod 24. In many kinds of programs it isn't too critical exactly how you handle unreasonable inputs. Garbage in Garbage out. In consensus systems, however, any difference in behaviour can be a fatal vulnerability. Some might find the motivation section of Bitcoin's BIP340 informative: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#Motivation https://github.com/bitcoin/bips/blob/master/bip-0340.mediawi... Or this earlier publication: https://slowli.github.io/ed25519-quirks/ https://slowli.github.io/ed25519-quirks/ (which has more explanation for the S value related issues that the parent article mostly skips over-- but lacks the breadth and the amazing illustration of the incompatibility train-wreak).

im3w1l 6y ago
> In consensus systems, however, any difference in behaviour can be a fatal vulnerability. Another issue can come if you have code like this, and different validations are used. if (signature_valid()) { // Safe because we already verified signature. use_signed_message_or_die(); } In practice the check and usage could be very far apart in the code (maybe using the type system to keep track of verified signatures), or even in different programs.