On 05/15/2013 05:02 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
I see that the ARM version is following the pattern of SPARC64 and X86
SSSE3 in how it is configured, so for fear of opening a can of wor
On Wed, 15 May 2013, Ard Biesheuvel wrote:
> On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> > I see that the ARM version is following the pattern of SPARC64 and X86
> > SSSE3 in how it is configured, so for fear of opening a can of worms,
> > perhaps it's simpler if we just go with the linaro
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
> On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> > I see that the ARM version is following the pattern of SPARC64 and X86
> > SSSE3 in how it is configured, so for fear of opening a can of worms,
> > perhaps it's simpler if we just go wi
On 15 May 2013 14:38, Jon Medhurst (Tixy) wrote:
> I see that the ARM version is following the pattern of SPARC64 and X86
> SSSE3 in how it is configured, so for fear of opening a can of worms,
> perhaps it's simpler if we just go with the linaro-base.conf patch which
> started this thread? :-)
>
On Wed, 2013-05-15 at 14:12 +0200, Ard Biesheuvel wrote:
> On 15 May 2013 14:05, Jon Medhurst (Tixy) wrote:
> > If the assembler version is always faster I would have thought that we
> > should always have it enabled and not have it as a user visible option.
> > Perhaps the fact that the assembler
On 15 May 2013 14:05, Jon Medhurst (Tixy) wrote:
> If the assembler version is always faster I would have thought that we
> should always have it enabled and not have it as a user visible option.
> Perhaps the fact that the assembler is specifically target at ARMv4
> means that on ARMv7 CPUs the l
On Wed, 2013-05-15 at 10:17 +0200, Ard Biesheuvel wrote:
> On 14 May 2013 18:49, Jon Medhurst (Tixy) wrote:
> >
> > This also enables CONFIG_CRYPTO_SHA1 which we didn't already have
> > enabled in our builds, so I assume nothing actually needs this option.
> > If that's true, then it doesn't seem
Why not default to sha512 while still supporting sha1
On Wed, May 15, 2013 at 10:20 AM, Ard Biesheuvel
wrote:
> On 15 May 2013 07:03, Jonathan Aquilina wrote:
> > Not trying to hijack this thread, but I studied in my security class that
> > SHA1 is being attacked so to speak in terms of crypto
On 15 May 2013 07:03, Jonathan Aquilina wrote:
> Not trying to hijack this thread, but I studied in my security class that
> SHA1 is being attacked so to speak in terms of crypto analysis and it was
> suggested in the book that it not be used but something like SHA512 be used
> instead.
>
Hello J
On 14 May 2013 18:49, Jon Medhurst (Tixy) wrote:
>
> This also enables CONFIG_CRYPTO_SHA1 which we didn't already have
> enabled in our builds, so I assume nothing actually needs this option.
> If that's true, then it doesn't seem worth enabling an optimised version
> of code which isn't going to
Not trying to hijack this thread, but I studied in my security class that
SHA1 is being attacked so to speak in terms of crypto analysis and it was
suggested in the book that it not be used but something like SHA512 be used
instead.
Just to give you all a heads up :)
On Tue, May 14, 2013 at 6:49
On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote:
> These assembler implementations of SHA1 and AES have been
> in the upstream source tree since September 2012 but need
> to be selected explicitly in order to be enabled.
>
> Signed-off-by: Ard Biesheuvel
> ---
> linaro/configs/linaro-bas
These assembler implementations of SHA1 and AES have been
in the upstream source tree since September 2012 but need
to be selected explicitly in order to be enabled.
Signed-off-by: Ard Biesheuvel
---
linaro/configs/linaro-base.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/linaro/con
13 matches
Mail list logo
