[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121210000251.GC4421@openwall.com>
Date: Mon, 10 Dec 2012 04:02:51 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU
On Sun, Dec 09, 2012 at 11:45:41AM +0530, Sayantan Datta wrote:
> Since the real world offset values would never exceed 8 bits ,
Actually, byte-granularity offsets probably would. If you multiply max
B index of 63 by vector width of 64 bytes, that's 4032 bytes offset.
However, several least significant bits of such offsets will be always
zero, and in fact they might not be encoded in instructions (if only
naturally aligned accesses are supported). So, yes, the important
portion of the field should fit in 6 bits.
> I think we should focus on that.
OK, you can look for 6-bit sub-fields.
... On the other hand, if another base offset is added and merged into
the same field, then our 6-bit offset can span a range that is not
representable by a 6-bit sub-field. So 7 bits would be the minimum.
> That way we could also eliminate *endianness issue. *
Not necessarily, because even a field that fits in 8 bits (or less) may
span an octet boundary.
> Okay. So searching the exact values is not the way to go. So basically
> we've to diff two binaries and find the locations where they differ.
Yes, and quite possibly more than two (but not a lot) - to filter out
the noise. In practice you might need e.g. 4.
> And
> since the operands are not at byte boundaries , the operand might be spread
> over two consecutive bytes(considering nonzero 8 bit operands). Also taking
> in account a shift of 0bit and 4bit should suffice , because hopefully the
> size of operands and opcodes are always 4bit multiples. Are there any
> opcode or operand field which is not a multiple of 4bits ?
These definitely don't have to be on a 4-bit boundary, especially not if
we're searching for sub-fields rather than entire fields.
For a specific ISA we could make extra assumptions, but ultimately we
want this to work for more than just GCN anyway.
> Then find the
> deltas in their values and verify it is the same the source
> kernels. Negative numbers may be a problem though , because it would
> require the knowledge of how they are being encoded. For example the 2's
> complement of a small 12bit number say 000000000101 is a very large number
> 111111111011 .
You can assume two's complement, and since you only care about the
deltas it won't matter if the individual numbers are in the positive or
negative range.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
