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
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 Ceasar.
--
From: James A. Donald jam...@echeque.com
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 tricky
--
From: Ray Dillinger b...@sonic.net
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
--
From: James A. Donald jam...@echeque.com
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
From: Nicolas Williams nicolas.willi...@sun.com
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
On Jul 27, 2009, at 4:50 AM, James A. Donald wrote:
From: Nicolas Williams nicolas.willi...@sun.com
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
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 in a
[I realise this isn't crypto, but it's arguably security-relevant and arguably
interesting :-)].
James Hughes hugh...@mac.com 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
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
--
From: Nicolas Williams nicolas.willi...@sun.com
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
mhey...@gmail.com 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
On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote:
mhey...@gmail.com 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 Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
mhey...@gmail.com 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
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:
--
From: Nicolas Williams nicolas.willi...@sun.com
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
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 the
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. As
On Wed, Jul 22, 2009 at 1:43 AM, Nicolas
Williamsnicolas.willi...@sun.com 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
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
20 matches
Mail list logo
