search for: 512bits

...age). Shouldn't this rather be hash(message+key)? In the former situation, it could be possible for an attacker to append something to the end of the data being sent. The attacker would be able to calculate a valid hmac without knowing the key. For instance, since md5 does rounds on blocks of 512bits, where the output of the last round is the input for the first round of the next block; an attacker could just use the existing hmac as input for a new block to append. If the hash were computed as hash(message+key), the attacker would have to know the key to do that. How do people feel about th...

...e is nothing to stop other targets from using > stepvector/seriesvector. In fact for wide vector targets, often the IR > constant for representing a step vector is explicitly expressed as > <i32 0, i32 1, i32 2..> and so on (this gets really cumbersome when > your vector length is 512bits for example). That could be replaced by > a single "stepvector" constant, and it works the same for both > fixed-length and scalable vectors. Indeed! For this particular point, I think we should start there. Also, on a more general comment regarding David's point about Hwacha,...

On 27 November 2016 at 13:59, Paul Walker <Paul.Walker at arm.com> wrote: > Thanks Renato, my takeaway is that I am presenting the design out of order. So let's focus purely on the vector length (VL) and ignore everything else. For SVE the vector length is unknown and can vary across an as yet undetermined boundary (process, library....). Within a boundary we propose making VL a

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision