Cryptography-Digest Digest #165, Volume #14 Tue, 17 Apr 01 04:13:01 EDT
Contents:
Re: Incomplete Blocks in Twofish (Paul Rubin)
Re: Incomplete Blocks in Twofish ("Scott Fluhrer")
Publishing is *hard* ("John A. Malley")
Re: HOW THE HELL DO I FIND "D"?!?! ("Joseph Ashwood")
Re: Reusing A One Time Pad ("Joseph Ashwood")
Re: Incomplete Blocks in Twofish ("Tom St Denis")
Re: AES poll (SCOTT19U.ZIP_GUY)
Re: patent issue (Paul Crowley)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Distinguisher for RC4 ([EMAIL PROTECTED])
Re: Incomplete Blocks in Twofish (Eric Lee Green)
Re: Reusing A One Time Pad ("Douglas A. Gwyn")
Re: MS OSs "swap" file: total breach of computer security. (wtshaw)
Re: There Is No Unbreakable Crypto (Mok-Kong Shen)
Re: Note on combining PRNGs with the method of Wichmann and Hill ("Bryan Olson")
Re: Note on combining PRNGs with the method of Wichmann and Hill ("Bryan Olson")
----------------------------------------------------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Incomplete Blocks in Twofish
Date: 16 Apr 2001 21:22:39 -0700
"Mike Moulton" <[EMAIL PROTECTED]> writes:
> I've been in the process of testing and modifying the reference
> implementation of Twofish to meet my needs, and I'm wondering what is the
> process of encrypting incomplete blocks. What technique should I use
> considering that I am going to be running it in ECB for Encryption and CBC
> as a MAC? Should I pad the ECB encryption like MD4/MD5 with a string of
> zero's and a the length of the padding, or use ciphertext-stealing? After
> having read through Stinson/HAC/Schneier and the Twofish Book/Paper the only
> one to even mention it was Applied Cryptgraphy by Schneier. Perhaps there
> was a mention somewhere else about an *official* way to implement padding in
> Twofish. If so I'd be grateful for the reference.
The closest thing to a standard I know of for this is PKCS5.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Incomplete Blocks in Twofish
Date: Mon, 16 Apr 2001 21:20:17 -0700
Mike Moulton <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've been in the process of testing and modifying the reference
> implementation of Twofish to meet my needs, and I'm wondering what is the
> process of encrypting incomplete blocks. What technique should I use
> considering that I am going to be running it in ECB for Encryption and CBC
> as a MAC? Should I pad the ECB encryption like MD4/MD5 with a string of
> zero's and a the length of the padding, or use ciphertext-stealing? After
> having read through Stinson/HAC/Schneier and the Twofish Book/Paper the
only
> one to even mention it was Applied Cryptgraphy by Schneier. Perhaps there
> was a mention somewhere else about an *official* way to implement padding
in
> Twofish. If so I'd be grateful for the reference.
Well, padding is not particularly Twofish specific -- any block cipher has
to deal with it. There's several generic ways to handle it, none of which
is the "official" way (whatever that means):
- Add an explicit length field at the beginning. Pad the last block out any
way that's convienent.
- Put the pad length as the last byte of the last block. This implies that
you always have at least one byte of padding
- Ciphertext stealing
- Use a mode that handles arbitrary message lengths, such as CFB, OFB or
counter mode.
BTW: why are you using ECB for encryption? Unless you know a priori that
duplicate plaintext blocks are unlikely, that's insecure.
--
poncho
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Publishing is *hard*
Date: Mon, 16 Apr 2001 21:52:31 -0700
Well the *bad* news is my first attempt to publish the results of some
amateur research ended up rejected. :-(
(I put up a URL to a draft of the paper last year here in the group -
http://www.homeworlds.com/papers/SECLCG.pdf )
The *good* news is I gained better understanding of the referee process.
:- )
I got some insightful and helpful comments from an anonymous referee. I
don't agree with everything he wrote, BUT, I do now understand the
standards to which work will be held, I appreciate the advice, critique
and pointers and I'll take it to heart.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: HOW THE HELL DO I FIND "D"?!?!
Date: Mon, 16 Apr 2001 21:29:06 -0700
Finding D you use the extended Euclidian Algorithm (documented several
places)
For encrypting values you take some representation of it (ASCII is fine) to
build a very large number, then you take the first n-1 bits of it (where n
is the size of your RSA modulus) (you could also use n-8 bits if it's more
convenient) and encrypt. On decryption you know how many top bits were not
original data and so can remove them before displaying.
Joe
"Dopefish" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]...
> i have been reading "The Mathematics of RSA"
> (http://dslab.csie.ncu.edu.tw/~lucas/rsamath.HTM) and after working out
all
> of the stuff, i can figure out how to encrypt a message (which is
extremely
> easy, "c=m^e mod n") but i cannot find how to get d (the decryption key)
> that would give you "m=c^d mod n." I am using a TI-89 calculator to work
> out this stuff and i am intending to write a program for it. also, how
> would i go about encrypting a string of letters? would i have to take the
> ASCII code for each letter, encrypt it,then display the letter that
> corrisponds to the encrypted ASCII code, or is there an easier way to do
> this?
>
>
> thanks, james
>
>
>
> --
> ------BEGIN SIGNATURE------
> A.K.A "Dopefish" or "fish" for short on Usenet.
>
> Microsoft? Is that some kind of toilet paper?
>
> "Rockin' the town like a moldy crouton!"
> - Beck (Soul Suckin' Jerk - Reject)
>
> "Help me, I broke apart my insides. Help me,
> I've got no soul to sell. Help me, the only thing
> that works for me, help me get away from
> myself."
> - Nine Inch Nails (Closer)
>
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GO dpu s++:++ a---- C++++ U--->UL
> P L+ E? W++ N+++ o+ K--- w+>w+++++
> O--- M-- V? PS+++ PE Y-- PGP t 5--
> X+ R tv b+ DI D+ G-- e- h! r z
> ------END GEEK CODE BLOCK------
> (www.geekcode.com)
>
> ------END SIGNATURE------
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Mon, 16 Apr 2001 21:28:35 -0700
The moment you reuse *any* portion of the pad, the security immediately
falls to precisely 0. That's a simple fact of life (assuming you are using a
standard XOR based pad). There is no getting around that, no amount of
postulating will get around the mathematic problems involved, your idea is
plain and simply insecure.
Joe
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bg80j$2oua$[EMAIL PROTECTED]...
> > However I can tell you that you can do something akin to this. Simply
keep
> a
> > pointer to the next unused bit in the large pad. It becomes a OTP as
> > commonly envisioned. If you do not do this and instead choose a random
> > location in the large randblock at random you will very quickly reduce
> your
> > security to 0. In particular once you reach sqrt(length randblock) bits
> > encrypted there is already a 50% likelihood that an attacker can read at
> > least one bit.
>
> Well if I wasn't going to reuse the pad that's obviously what I'd do
but...
> if I intend on reusing the pad I wouldn't want to do it in a predictable
> way.
>
> And one bit dose not a useful message make. Nor two, or three...
>
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Incomplete Blocks in Twofish
Date: Tue, 17 Apr 2001 05:02:27 GMT
"Mike Moulton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've been in the process of testing and modifying the reference
> implementation of Twofish to meet my needs, and I'm wondering what is the
> process of encrypting incomplete blocks. What technique should I use
> considering that I am going to be running it in ECB for Encryption and CBC
> as a MAC? Should I pad the ECB encryption like MD4/MD5 with a string of
> zero's and a the length of the padding, or use ciphertext-stealing? After
> having read through Stinson/HAC/Schneier and the Twofish Book/Paper the
only
> one to even mention it was Applied Cryptgraphy by Schneier. Perhaps there
> was a mention somewhere else about an *official* way to implement padding
in
> Twofish. If so I'd be grateful for the reference.
Typically in CBC mode you encrypt the last IV again and xor the bits
required against the remainder of the plaintext/ciphertext.
The way you handle it is really independent of the block cipher you use.
A better method if you're allowed is to use a counter mode where you encrypt
a binary counter. That way you can encrypt/decrypt arbitrary sized messages
using only the [twofish] encrypt routine.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES poll
Date: 17 Apr 2001 00:18:10 GMT
[EMAIL PROTECTED] (Eric Lee Green) wrote in
<[EMAIL PROTECTED]>:
>On Mon, 16 Apr 2001 23:15:47 +0200, Jack Lindso <[EMAIL PROTECTED]>
>wrote:
>>From reading the government document concerning the choice of AES I had
>>the feeling that Rijindael was selected without evident/sufficient
>>proof for being the best choice.
>
>"Best" defined how?
>
>The government document is pretty clear that they chose Rijndael because
>it was the fastest. That's how they defined "best". If you disagree, use
>Twofish. Nobody's forcing you to use Rijndael.
>
Actaully having worked for Uncle for 26 years. The word "best" means
whatever the goverenmenf feels it means. My own pesonnel belief is that
best means the public doesn't know how to break it but the NSA does.
Speed of a method gives a upper limit on how secure it really is.
Since its the fastest. Its most likely the easiest of the group of
finailist methods that it can break. In reallity I would farther guess
that any finialist AES candidate can be broken by the NSA.
That said. I don't think they can fully break all implimentations
of the method. That is why deliberate weaknesses are in things like
PGP. Such as the nonbijective compression and the quick key check all
these features greatly weaken such encryption when subject to a
cipher text only mode of attack. If you want to use the AES method
the best choice at this time is Matts version which does a bijective
PPM compression as a first pass. This makes a cipher text only mode
much harder to break. I think its even possible they don't yet
have a break for this kind of combo method.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
Subject: Re: patent issue
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 17 Apr 2001 05:32:21 GMT
[EMAIL PROTECTED] (Terry Ritter) writes:
> Oh, please. When did any patent prevent you from exploring new
> ground?
Well, I won't devote time to fixing the cipher I attacked at FSE
because it is patented, despite the fact that such a cipher would be
useful. There's one example.
> In fact you have some nerve: the US patent does not apply to
> you anyway.
However, it's still the case that ciphers patented in the US should
not appear in standards, so the constraint is effectively worldwide.
> It sounds to me like you can't bear the thought that any research you
> do might benefit someone with a patent. So your "exploration" is not
> really to seek knowledge, nor is it to benefit society, but instead is
> to benefit you personally in the way you want. That's childish even
> beyond the obvious "sour grapes" involved.
I have no idea why you would prefer this explanation of my beliefs
over the one I gave.
> Dynamic Substitution has already been essentially free for the past
> decade. Over half the patent lifetime has passed, so there has been
> ample opportunity to inquire, experiment and develop, an opportunity
> which was generally ignored. It may be that enforcement would do more
> for Dynamic Substitution technology than anything academia has done
> over a decade.
Perhaps when the expiration deadline is very close I'll start to take
an interest in this technology.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 01:03:23 -0500
I don't wish to seem rude and will admit that I'm not the smartest person in
the world, but you know what I would find extremely helpful in life... an
automatic intelligence rating, for lack of a better term, with regards to a
topic when I'm talking to someone trying to learn something. I'm sure we've
all been there, you listen intently thinking that maybe your just not
understanding something profound, only to realize you've been wasting your
time.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Distinguisher for RC4
Date: 16 Apr 2001 23:19:15 -0700
"Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> Yes, I just tried it on 256,000 keys, and I saw a zero as the second byte
> 1926 times.
Interesting. I used an RC4 command-line utility I had lying around
and gave it 32 bit keys from /dev/urandom. With this, after 22210
iterations I saw 83 with the 2nd byte being zero, compared to an
expected 86.75 if an even distribution, or 173.5 if biased in this
way.
Can you modify your test to try 32 bit keys? Maybe there is something
about them that keeps S[2] from being 0 after key setup.
> Here's why it works: suppose, immediately after key setup, S[2]==0. Then,
> if S[1]=X, then the first iteration sets j to X. Then, on the second
> iteration, i is set to 2, j remains X (because S[i]=0), S[i] and S[j] are
> swapped (which sets S[j] to 0 and S[i] to X), and then S[S[i]+S[j]] = S[X +
> 0] = 0 is output. Actually, there are a few values of X where this won't
> work, but usually it does. This happens about 1/256 of time.
>
> Then, if S[2]!=0, then RC4 acts essentially randomly, and outputs 1/256 of
> the time.
>
> Hence, the probability of a zero output is about 1/256+1/256 = 1/128
Thanks, that makes sense. If S[1] is 0 then by a similar argument you
can't get a zero output on the 2nd byte, but this only decreases the
probability by about 1/256*256, so it is not noticeable.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Incomplete Blocks in Twofish
Reply-To: [EMAIL PROTECTED]
Date: 17 Apr 2001 01:21:31 -0500
On Mon, 16 Apr 2001 23:32:39 -0400, Mike Moulton <[EMAIL PROTECTED]> wrote:
>I've been in the process of testing and modifying the reference
>implementation of Twofish to meet my needs, and I'm wondering what is the
>process of encrypting incomplete blocks. What technique should I use
>considering that I am going to be running it in ECB for Encryption and CBC
>as a MAC? Should I pad the ECB encryption like MD4/MD5 with a string of
Uhm, don't use ECB? (CBC maybe, but ECB is Evil). I can't think of an
implementation where you can use ECB but not CBC. Even hard drive encryption
usually has a unique "salt" you can use for each block on disk without
the problem of expanding the text (usually the block address). Of course,
even with CBC you end up with the problem of padding blocks. See below.
>was a mention somewhere else about an *official* way to implement padding in
>Twofish. If so I'd be grateful for the reference.
I would suggest simply padding the last block out with random numbers,
then packetizing your block stream. Or use a streaming mode like CFB-128.
CBC is an excellent way to handle block-oriented data, but there are
easier ways to handle streaming data. Although I must admit that I don't
trust CFB as much as I do CBC, due to the whole "one time salt" issue
(where if the salt is reused, it's the same as re-using a one time pad).
--
Eric Lee Green http://www.badtux.org mailto:[EMAIL PROTECTED]
Phoenix Branch -- Eric Conspiracy Secret Labs
Cruisin' the USENET since 1985
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 06:48:12 GMT
Joseph Ashwood wrote:
> The moment you reuse *any* portion of the pad, the security
> immediately falls to precisely 0. That's a simple fact of life
I'm curious how you're measuring "security".
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Tue, 17 Apr 2001 00:24:55 -0600
In article <_XIC6.22803$[EMAIL PROTECTED]>, "Tom St
Denis" <[EMAIL PROTECTED]> wrote:
> "wtshaw" <[EMAIL PROTECTED]> wrote in message
> > It does not follow that if a better choice is available why one would seek
> > a ride in a leaky boat with only a slight hole in it. I doubt you
> > understand what you advocate nor the limitations of trying to fully
> > control the effects of a black box.
>
> Now repeat your reply in English please.
>
> Tom
The basic problem like Jessica Rabbit is that security need not be bad, it
is just drawn that way. It is not for want of the knowledge of how yo do
things correctly, just that the prospective has been that insecurity is
better for national security and discouraging autonomous systems.
The fly in the ointment as far as the power mongers is that different
teams did not always agree and some designs have turned out to be much
more secure than others.
Fortunately for them, hype has sold the worse plans to almost everyone.
People worship quantity over quality. To protect the beast, the code has
been obscure. Tools have been designed with certain peculiar limitations
to keep accessory products insecure and under central control. External
improvements suffer under a poor architecture and a swamp of system code
to try to figure out. This was all shortsighted because covert faults
that were touted as good are showing as its Mr. Hyde side.
--
Ah, so! Chop suey on a bagel. Now...say, "So Sorry."
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto
Date: Tue, 17 Apr 2001 09:57:22 +0200
David Wagner wrote:
>
> Henrick Hellström wrote:
> >I rather had some doubts about the proposal to extend the function to
> >generate even longer PRG outputs, e.g. G'(k) = G(k1)|G(k2) where k1|k2 =
> >G(k). I don't find it obvious that [...]
>
> I never said it was obvious. It's a pretty marvelous result, in fact,
> and it is the meat of the theorem. But while you're reading the proof
> of it, you can see my other post for some partial intuition.
>
> Note that to prove this, you don't need to know anything about the
> structure of G (for instance, you can forget about the fact that it's
> constructed using E). The above fact is true in general of all PRG's.
>
I continue to think, as said in another post, that this
means one can generate from, say, 128 random bits, a
secure bit string of infinite length, which seems to
be very counter-intuitive. Could you please say something
to that? Thanks.
M. K. Shen
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 17 Apr 2001 08:03:09 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen wrote:
>
>
>Bryan Olson wrote:
>>
>> Mok-Kong Shen wrote:
>> >
>> > The method of Wichmann and Hill (Appl. Statist. 31 (1982))
>> > for combining n arbitrary PRNGs with output in [0, 1) consists
>> > in forming their sum mod 1. For crypto purposes, one could
>> > introduce some 'variability' by employing a weighted sum
>> > instead, thus rendering the analysis more difficult. We could,
>> > for example, choose cofficients in some range (1.0-delta,
>> > 1.0+delta) to multiply the PRNG outputs before summing mod 1.
>>
>> This note includes no justification for "thus rendering the
>> analysis more difficult".
>>
>> The modification destroys an important property of the basic
>> combination method: as long as the streams are independent,
>> if any of the streams are uniform then the sum is uniform.
>
>It is a heuristic method, not of the sort accessible
>(not intended for) rigorous proofs. Theorecital minded
>and perfectionists should definitely and immediately leave
>their fingers off my scheme.
You present no justification at all. Neither theory nor
empirical study supports the assertion. The modification
loses a good quality, and nothing desirable is established.
>Havisng weights well distributed in an interval as I
>mentioned tends to do something against what you said last.
What I had written last is simply true.
>Again, this is rough, ad hoc, approximate, quick-and-dirty
>and what not, i.e. very very non-perfect.
I've never understood low quality as a goal.
--Bryan
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 17 Apr 2001 08:04:01 GMT
Mok-Kong Shen wrote:
>I like to add something to make my last paragraph better
>understandable: If one of the streams gets a factor 1.0
>(and it is uniform), isn't that everything is again
>(rigorously) theoretically o.k. in that particular issue?
Of course not. The theorem was:
| as long as the streams are independent, if any of the
| streams are uniform then the sum is uniform.
--Bryan
------------------------------
** 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
******************************
