On Fri, May 05, 2017 at 10:48:30PM +, Christian Weisgerber wrote:
> On 2017-05-05, "Peter J. Philipp" wrote:
>
> > This is my second official contribution to what I call ELFSEC, it places a
> > signature in binaries, in the ELF header to be exact.
> -snip-
>
> How does this defend against b
On 2017-05-05, "Peter J. Philipp" wrote:
> This is my second official contribution to what I call ELFSEC, it places a
> signature in binaries, in the ELF header to be exact.
-snip-
How does this defend against binary code introduced as a shared
library by way of LD_LIBRARY_PATH or LD_PRELOAD?
On Fri, 5 May 2017 17:56:11 +0200
> If CMAC's can be truncated then this entire implementation can be
> rewritten to not truncate for 64 bit machines and truncate for 32 bit
> machines.
There is also POLY1305-AES which is a little stronger. The more you
limit failed MAC requests the more you can
On Fri, May 05, 2017 at 05:25:57PM +0100, Kevin Chadwick wrote:
> > There was concern about my use of MD5 HMAC's so I
> > took them out. The ELF header of 32 bit systems is too small to fit
> > SHA256 checksums, so I'm leaving it out.
>
> Have you considered CMAC which can be truncated if need b
On Fri, 5 May 2017 14:16:37 +0200
> There was concern about my use of MD5 HMAC's so I
> took them out. The ELF header of 32 bit systems is too small to fit
> SHA256 checksums, so I'm leaving it out.
Have you considered CMAC which can be truncated if need be and also
could take advantage of AES
This is my second official contribution to what I call ELFSEC, it places a
signature in binaries, in the ELF header to be exact. This set of patches
are against 6.1 sources not -current. While I think it's somewhat premature
to send this in, some people in #openbsd on efnet were very interested
