Re: Cohen's paper on byte order
From: Eugene Starokoltsev (eugene_o@gmx.net)
Date: 04/10/03
- Next message: Jon Sturgeon: "Re: Good books?"
- Previous message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
- Next in thread: Bryan Olson: "Re: Cohen's paper on byte order"
- Reply: Bryan Olson: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: eugene_o@gmx.net (Eugene Starokoltsev) Date: 10 Apr 2003 11:06:31 -0700
Bryan Olson <fakeaddress@nowhere.org> wrote in message news:<Oiala.529$5s3.29351061@newssvr21.news.prodigy.com>...
> > Could you please give an example of an octet-level protocol
> > specification without cryptographical functionality you consider?
>
> TCP. Then SSL builds an authenticated and optionally encrypted
> octet stream on top of reliable octet stream transport.
Unfortunately RFCs I saw do have a clear bug: they rely on MSB-first
mapping of bytes into bit strings for cryptographical functions
without specifying this mapping directly. There is no difference, they
use AES, MD5 or SHA-1. As I said already IETF should correct them.
> > think you suggest a way to add AES to it using FIPS-197 only without
> > writing additional specifications, don't you? I would like to see how
> > adding of just octets-to-bit mapping into FIPS-197 will help you to
> > achieve your goal.
> >
> > BTW SP-800-38A is such an extra specification.
>
> I don't think it is. I do not see where SP-800-38A tells how to
> map octets to bits. It still leaves us one specification short
> of knowing how to encrypt the octet data that the vast majority
> of protocols use.
A say that it is an example of _extra_ specification which you need to
use to encrypt a big stream of data. It does not specify bit order, it
is out of scope of it. You argued against extra specifications. But if
you specify bit order but do not specify mode of operation you can't
use AES still. So you need extra specifications in any case.
> >> > I suspect some standard exists
> >> > already but we do not know it. It is not AES-specific problem.
> >>
> >>It's been a problem with some of the NIST algorithms. It's not
> >>a problem with most crypto standards, because most are defined
> >>on octets.
> >
> >
> > Could you please give an examples of such FIPS?
>
> FIPS 46.
If we speak about the same, i. e. DES (I have FIPS 46-3) than NO. DES
is defined on bit streams. "The algorithm is designed to encipher and
decipher blocks of data consisting of 64 bits under control of a
64-bit key1. 1) Blocks are composed of bits numbered from left to
right, i.e., the left most bit of a block is bit one."
> >> > And
> >> > FIPS-197 is not the place to add such specification because modes of
> >> > operation are specified in terms of bit streams.
> >>
> >>The first AES modes-of-operation document has no problem
> >>specifying in terms of both bit-strings and integers. See NIST
> >>SP 800-38A. Incidentally, it says the high order bits are ones
> >>on the left.
> >
> > I read it. It defines "Block" as just "A sequence of bits whose length
> > is the block size of the block cipher." And later (5.2): "For all of
> > the modes in this recommendation, the plaintext must be represented as
> > a sequence of
> > bit strings; the requirements on the lengths of the bit strings vary
> > according to the mode ... The formatting of the plaintext, including
> > in some cases the appending of padding bits to form complete data
> > blocks or data segments, is outside the scope of this recommendation."
>
> And it defines the high-order bits as the leftmost bits, giving
> a well-defined mapping to integers. It does not, strictly
> speaking, tell how to encrypt octet strings.
It just defines mapping of integers into bit strings for internal
usage - to specify standard integer counter mapping for CTR mode of
operation. It does not define mapping of integers for plaintext (as
"the formatting of the plaintext ... is outside the scope of this
recommendation") nor requires any specific mapping even for integer
counters for CTR mode of operation.
- Next message: Jon Sturgeon: "Re: Good books?"
- Previous message: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- In reply to: Bryan Olson: "Re: Cohen's paper on byte order"
- Next in thread: Bryan Olson: "Re: Cohen's paper on byte order"
- Reply: Bryan Olson: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
