On Feb 25, 2019, at 1:28 PM, fo...@univ-mlv.fr wrote:
>
>> So encapsulation, controlled by user choice, provides adequate
>> control over this corner case in op== semantics.
>
> it's unforgeable but you can still guess the content of 'i' using a timing
> attack ? no ?
Yes.
These points are not unique to values. They are well known
for non-values. If you use value types as security tokens,
there's a set of best practices you need to follow.
Example this kind of thing today:
class PasswordWrapper {
private String password;
public PasswordWrapper(String password) { … }
boolean checkPassword(String attempt) { … }
// and an anti-pattern:
enum Status { GOT_IT, LOWER, HIGHER, HOTTER, COLDER, … }
boolean Status sniffPassword(String attempt) { … }
}
The timing attacks are equivalent to the presence of a
sniffPassword method. None of this depends particularly
on value-ness.
The new thing you have noticed, Remi, is that value*
classes lack a routine means of forge prevention, the
identity wristband. This is the same thing that int lacks
and String lacks (as usually employed) and VBCs lack
(if clients follow the VBC rules). Does this mean that
ints and strings and VBCs are less secure than opaque
objects? Yes, I suppose they are, by some measures
of security.
If you want a really insecure value, make it Comparable,
so that it can be guessed by binary search. Does this
mean Comparable is insecure?
— John
