--
From: "Ray Dillinger"
Subject: Re: Fast MAC algorithms?
I mean, I get it that crypto is rarely the weakest link in a secured
application. Still, why are folk always designing and adopting
cryptographic tools for the next decade or
--
From: "James A. Donald"
Subject: Re: Fast MAC algorithms?
Joseph Ashwood wrote:
RC-4 is broken when used as intended.
...
If you take these into consideration, can it be used "correctly"?
James A. Donald:
Hence "
Joseph Ashwood wrote:
RC-4 is broken when used as intended.
...
If you take these into consideration, can it be used "correctly"?
James A. Donald:
Hence "tricky"
Joseph Ashwood wrote:
By the same argument a Viginere cipher is "tricky" to use securely, same
with monoalphabetic and even Cea
I recommend Poly1305 by DJB or VMAC by Ted Krovetz and Wei Dai. Both
are much faster than HMAC and have security proven in terms of an
underlying block cipher.
VMAC is implemented in the nice Crypto++ library by Wei Dai, Poly1305
is implemented by DJB and is also in the new nacl library by
--
From: "James A. Donald"
Subject: Re: Fast MAC algorithms?
james hughes wrote:
On Jul 27, 2009, at 4:50 AM, James A. Donald wrote:
No one can break arcfour used correctly - unfortunately, it is tricky to
use it correctly.
RC-4
On Jul 27, 2009, at 4:50 AM, James A. Donald wrote:
From: "Nicolas Williams"
For example, many people use arcfour in SSHv2 over AES because
arcfour
is faster than AES.
Joseph Ashwood wrote:
I would argue that they use it because they are stupid. ARCFOUR
should have been retired well ove
From: "Nicolas Williams"
For example, many people use arcfour in SSHv2 over AES because arcfour
is faster than AES.
Joseph Ashwood wrote:
I would argue that they use it because they are stupid. ARCFOUR should
have been retired well over a decade ago, it is weak, it meets no
reasonable securi
Nicolas Williams wrote:
On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
"mhey...@gmail.com" writes:
2) If you throw TCP processing in there, unless you are consistantly going to
have packets on the order of at least 1000 bytes, your crypto algorithm is
almost _irrelevant_.
[...]
On Jul 24, 2009, at 1:30 PM, Peter Gutmann wrote:
[I realise this isn't crypto, but it's arguably security-relevant
and arguably
interesting :-)].
As long as we think this is interesting, (although I respectfully
disagree that there are any inherent security problems with TOE. Maybe
the
[I realise this isn't crypto, but it's arguably security-relevant and arguably
interesting :-)].
James Hughes writes:
>TOEs that are implemented in a slow processor in a NIC card have been shown
>many times to be ineffective compared to keeping TCP in the fastest CPU
>(where it is now).
The pr
> >2) If you throw TCP processing in there, unless you are consistantly going to
> >have packets on the order of at least 1000 bytes, your crypto algorithm is
> >almost _irrelevant_.
This is my experience, too. And I would add "and lots of packets".
The only crypto "overhead" that really mattered
Note for Moderator. This is not crypto but TOE being the solution to
networking performance problems is a perception that is dangerous to
leave in the crypto community.
On Jul 23, 2009, at 11:45 PM, Nicolas Williams wrote:
On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
"mhe
On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
> "mhey...@gmail.com" writes:
> >2) If you throw TCP processing in there, unless you are consistantly going to
> >have packets on the order of at least 1000 bytes, your crypto algorithm is
> >almost _irrelevant_.
> >[...]
> >for a Linu
On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmann wrote:
> "mhey...@gmail.com" writes:
>
>>2) If you throw TCP processing in there, unless you are consistantly going to
>>have packets on the order of at least 1000 bytes, your crypto algorithm is
>>almost _irrelevant_.
>>[...]
>>for a Linux 2.2.14 ker
"mhey...@gmail.com" writes:
>2) If you throw TCP processing in there, unless you are consistantly going to
>have packets on the order of at least 1000 bytes, your crypto algorithm is
>almost _irrelevant_.
>[...]
>for a Linux 2.2.14 kernel, remember, this was 10 years ago.
Could the lack of suppo
--
From: "Nicolas Williams"
Sent: Tuesday, July 21, 2009 10:43 PM
Subject: Re: Fast MAC algorithms?
But that's not what I'm looking for here. I'm looking for the fastest
MACs, with extreme security considerations (e.g.
On Wed, Jul 22, 2009 at 1:43 AM, Nicolas
Williams wrote:
>
> But that's not what I'm looking for here. I'm looking for the fastest
> MACs, with extreme security considerations...In the crypto world
> one never designs weak-but-fast algorithms on purpose, only
> strong-and-preferably-fast ones. An
On Wed, Jul 22, 2009 at 06:49:34AM +0200, Dan Kaminsky wrote:
> Operationally, HMAC-SHA-256 is the gold standard. There's wonky stuff all
> over the place -- Bernstein's polyaes work appeals to me -- but I wouldn't
> really ship anything but HMAC-SHA-256 at present time.
Oh, I agree in general.
On Tue, Jul 21, 2009 at 07:15:02PM -0500, Nicolas Williams wrote:
> I've an application that is performance sensitive, which can re-key very
> often (say, every 15 minutes, or more often still), and where no MAC is
> accepted after 2 key changes. In one case the entity generating a MAC
> is also t
--
From: "Nicolas Williams"
Subject: Fast MAC algorithms?
Which MAC algorithms would you recommend?
I didn't see the primary requirement, you never give a speed requirement.
OMAC-AES-128 should function around 100MB/sec, HMAC-SH
I've an application that is performance sensitive, which can re-key very
often (say, every 15 minutes, or more often still), and where no MAC is
accepted after 2 key changes. In one case the entity generating a MAC
is also the only entity validating the MAC (but the MAC does go on the
wire). I'm
21 matches
Mail list logo
