linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tan Swee Heng" <thesweeheng@gmail.com>
To: "Sebastian Siewior" <linux-crypto@ml.breakpoint.cc>,
	"Tan Swee Heng" <thesweeheng@gmail.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Linux Crypto" <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 2/2] salsa20_i586: Salsa20 stream cipher algorithm (i586 version)
Date: Sun, 9 Dec 2007 02:13:40 +0800	[thread overview]
Message-ID: <fd3e431c0712081013n731447bap600c2157fd036cb6@mail.gmail.com> (raw)
In-Reply-To: <20071207184432.GE24292@Chamillionaire.breakpoint.cc>

Hi Sebastian,

On Dec 8, 2007 2:44 AM, Sebastian Siewior <linux-crypto@ml.breakpoint.cc> wrote:
> >The keysetup() should be the same as the C version... except that I've
> >previously modified the C version to use key length in bytes while the
> >assembly version uses bits! :-) I could change the C code back. But I
> >personally prefer to use the assembly version since it was distributed
> >as a "self-contained and complete solution" in Bernstein's
> >"salsa20.s".
> I would go for the smaller files. That's why merged the AES code
> earlier.
I've seen your good work with the AES code. But I will stick with the
assembly version for the time being... at least until I've done the
Salsa x86-64 version and perhaps a few more eSTREAM ciphers.

> I would not mind modifing the source code for the greated good :) Should
> you make a mistake than the test vectors should detect them.
Test vectors are great for catching general bugs (wrong S-box entry,
wrong transformation, etc) but they can be weak at boundary conditions
(an extra byte mistakenly written at the end of the output buffer) and
against malicious intent (malicious code added without breaking
crypto). Since I don't expect people to trust a newbie like me, I'd
rather stick to not modifying the original assembly code too much. :-)

> After all, you modified the C version and s/keysize/bits.
With hindsight, I wish I had not modified the keysize bits in the C
version. It was the source of a bug while I was writing up the i586
patch (I forgot to multiply keylen by 8). So I may revert them
eventually to make them consistent with the assembly version. :-)

Swee Heng

  reply	other threads:[~2007-12-08 18:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-05 20:31 [PATCH 2/2] salsa20_i586: Salsa20 stream cipher algorithm (i586 version) Tan Swee Heng
2007-12-05 21:49 ` Sebastian Siewior
2007-12-05 23:51   ` Herbert Xu
2007-12-07 17:02   ` Tan Swee Heng
2007-12-07 18:44     ` Sebastian Siewior
2007-12-08 18:13       ` Tan Swee Heng [this message]
2007-12-07  9:22 ` Herbert Xu
2007-12-08  3:21   ` Tan Swee Heng
2007-12-08  3:30     ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd3e431c0712081013n731447bap600c2157fd036cb6@mail.gmail.com \
    --to=thesweeheng@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@ml.breakpoint.cc \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).