Cryptography-Digest Digest #501, Volume #13 Fri, 19 Jan 01 17:13:01 EST
Contents:
Re: Any good source of cryptanalysis source code (C/C++)? (AllanW)
Re: using AES finalists in series? (Mok-Kong Shen)
Re: block algorithm on variable length without padding? ("N. Weicher")
Re: block algorithm on variable length without padding? (Gregory G Rose)
Re: 3G crypto algorithms (David B. Hoeffer)
Re: AES sbox generating code. (Benjamin Goldberg)
try this out, it looks cool ("John Wang")
Re: Crypting byte by byte (Simon Johnson)
Re: block algorithm on variable length without padding? [in the process of changing
discussions, now on difference between block and stream ciphers] ("Joseph Ashwood")
Re: AES sbox generating code. (Benjamin Goldberg)
Re: Crypting byte by byte (Benjamin Goldberg)
Re: Differential Analysis (Benjamin Goldberg)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: Kooks (was: NSA and Linux Security) (Benjamin Goldberg)
32 bit message digest ("Marcin")
Re: Comparison of ECDLP vs. DLP (Splaat23)
Re: Any good source of cryptanalysis source code (C/C++)? (Splaat23)
Re: Dynamic Transposition Revisited (long) (Benjamin Goldberg)
Re: 32 bit message digest (Benjamin Goldberg)
----------------------------------------------------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Fri, 19 Jan 2001 19:55:52 GMT
In article <947dmj$k67$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <94077c$blqps$[EMAIL PROTECTED]>,
> "Haider Ali" <[EMAIL PROTECTED]> wrote:
> > Hi.....
> >
> > I am looking for any good cryptanalytic attacks on block ciphers,
> programmed
> > in C/C++ (I need the source code).....
>
> Why? Not, "why do you need to know the attacks", but rather,
> "why do you need source code?"
>
> And you fail to specify which block cipher.
He did specify which block cipher: he used the word "any."
This also makes it fairly obvious why he wants source code:
he wants to study how it works. Hopefully this means he's more
interested in learning how to do it than he is in actually
doing it.
Throughout history great leaps in knowledge have often
followed questions such as "How does this work?"
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Fri, 19 Jan 2001 21:22:45 +0100
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >Gary Watson wrote:
[snip]
> >The topic has been discussed previously. The disadvantage
> >of not using a standard is non-conformity (conformity is
> >the very purpose of standardization).
>
> As discussed previously (see, for example:
>
> http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
>
> ), that argument is poor.
>
> Cryptography is *fundamentally* a non-conformity. We *deliberately*
> build cipher systems so that information is obscured unless both sides
> achieve agreement with the correct keys. So, while the *idea* of keys
> is a standard, having nonstandard key values is at the core of
> cryptography.
>
> How do we deal with a nonstandard? We introduce some way to define
> the unknown: Typically, we deliver keys in a secure way (e.g., a
> public key layer).
>
> But in the same way we now deliver keys, there is ample opportunity to
> describe a particular cipher, or a multiple ciphering sequence of
> ciphers. One might even deliver the actual code for a new cipher.
>
> Banks want a government-approved cipher, which they use for legal
> liability reasons. For most other cases, each individual cipher is
> what it is, and each cipher is a standard of one. There is remarkably
> little advantage, and great disadvantage, in having just a single
> cipher to use.
>
> Real security would do better with a meta-standard, negotiating cipher
> selection and multi-ciphering structure (as well as key values), in a
> way conceptually similar to modems negotiating speeds. Negotiation
> need not be real-time.
While I well recognize the advantage of availability of a
large number of good algorithms for user's choice, I believe
that one can't ignore the fact that a substantial part of
crypto users in the world would benefit from a standard like
AES. In fact, I don't see matters that inherently distinguish
a crypto standard from other standards in aspects of benefits.
> >The disadvantage
> >of using multiple encryptions (different or same algorithms
> >in series) is mainly loss of efficiency. But, for fixed
> >communication partners,
>
> Nonsense. The advantages are not limited to "fixed communication
> partners."
>
> >where conformity can be achieved
> >through appropriate arrangements and where lower efficiency
> >is acceptable, one could in my humble opinion well use
> >variants of algorithms (e.g. more rounds)
>
> It is not true that giving a cipher more rounds makes it necessarily
> stronger. For one thing, surely no cipher can be stronger than its'
> keyspace.
I was not arguing about more rounds vs. strength here,
though you might (naturally) think it that way. My point
was about 'variant' and I used 'more rounds' as an example
of a variant. On the other hand, more rounds commonly
do lead to more strength, though there is certainly a upper
limit (like one can't make a car to have infinite speed).
But using a different round number that is unknown to
the opponent does at least make his job more labourious.
> In contrast, multiple ciphering expands the keyspace, and also
> protects each individual cipher against known-plaintext attack, which
> is a very serious advantage.
Indeed true.
M. K. Shen
------------------------------
Reply-To: "N. Weicher" <[EMAIL PROTECTED]>
From: "N. Weicher" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Fri, 19 Jan 2001 20:24:28 GMT
Thanks! The light of understanding is slowing dawning <g>.
Neil
================
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:948d91$7ji$[EMAIL PROTECTED]...
> That doesn't work: You don't need to know the key to get the final partial
> block, and *neither does the attacker*. Doing:
>
> C(N) = P(N) ^ E(C(N-1))
>
> would work, but that's not what's Don's suggesting.
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: block algorithm on variable length without padding?
Date: 19 Jan 2001 12:32:40 -0800
In article <uI0FvtkgAHA.235@cpmsnbbsa07>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>There are many circumstances where stream modes of block ciphers are
>unacceptable. They offer no diffusion, the offer no protection from known
>plaintext attacking to send an incorrect message, etc. (see our common
>discussions on the problems with OTP). And you can never use a key twice.
>For some purposes they are an ideal solution. For others, particularly those
>where the need is a block cipher (aka diffusion), the stream modes are
>unacceptable.
I have to make two comments on this.
1. While bitwise stream ciphers (and block ciphers used in
a stream generation mode like OFB or counter mode)
offer no diffusion and hence allow fiddling with
messages:
a. Block ciphers also offer *only limited*
protection, and it is a mistake to think that just
because you use a block cipher that the system is
immune to such attacks
b. if you use a stream cipher with a byte- or
word-wise combination function (such as addition,
multiplication, GF(2^w) multiplication, for
example) you *do* get diffusion and some
protection against bit-flipping.
In any case, if integrity protection is a problem,
use a MAC too, and then it doesn't matter whether
you started with a stream cipher or a block
cipher.
2. "You can never use a key twice", when applied
to a block cipher in OFB or Counter mode, gives
the wrong impression. You can fix the key, but
*must* vary the initialisation vector, so that a
different output stream is generated for each
encryption. Similarly, for a stream cipher, just
fix part of the key, and vary another part; if the
cipher accepts variable length keys (eg. RC4 as
used in CipherSabre) or multi-level keying (as in
the SOBER ciphers or the GSM A5 algorithms) this
is not a problem.
When you contemplate these things, you realise
that the line between stream ciphers and block
ciphers is somewhat blurry.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
Subject: Re: 3G crypto algorithms
From: [EMAIL PROTECTED] (David B. Hoeffer)
Date: 19 Jan 2001 21:32:57 +0100
[EMAIL PROTECTED] (Janos A. Csirik) writes:
> However, the way in which these documents are made public is
> unlikely to result in immediate gratification for those who would
> just like to go in and look at the crypto algorithms.
> http://www.research.att.com/~janos/3gpp.html
Thank you very much. I have spent half an hour searching on the etsi
and 3gpp sites and than gave it up. I suspect there's some kind of
secret page telling you where to find things :)
--
David Blaustern Höffer
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AES sbox generating code.
Date: Fri, 19 Jan 2001 20:40:04 GMT
Aha! Yes, I had overlooked that. I remembered to change the line
j ^= (j << 1) ^ ((j & 0x80) ? 0x1b : 0);
to
j ^= (j << 1) ^ ((j & 0x80) ? 0x11b : 0);
But I forgot to fix the other section. Thanks!
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: "John Wang" <[EMAIL PROTECTED]>
Subject: try this out, it looks cool
Date: Fri, 19 Jan 2001 20:40:31 GMT
Hi, folks,
I just downloaded a new email encryption/decryption software called
Ensuredmail. It has plug-ins for Outlook, Outlookexpress, AOL and be-based
mails. 3DES is used. However, hex digit is not used. It works perfectly for
me.
Try it out, http://www.ensuredmail.com/download.asp?p=5
John.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Crypting byte by byte
Date: Fri, 19 Jan 2001 20:38:11 GMT
In article <949tqc$cq65q$[EMAIL PROTECTED]>,
"dexMilano" <[EMAIL PROTECTED]> wrote:
> Sorry for word game, but this can explain my need.
> I'm looking for an algorthm that can code a stream byte by byte.
> RC4 could be OK, but I'm looking some alternative.
> particularly I've the problem to keep the 2 sides syncronized.
>
> Any suggestion/reference will be welcome.
>
> dex
>
>
Seal should be good, provided you can modify it to work on 8-bit slices
(you could do this by just trucating the output). Seal is nice because
you can compute the nth pseudo-random output without generating all the
outputs before it. THis is useful in your application, you could supply
a unique packet number to each peice of data tranmitted. And encrypt
your data with the pseudo-random byte equal to the packet number. This
will solve sync problems.
Seal is also very fast, which is also nice.
Simon.
---
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding? [in the process of
changing discussions, now on difference between block and stream ciphers]
Date: Fri, 19 Jan 2001 12:48:49 -0800
"Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
news:94a898$[EMAIL PROTECTED]...
> When you contemplate these things, you realise
> that the line between stream ciphers and block
> ciphers is somewhat blurry.
Actually if you view them correctly you will see that there is a very sharp
difference between them. Any XOR based stream cipher can be very easily
viewed as an advanced chaining method for XOR. A block cipher is a finitely
sized one to one mapping between permutations. Once you view them in this
way many things start to become clear. It becomes very clear although XOR is
weak, using it with a strong chaining mode can result in something useful.
Key schedules may go the way of the Dodo, they are basically just a chaining
mode on the rounds, so it is more code efficient to use a strong chaining
mode to generate the individual block chain as well as the internal round
chain. Where PKI, hashes, MACs, etc fit in this picture I haven't figured
out yet, they may not even be in the same picture, although hashes and MACs
are evidently very closely related. This is simply a case of seperate but
equal specifically, a stream cipher can be used to build a block cipher, a
block cipher can be used to build a stream cipher. Block -> MAC, MAC->Block.
hash->MAC, MAC->hash, so all are equal, but they are more efficient at their
own purpose.
Joe
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AES sbox generating code.
Date: Fri, 19 Jan 2001 20:55:26 GMT
Ok, I now fixed that:
unsigned char AES_sbox[256], AES_sibox[256];
void AES_setup() {
unsigned char pow[256], log[256];
unsigned char i = 0, j = 1;
do { log[pow[i] = j] = i;
// The above line does pow[i] = 3**i % 0x11b
// and of course it's inverse.
j ^= (j << 1) ^ ((j & 0x80) ? 0x11b : 0);
// The above line does j = j * 3 % 0x11b
} while( ++i );
do { unsigned char k;
j = i ? pow[255 - log[i]] : 0;
// j is now 3**(-i) % 0x11b
k = ((j >> 7) | (j << 1)) ^ ((j >> 6) | (j << 2));
j ^= 0x63 ^ k ^ ((k >> 6) | (k << 2));
// j now is an affine transform of what it was.
AES_sibox[AES_sbox[i] = j] = i;
} while( ++i );
}
I'm especially proud of the do {} while(++i) construct, with i being an
8 bit value.
Doing my differential analysis on *this* sbox, results in a DP_max of
4/256, with 255 differentials with that probability.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Crypting byte by byte
Date: Fri, 19 Jan 2001 20:58:12 GMT
dexMilano wrote:
>
> Sorry for word game, but this can explain my need.
> I'm looking for an algorthm that can code a stream byte by byte.
> RC4 could be OK, but I'm looking some alternative.
> particularly I've the problem to keep the 2 sides syncronized.
There are any number of self synchronizing ciphers. Usually, one would
use CFB (Ciphertext FeedBack mode) and one's favorite block cipher.
> Any suggestion/reference will be welcome.
I would suggest AES in CFB mode.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Fri, 19 Jan 2001 21:07:02 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Tom. Your sboxgen will not generate the AES sbox. Or at least, it
> > might, but not in the lifetime of the universe.
>
> My intent was to rebut the fact that your diff code is wrong because
> you don't know what you are doing.
Except of course for the two minor facts that 1) I *do* know what I'm
doing, and 2) my diff code is correct, as you would see if you tried
implementing it.
> The AES sbox is not as good as you think it is my friend. It fails
> the SAC test has a low algebraic degree (which means the millions of
> cryptographers better then me can use it in an attack).
It doesn't really matter if the AES sbox is "as good as I think it is,"
only that I get it correct. I spent quite alot of time looking in the
wrong direction since you said my diff code was wrong (when it had been
right) and that my AES sbox gen code was right (when it was wrong).
> Sboxgen can at least make sboxes with a little more desirable
> properties.
I consider the fact that I can write a short function to generate it to
be of greater importance. Remember how, when DES came out, people
asked, where the heck do these sboxes come from? I don't want this.
Even if I say, they came from this here sboxgen program, people might be
inclined to disbelieve me, because they won't be able to produce those
exact sboxes from sboxgen, since they were, after all, randomly
produced.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Fri, 19 Jan 2001 21:09:11 GMT
In article <94a643$ro$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> > > I am looking for any good cryptanalytic attacks on block ciphers,
> > programmed
> > > in C/C++ (I need the source code).....
> >
> > Why? Not, "why do you need to know the attacks", but rather,
> > "why do you need source code?"
> >
> > And you fail to specify which block cipher.
>
> He did specify which block cipher: he used the word "any."
"I want a super-dooper secret decoder ring that works for all codes".
TANSA. Any such software would be specific to the particular cipher.
>
> This also makes it fairly obvious why he wants source code:
> he wants to study how it works.
Reading source is the worst way to learn how to do decryption.
It won't tell you what is happening and discerning the technique
used from just the source would be very difficult.
> Throughout history great leaps in knowledge have often
> followed questions such as "How does this work?"
Then that is what he should ask, rather than asking for code.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 21:23:46 GMT
tennish wrote:
And indeed, they were inexcusably sloppy in publishing it, but:
In the late eighteenth and early nineteenth centuries,
there was frequent confusion about whether proposed
amendments had become part of the Constitution. "At that time
no legal procedure existed to control the communication of
action by States to the Federal Government. . . . Uncertainty
as to the status of [TONA] continued for eight years." The
Eleventh Amendment became effective on February 7, 1795, but
was not acknowledged by President John Adams as being in
effect until January 8, 1798. Similarly, President Thomas
Jefferson's Secretary of State, James Madison, did not declare
the Twelfth Amendment in effect until more than three months
after it became part of the Constitution. Even in 1845, the
editors of United States Statutes at Large were unsure exactly
when the Eleventh and Twelfth Amendments had been ratified.
--thirdamendment.com
Greggy wrote:
[snip]
> Entire legislatures published the 13th amendment without people within
> those bodies crying foul.
>
> To assume that they were all fools is beyond any credible argument you
> can put forth, but apparently that is what you would have us believe.
Not necessarily fools, but misinformed.
> To imagine that each of these legislatures were conspiring to place
> into law an improperly ratified amendment is also incredible.
Who says that they *knew* that it was improperly ratified?
> You would have us believe that those who knew the truth intimately
> would have stood by and said nothing - and many were present when
> these votes were taking place.
How do you know that people who knew that it hadn't been properly
ratified where present when the votes were taking place?
> Their actions show us that they knew TONA was ratified and was law.
Their actions show us that they believed TONA was ratified and was law.
[snip]
> You would have us believe that those involved in publishing Virginia's
> state law books were not certain, raised no question or objections,
> and yet published anyway. A quick history lesson on who those
> publishers were would clear that up quickly, but you don't do your
> research - you just attack.
Publishers are not lawmakers. Their actions do not make laws.
> You would have us believe they knew little and were confused or
> mislead. As Richard Green shows in his essay, this is an assertion
> that defies all the knowledge we have of these men.
Perhaps they knew much, but not about the proposed 13th amendment.
No man is all knowing, or infallible. Knowledge tends to flow from few
to many. Supposing each of these legislatures gained their knowledge
from a small number of people, and that small number of people were
mistaken or misinformed, then what happened could happen.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: "Marcin" <[EMAIL PROTECTED]>
Subject: 32 bit message digest
Date: Fri, 19 Jan 2001 16:27:18 -0800
Hello,
I'm trying to settle on a good way of obtaining 32 bytes of entropy from a
rather short phrase that could be used as a symetric key to a block cipher.
My current solution is to take the first half of the source bytes and
produce an MD5 digest and take the other half and produce the latter 16
bytes, then concatenate it into 32 byte word. Does that seem like a good
solution? Any comments or suggestions?
Thanks,
Marcin.
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Fri, 19 Jan 2001 21:34:03 GMT
True. Modulus n being prime is obviously a trivial technique because
anyone could check this from the public key. However, what would an
effective technique be? One example would be all I need to drop RSA in
most situations where users are expected to generate their own keys.
It's kind of a shocker that I haven't encountered any papers on this
potentially large hole in RSA security (probably popular support has
suppressed them). I can't imagine that it's very easy to generate a key
that looks good but is not, but I'm now very curious as to how this
attack could be pulled off in the real world.
Also, do you have any references to RSA PKV verification protocols?
- Andrew
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Splaat23 wrote that he thought that a well-designed RSA ownership
test would be
> sufficient.
>
> This is obviously not true when considering an active adversary.
Just make up
> an key that looks like an RSA key but is easy to invert, in the toy
example,
> let the modulus n be prime. Any test can be done by the owner, as he
can
> certainly invert it, but anyone else can also invert this key.
>
> My beliefs are that POP and PKV are best thought of as indenpendent
and
> complementary. Both are useful. But the fact that some POP test
MIGHT give
> some PKV fuzzies is not enough. If you want PKV, you should really
try to do
> PKV, that is, check the components for arithmetic validity.
>
> Both POP and PKV are tools, both are valid and useful. For DL/ECC
POP and PKV
> separate cleanly, for RSA, perhaps it is not as clean to separate
them, I am
> not sure what this means, except that the RSA sandbox (group info)
must remain
> a secret while for DL/ECC it is public. I do agree that RSA POP does
provide
> SOME assurance of RSA PKV, just that it is partial.
> Don Johnson
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Fri, 19 Jan 2001 21:41:18 GMT
If he really was interested in the mechanics of the attacks, he would
not have asked for the code but for an explanation of the attack. Note,
he didn't ask for "good cryptanalytic attacks on any block cipher",
but "any good cryptanalytic attacks on block ciphers". This, with
request for code, really points to a script-kiddie looking to crack
something he found and has no idea what it is. Pretty sad if you ask me.
- Andrew
In article <94a643$ro$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> In article <947dmj$k67$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <94077c$blqps$[EMAIL PROTECTED]>,
> > "Haider Ali" <[EMAIL PROTECTED]> wrote:
> > > Hi.....
> > >
> > > I am looking for any good cryptanalytic attacks on block ciphers,
> > programmed
> > > in C/C++ (I need the source code).....
> >
> > Why? Not, "why do you need to know the attacks", but rather,
> > "why do you need source code?"
> >
> > And you fail to specify which block cipher.
>
> He did specify which block cipher: he used the word "any."
>
> This also makes it fairly obvious why he wants source code:
> he wants to study how it works. Hopefully this means he's more
> interested in learning how to do it than he is in actually
> doing it.
>
> Throughout history great leaps in knowledge have often
> followed questions such as "How does this work?"
>
> --
> [EMAIL PROTECTED] is a "Spam Magnet," never read.
> Please reply in newsgroups only, sorry.
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 19 Jan 2001 21:53:33 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > John A. Malley wrote:
>
> > > May I paraphrase the description of block balancing to make sure I
> > > understand the mechanism as envisioned? And please, correct me if
> > > I got this wrong.
> > >
> > > Given plaintext P,
> > >
> > > 1) divvy P into bytes as P[1], P[2], P[3] ... P[n],
> > >
> > > 2) build up (one at a time) blocks of size k bytes, B[1], B[2],
> > > B[3] ... B[m] where m < n, and sequential plaintext bytes are
> > > assigned to a given block B[i] where B[i] is the concatenation of
> > > a few plaintext bytes, followed by a special byte that has 0s and
> > > 1s in it, followed by bytes of all zeros or all ones - like
> > >
> > > P[1] | P[2] | ... | P[L] | a block of 1s and 0s | 00000000 |
> > > 11111111 | ... 00000000 = B[i]
> > >
> > > or
> > >
> > > P[1] | P[2] | ... | P[L] | a block of 1s and 0s | "0" | "255" |
> > > ... "0" = B[i]
> > >
> > > Is this an accurate description of the proposed bit balancing?
> >
> > Almost. It's more like
> > if( P[1..L] has more 0s than 1s ) {
> > P[1] | P[2] | ... | P[L] | XXXXXXX | 00000000 | 00000000 = B[i]
> > Where XXXXXXXX is some number of 1s and 0s.
> > } else {
> > P[1] | P[2] | ... | P[L] | XXXXXXX | 11111111 | 11111111 = B[i]
> > Where XXXXXXXX is some number of 0s and 1s.
> > }
> [snip]
>
> I am certainly confused. What if, say, the block size is
> 4 bytes and one has (1) two bytes and (2) three bytes of
> information which are all 0's? Thanks.
A 4 byte block is really small. If you have two bytes of 0x00s, then
one byte goes into the first block, one balance byte 0x00 is added, and
two balance bytes 0xFFFF are added. The next 0x00 byte goes into the
next block. With 3 0x00s it's similar.
A 5 byte block is better. Two 0x00 bytes go in, then a 0x0F byte, then
0xFFFF. With three 0x00s, two bytes go into the first block, then one
into the next.
Fortuneatly, we won't be likely to be using 4 byte blocks, but much
larger, perhaps 15 or 16 bytes.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: 32 bit message digest
Date: Fri, 19 Jan 2001 22:05:49 GMT
Marcin wrote:
>
> Hello,
>
> I'm trying to settle on a good way of obtaining 32 bytes of entropy
> from a rather short phrase that could be used as a symetric key to a
> block cipher.
> My current solution is to take the first half of the source bytes and
> produce an MD5 digest and take the other half and produce the latter
> 16 bytes, then concatenate it into 32 byte word. Does that seem like
> a good solution? Any comments or suggestions?
No, it doesn't seem like a good solution, because an attacker can
seperately attack the left half and the right half.
I would suggest using SHA256. That's what it's for, after all.
If all you have available is a 128 bit hash, then I would suggest
something like the following:
H = the hash
S = the string.
|| means concatenate.
Use as your hash H( S ) || H( S || S ). Or H(S) || H( "X" || S ).
Regardless, don't divide your string, since that will weaken the output.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
