[openssl-users] Authentication over ECDHE

[J. J. Farrell]

On 29/12/2018 17:18, C.Wehrmeyer wrote:
> On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct 
> portable code which derives obviously and
> > straightforwardly from the specification, you'd write arrays of a
> > different length from the original, the first 48 bytes of which would
> > only be correct in some compilation environments, and even in the cases
> > where those 48 bytes end up correct they have no obvious 
> relationship to
> > the specification they are implementing (your obfuscation making the
> > code much more difficult to review). How are these changes improvements?
> Another implication, this time that my code isn't perfectly portable 
> code. There is *one* environment I could think of where this wouldn't 
> be the case - that being Shift JIS environments that tinker with ASCII 
> standard by replacing a backslash with a Japanese half-width Yen sign 
> - however:
>
> 1. we'll already have much, MUCH bigger problems if ASCII isn't the
> encoding the compiler is expecting here, so exchanging 0x5c for '\' is 
> not going to ruin much more here. And it doesn't even matter anyway 
> because any Shift JIS editor would display this as ...

You don't explain the benefits of coding a requirement for "the byte 
0x5C repeated 48 times" as a string of back-slash characters instead of, 
well, the byte 0x5C repeated 48 times. What are the benefits, and how do 
they outweigh the ability to compare more easily against the requirement?

You don't explain the benefits of writing non-portable code where that 
code is very widely deployed in environments of which you have no 
knowledge (and which don't even exist at the time of writing it), 
without even a comment specifying the portability restrictions you are 
imposing, when it's just as easy to write the code portably and not need 
to think about such restrictions. What are the benefits, and how do they 
outweigh the obvious disadvantages?

-- 
J. J. Farrell
Not speaking for Oracle