Cryptography-Digest Digest #101, Volume #10 Tue, 24 Aug 99 01:13:03 EDT
Contents:
Re: How Easy Can Terrorists Get Strong Encrypt? (SCOTT19U.ZIP_GUY)
The Reversal of NetNanny ([EMAIL PROTECTED])
Re: truly anonymous membership proof ([EMAIL PROTECTED])
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
One-time pad encryption. (Tony L. Svanstrom)
Re: The Reversal of NetNanny (Keith A Monahan)
Re: How Easy Can Terrorists Get Strong Encrypt? (Tom St Denis)
crypto RNG and permutations (Tom St Denis)
Re: Vigenere/Kasisky problem (JTong1995)
Re: Vigenere Variant Problem (John Savard)
Re: Entropy in "modified" passwords (Wim Lewis)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Tue, 24 Aug 1999 03:50:47 GMT
In article <7pslek$t0g$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>In case anyone is interested, this came from WND...
>
>Indeed, a recent study by the George Washington University School of
>Engineering and Applied Science backs up Goodlatte. It found good
>encryption programs available outside the United States on more than
>800 Websites.
>
Who says they are getting good crypto. They most likely have people
with no mathematical background like Hamilton picking software for them
or they use the pusedo secure stuff like DES or AES.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: The Reversal of NetNanny
Date: Tue, 24 Aug 1999 02:06:24 GMT
Hello.
While this is not science, and while the application targeted isn't an
encryption-product per se, I thought this essay might interest some of the
readers of this group.
The essay is called _The Reversal of NetNanny_ and you'll find it at
http://hem2.passagen.se/eddy1/reveng/nn/
In it we describe how we 'reverse engineer' this program, a process which
involves some very simple and extremely basic cryptanalysis (if it may so be
called).
Feedback appreciated.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: truly anonymous membership proof
Date: Tue, 24 Aug 1999 03:23:43 GMT
Here's my solution. I posted it before, but I think that it may not have
made it. It relies on people keeping their private key secret.
As an example, i will assume that a government wants to be able to
regularly check whether people are citizens, but the people don't want
to have to reveal who they are all the time. The govt issues
certificates to the people, based on their public key, such that one
needs the private key to use the certificate.
Specific protocol:
N: Large public prime modulus, where N=2M+1, with M prime. So
phi(N)=N-1, phi(N-1)=M-1, the largest possible value of phi(phi(N)). All
arithmetic mod N unless otherwise stated.
s, s': state secret keys, such that a^(s*s')=a (mod N-1) for all a (can
be calculated, as everyone knows phi(N-1) ) x: secret number, only known
to state.
p: personal, private key.
a: random number, chosen by state at time of issuing certificate
b, c: random numbers chosen by individual at time of verification.
d: as above, but by the state.
y: publically known constant, relatively prime to N-1.
z=y^s (mod N-1), z is also publically known.
e=y^b (mod N-1)
f=cdx.
Capital letters denote 2^[lowercase letter], eg P=2^p, the person's
public key, except:
I: individual
G: Government
Initial authorisation:
G chooses a (must be relatively prime to N-1)
G computes: (2^(1+xp))^a, (from knowing P, I's public key.).
G->I: (2^(1+xp))^a, and
a^s (mod N-1).
Verification:
I chooses b,c.
I computes: y^b=e (mod N-1)
z^b=e^s (mod N-1).
(2^(1+xp))^aec
(a^s)*(e^s)=(ae)^s (mod N-1)
2^c=C
I->G: (ae)^s, (2^(1+xp))^aec, C.
G chooses d.
G computes: (ae)^(ss')=ae (mod N-1)
1/(ae) (mod N-1) (ie works out how to take (ae)th
roots).
(2^(1+xp))^c=C^(1+xp)
C^xp
C^xpd=F^p
C^xd=F
Now they engage in two ZK proofs of discrete logs: firstly G proves
knowledge of log_C F (thereby essentially proving that G does not know
log_2 F), and then I proves knowledge of log_F (F^p) = p. At this point
G knows that I knows the private key of a citizen, and as such is a
citizen. Assuming that discrete logs are intractible G cannot work out
who I is, or even check a suspicion. I also believe that people cannot
forge certificates, even if they betray their private keys, but i can't
be sure.
Anyone feel like checking it out?
Thanks
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 24 Aug 1999 03:48:06 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>> >SCOTT19U.ZIP_GUY wrote:
>> >>
>> >> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
>> > <[EMAIL PROTECTED]> wrote:
>> >>
>> >> >
>> >> >To be exact, you can't say how many input symbols are obtained from
>> >> >the x's. For instance, it could be that there are Huffman codes
>> >> >that occupies only 3 x positions. All one knows (by our assumption)
>> >> >is that the last 9 bits of the original output file constitute one
>> >> >single Huffman code and therefore these 9 bits will be decompressed
>> >> >to one input character (which, if it is 8 bit ASCII, occupies a byte).
>> >> >But this fact is unimportant for the present discussion.
>> >> What are you thinking I thought the x's where a single token.
>> >> Look it is obvious you are lost and don't know what I mean. PLEASE
>> >> ASK SOMEONE ELSE FOR HELP.
>> >
>> >Eh?? What was wrong?? There were 7 x's, each being a bit position,
>> >so it could well be that 3 of the bits consitute one Huffman code.
>> >That each x represent a bit in the output file (compressed file)
>> >should have been entirely clear to you in all the discussions up
>> >till now!!!!!
>> Get real the 7 x's where only one token. Your are the one who just
>> said maybe 3 of the x's are part of a token and the 7'x could be more than
>> one token. You don't have a clue.
>
>What are your understanding of a binary file????? I listed only the
>last 2 bytes without specifying whether these are 0 or 1. The last
>Huffman code had, by assumption, 9 bits and hence was represented
>by 9 y's. The x's represent bits from any (unspecified) number of
>Huffman codes. If I were to describe the last 5 bytes, I would
>have written as follows:
>
> xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxy yyyyyyyy
I realy doubt you understand what is going on but i will give it another
shot. What you have is not necessarily the form that my program
compresses too. There fore it might not decompress to the file
that you expect. The reason is that my compression/decompression
program addresses the end of file in a specail way. I have modifed
it to be "one to one" which I have defined to you several times. But
you still don't get it. When compressing the last huffman code may
or may not be written out. But again you don't understand do you.
I wish you would ask you ask what happens with real (but you can't)
example. giive me a file as HEX like "ff 00 ff" and I will tell you what
it compress to or decompresss to. Is this to hard for you since I see
absoultely no other way to communicate with you since I you don't
have the foggegst idea what i am saying. Is concrete examples to
hard for you?
for the rest look at http://members.xoom.com/ecil/compress.htm
>
>The very dirty words you employed above and also in your last
>follow-up don't belong to the vocabulary of ANY educated person!!!
>It's extremely deplorable that such stuffs ever come into scientific
>discussions that are, in particular, in written form and further get
>archived for future reference (by both members of this group and
>outsiders). It is a shame that discussion in this group ever came
>down to such a low level. It is really time to stress that we are
>in a sci-group not in a chat room!!!
If I could find another way to talk with you I would be you don't
seem to understand. I write the way I feel and when I get pissed
at you for not following I may use strong langauage. If it bothers
you don't answer the dam letters casue I think you are playing
a stupid game with me. This stuff is not that hard you must be
faking it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: One-time pad encryption.
Date: Tue, 24 Aug 1999 06:07:45 +0200
Please explain the weakness of this senario (besides the fact that the
"key" has to be within reach and that finding "random" characters
usefull to be used might in field be quite hard):
Agent X and Agent Y wants to send encrypted messages to eachother, they
pick OTP; which they use like this:
The needed area for the message is this long:
xxxxx
xxxxx
xxxxx
That possible number of characters (it might be shorter and then padded,
but if longer then two messages would have to be sent) is then "hidden"
by padding it with "randomly" picked characters so that you might get
something like this (no pattern beyond being able to be read by a human
is needed):
xxxxx
12345
xxxxx
xxxxx
67890
12345
Added to the above is then the next OTP to be used (not for the reply,
but for the next encrypted message from that agent):
xxxxx
12345
xxxxx
xxxxx
67890
12345
09876
54321
09876
54321
09876
54321
That "packet" is then being "encrypted" using the OTP from the last
message, the OTP is used twice to cover the 2([length of the OTP]) long
message.
My reasoning is that using the OTP twice shouldn't weaken this based on
the fact that the second time it's being used it's used on a "text" that
has been randomly picked and that contains no words or any other
information that could be compared to the known to be a text part of the
message (where the known to be text-part has been located by knowing the
basic structure of this method).
Is this the best possible way to implement OTP in a everyday situation
where you want to send secure messages?
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: The Reversal of NetNanny
Date: 24 Aug 1999 04:37:07 GMT
Hello,
Very interesting article. I enjoyed reading it -- this definitely is
a sci.crypt type of article, IMHO. Good semi-formal write up that was
accurate but keeps your interest, without adding unnecessary technical
detail.
It's nice to see practical real world application of all this theory
we talk about soo much here.
Keep us posted on future achievements.
Keith
[EMAIL PROTECTED] wrote:
: Hello.
: While this is not science, and while the application targeted isn't an
: encryption-product per se, I thought this essay might interest some of the
: readers of this group.
: The essay is called _The Reversal of NetNanny_ and you'll find it at
: http://hem2.passagen.se/eddy1/reveng/nn/
: In it we describe how we 'reverse engineer' this program, a process which
: involves some very simple and extremely basic cryptanalysis (if it may so be
: called).
: Feedback appreciated.
: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Tue, 24 Aug 1999 04:44:47 GMT
In article <7pt1ac$1224$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Who says they are getting good crypto. They most likely have people
> with no mathematical background like Hamilton picking software for
them
> or they use the pusedo secure stuff like DES or AES.
This is for the year books ladies and germs.
Hey AES people you haven't a clue about crypto... hehehe. Yeah right,
look who talking.
Can someone please do a mass kill on him? Get him out of here...
byebye.
I would love to see two things in my crypto life
1) He proves his method is secure
2) He proves AES algorithms are weak....
BTW, does anybody actually read his posts for intellectual content or
do they get a good chuckle as well?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: crypto RNG and permutations
Date: Tue, 24 Aug 1999 04:41:40 GMT
I programmed a crypto RNG that works like this
i = cycle length (between key swaps)
b = number of blocks in a key
start:
for n = 0 to (i+b)
output[n] = Ek(n)
k = output[n..n+b]
goto start (as required)
Where the last b outputs are used to make a new key. I was wondering
from a remote position (i.e seeing the outputs only) is this even
relatively secure (assuming the attacker knows nothing of the original
k value) only the n values?
in my C example I am using Blowfish with the max key size (448 bits, 56
bytes or 7 blocks). I know that the new keys is not a 'total' 448 bits
since each block is different. What would the keyspace of such a new
key be?
If anyone wants to see the C example (it's a mini-lib) just mail me.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Vigenere/Kasisky problem
Date: 24 Aug 1999 04:57:57 GMT
Partial or complete transposition after the Vigenere encipherment
(superencipherment) does make cryptanalysis more difficult, and for a single
polyalphabetic message in an unknown transposition system may be realistically
unbreakable by paper and pencil techniques.
There is an interesting method to create an aperiodic (sort of)
encipherment using a Vigenere encryption wherein the encipherment is done using
word length encryption. Thus the first word has a period equal to its length
(e.g., attack is enciphered using cipher alphabets 1 through 6), the second
word has a period equal to its length (tomorrow is enciphered using cipher
alphabets 1-9), etc... Cryptanalysis of that approach is taught as the
transition from periodic polyalphabetic ciphers to aperiodic polyalphabetic
ciphers in the Army correspondence course I'm taking.
Jeffrey Tong [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Vigenere Variant Problem
Date: Mon, 23 Aug 1999 16:20:19 GMT
[EMAIL PROTECTED] () wrote, in part:
>JTong1995 ([EMAIL PROTECTED]) wrote:
>: Also. the explanation of indirect symmetry of position that is somewhat
>: muddy in FM 34-40-2. Does anyone know of a clearly written description in
>: another source?
>I recently added a description of indirect symmetry of position to my web
>page, but I don't know if it's very clear.
It's on the page
http://www.freenet.edmonton.ab.ca/~jsavard/pp010103.htm
and is at least clearer than the explanation I gave in my post, which
was incomplete.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Wim Lewis)
Subject: Re: Entropy in "modified" passwords
Date: Wed, 18 Aug 1999 04:59:06 +0000
In article <[EMAIL PROTECTED]>,
Nick Battle <[EMAIL PROTECTED]> wrote:
>If I do something unpredictable - in effect defining a new
>transformation function as part of the "password" - then it looks to me
>as though this *does* increase the entropy in the system, not by
>supplying more random data but by providing a function that modifies the
>initial password in an unpredictable way (to someone who doesn't know
>the password/function combination).
>
>I'd like to ask two things: is it appropriate to talk about a function
>representing a certain amount of entropy like this, and if so, how would
>one go about evaluating how much entropy is represented by a given
>function in this scenario?
Perhaps you can think of the "unpredictable function" as being a
predictable (known) function with an unpredictable input. For example,
let's say you choose a hash function for the password (instead of
always using MD5 or SHA). There's going to be some finite pool of
hash functions from which you choose --- say, SHA-1, MD5, RIPE-MD,
and HAVAL. So, it would be perfectly valid to describe this as
*one* hash function, which takes an extra input 0..3 which alters
its behavior --- MultiHash(X,0) is the same as SHA-1(X), and MultiHash(X,1)
is the same as MD5(X), etc. It's obvious from this construction that
choosing randomly from among four hash functions adds (at most) two bits
of entropy to the final hash.
Other tweaks (such as changing the initial constants in the hash
function, etc.) can also be described as a function taking an extra
input. The entropy of that input puts an upper bound on the entropy
added to the final hash.
My guess is that if the hash function you choose is any good, this method
is no more secure than simply appending the extra variables to the message
being hashed.
--
Wim Lewis - [EMAIL PROTECTED], also hhhh.org - Seattle, WA, USA
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 24 Aug 1999 04:18:39 GMT
In article <[EMAIL PROTECTED]>,
Rochus Wessels <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > [...] By the way, if
> > a "traditional" type of attack is found against finalist A that
> > requires 2^50 known plaintexts and 2^50 computer resources (some
> > function of work and memory) and another attack is found against
> > candidate B that requires only a thousand plaintexts and 2^100
computer
> > resources, which cipher should be considered more secure?
>
> If computer resources are defined as time*memory (which is reasonable,
> since most attacks allow time/memory-tradeoffs), (A) is more secure.
> BUT only, if there is no tradeoff resources/#texts (depends on
attack).
I would say that cipher B is more secure, precisely because in the
real world 2^50 plaintexts are not available or else it is a trivial
matter to deny the attacker a great many known or chosen plaintexts
encrypted with the same key; therefore any type of attack that
depends on a lot of plaintext will almost certainly not work in
practice. On the other hand a type of attack that works with few
plaintexts but that requires a lot of work has time and
technological evolution on its side. It is conceivable that
advances in fabrication technology for highly parallel, fault
tolerant computers (even one-computer wafers), or even completely
new kind of computers (quantum etc.), will make it cost-effective
in the next 50 years to routinely do 2^100 work. In other words,
2^50 known plaintexts are not really possible, but 2^100 work may
become feasible in the next 50 years.
By the way, time and memory resources are not completely
independent. If random access memory is required then there is a
time cost for addressing a large memory, i.e. on any given
technology the bigger the memory the slower the access. Fundamental
physics play a role here: the larger the memory the more space will
it fill and therefore more time will be needed for a signal to
cover the distance between memory and processor. So, a better cost
function for computer resources should be Cost = Time * Memory^K
with K>1.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 24 Aug 1999 04:07:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> [EMAIL PROTECTED] wrote:
>:I would rather see time invested and work done under the assumption
>:of a reasonable attack model. If all finalists turn out to be equally
>:strong under this model, then other reasonable parameters can be
>:taken into account for judging their security (simplicity, mature
>:design philosophy, partial proofs, even trust in their designers).
>:Otherfactors such as implementation flexibility and speed will count
>:also.
>
>Well, an unreasonable attack model _is_ very much an example of an
>"other reasonable parameter". It's more indicative of security than
>many of the few other choices remaining.
I agree up to a point. If a purely theoretical attack is found
against candidate A and nothing at all is found against candidate
B, then one can argue that A has a "flaw" that can grow it the
future, whereas B is "perfect". There is in fact a good posibility
(as Wagner mentions in another post) that several finalists will
endure the second phase of the AES competition flawlessly as far as
security is concerned.
On the other hand, if an attack is found against cipher A that
requires 2^60 plaintexts and an attack is found against B that
requires 2^70 plaintexts, I believe that the practical significance
of this for choosing between them is zero. Here, I would rather
take into account parameters such as simplicity, or even, using
Schneier's memorable phrase, give weight to the "warm and fuzzy
feelings" of experienced cryptanalysts. Cryptology is really a very
young and underfinanced discipline, and may still be more an
alchemy than a science. So we should better not let fancy numbers
attain meaning that is not really there.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
