Cryptography-Digest Digest #246
Cryptography-Digest Digest #246, Volume #14 Fri, 27 Apr 01 03:13:00 EDT Contents: Re: Censorship Threat at Information Hiding Workshop (AY) Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED]) Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED]) Cryptography FAQ (03/10: Basic Cryptology) ([EMAIL PROTECTED]) From: AY [EMAIL PROTECTED] Subject: Re: Censorship Threat at Information Hiding Workshop Date: Fri, 27 Apr 2001 03:21:15 +0100 When that audience receives that same work in other ways -- even if others just give it away -- the market for the original work is reduced. If that is not stealing worth from the intellectual property owner, what is it? So you say reducing the market for the original work is an instance of theft. Libraries *buy* the books they have. Buying is not theft. Indeed, one might well argue that having a book in libraries *increases* the market for the book. But wouldn't it be an equally valid point that :- The library buys a book = I can access my library and borrow the book for free = I don't need to buy the book = The market for the book is reduced = This results in an instance of theft on the library's behalf Let's say, I, as an individual, buy a copy of a book, and lend it to everyone I know who needs it, and all of whom would otherwise have bought the book. Would I be committing the act of theft by reducing the market for the work? AY -- Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (01/10: Overview) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 27 Apr 2001 07:02:31 GMT Archive-name: cryptography-faq/part01 Last-modified: 1999/06/27 This is the first of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read this part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. Disclaimer: This document is the product of the Crypt Cabal, a secret society which serves the National Secu---uh, no. Seriously, we're the good guys, and we've done what we can to ensure the completeness and accuracy of this document, but in a field of military and commercial importance like cryptography you have to expect that some people and organizations consider their interests more important than open scientific discussion. Trust only what you can verify firsthand. And don't sue us. Many people have contributed to this FAQ. In alphabetical order: Eric Bach, Steve Bellovin, Dan Bernstein, Nelson Bolyard, Carl Ellison, Jim Gillogly, Mike Gleason, Doug Gwyn, Luke O'Connor, Tony Patti, William Setzer. We apologize for any omissions. Archives: sci.crypt has been archived since October 1991 on ripem.msu.edu, though these archives are available only to U.S. and Canadian users. Another site is rpub.cl.msu.edu in /pub/crypt/sci.crypt/ from Jan 1992. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. The fields `Last-modified' and `Version' at the top of each part track revisions. 1999: There is a project underway to reorganize, expand, and update the sci.crypt FAQ, pending the resolution of some minor legal issues. The new FAQ will have two pieces. The first piece will be a series of web pages. The second piece will be a short posting, focusing on the questions that really are frequently asked. In the meantime, if you need to know something that isn't covered in the current FAQ, you can probably find it starting from Ron Rivest's links at http://theory.lcs.mit.edu/~rivest/crypto-security.html. If you have comments on the current FAQ, please post them to sci.crypt under the subject line Crypt FAQ Comments. (The crypt-comments email address is out of date.) Table of Contents = 1. Overview 2. Net Etiquette 2.1. What groups are around? What's a FAQ? Who am I? Why am I here? 2.2. Do political discussions belong in sci.crypt? 2.3. How do I present a new encryption scheme in sci.crypt? 3. Basic Cryptology 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key? 3.2. What references can I start with to learn cryptology? 3.3. How does one go about cryptanalysis? 3.4. What is a brute-force search and what is its cryptographic relevance? 3.5. What are some properties satisfied by every strong cryptosystem? 3.6. If a cryptosystem is theoretically unbreakable, then is it guaranteed analysis-proof in practice? 3.7. Why are many people still using cryptosystems that are relatively easy to break? 3.8. What are the basic types of cryptanalytic `attacks'? 4. Mathematical Cryptology 4.1. In mathematical terms, what
Cryptography-Digest Digest #246
Cryptography-Digest Digest #246, Volume #13 Thu, 30 Nov 00 12:13:00 EST
Contents:
Re: RC4 Questions (Guy Macon)
Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys! (PhyloBhetto)
Re: Probability Question on Square Attack (John Savard)
Re: keysize for equivalent security for symmetric and asymmetric keys (DJohn37050)
Vulnerability to Attack ("James Dabbs")
Re: voting through pgp (Dan Oetting)
Re: Pentium 4 and modular exponential ("James Dabbs")
Trivial Encryption Algorithm (TEA) ("James Dabbs")
PRNGD for Windows ("James Dabbs")
Re: Trivial Encryption Algorithm (TEA) (John Myre)
ARCFOUR (RC4) used for CipherSaber-N (Glide)
Re: Trivial Encryption Algorithm (TEA) ("James Dabbs")
Re: Pentium 4 and modular exponential ("James Dabbs")
Re: Vulnerability to Attack (Eric Lee Green)
Re: Trivial Encryption Algorithm (TEA) (Simon Johnson)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4 Questions
Date: 30 Nov 2000 06:01:28 GMT
James wrote:
After reading the information on the ciphersaber web site, I have a few
questions about RC4.
The site led me to believe that the maximum secure key length was 512 bits
(where the key is the string used to initialize the random number
generator). Is this correct??? Could I use a longer key and not have my
security compromised?
From http://ciphersaber.gurus.com/
"To leave room for the initialization vector, the length of the
user key must be less than 246 bytes (1,968 bits). To insure
adequate mixing of the initialization vector and user key, we
recommend you select a user key of 54 bytes (432 bits) or less."
http://ciphersaber.gurus.com/cryptanalysis.html
"In most cryptosystems, the longer the key, the better. However,
it was pointed out by several individuals who looked at
CipherSaber-1 that a very long user key could prevent the IV
from affecting more than a few of the S(i) values. This could
cause leakage of plaintext. To insure adequate mixing, we
advised users to restrict their user key length to 54 characters
or less, as most would anyway. This insures that the IV will
be mixed in at least four times during the setup process."
A key of 41 bytes (328 bits) insures 5 mixings
A key of 54 bytes (432 bits) insures 4 mixings
A key of 74 bytes (502 bits) insures 3 mixings
Please note that the effect of not enough mixings is to allow an
attacker to make a slightly better than random guess as to what
the second byte in your plaintext is. That's it.
Also, the ciphersaber implemtation suggests appending a fixed
number of random bytes to the end of the key (10), and then
placing these random bytes at the start of the encrypted stream.
Doesn't this compromise security??? Is there something I'm missing??
The ciphersaber web page doesn't "suggest" anything. You must
do it the way they say or it isn't ciphersaber. Ciphersaber is
one of many implementations or ARCFOUR - you are free to do it
however you please, but not to call the result ciphersaber.
The 10 random bytes let you use the same 54 bytes as your key
over and over, yet still allow ARCFOUR to see a different 64
byte key every time. On the other end, the repipient who knows
your 54 byte key needs to know those extra 10 bytes, so they are
sent in the clear.
Now I have a question for you; why do you wish to use a longer key?
Surely you don't believe that someone will do a brute force guess
and come up with your 54 byte/432 bit passphrase! I understand
the temptation - when I am faced with an encryption scheme that allows
keys of 128, 256, 512, 1024 and 2048 bits, I pick 2048. There is
no added security over 1024 bits though; all I am doing is stealing
CPU cycles from my sreensaver...
If you want to maximize your security, just implement ciphersaber as
described. You will be using a system that has been tested and
attacked over and over again without breaking. Why give that up for
a nonstandard, untested variant?
On the other hand, if your purpose is to learn rather than just to
keep your data secure, then by all means try various modifications.
--
From: PhyloBhetto [EMAIL PROTECTED]
Subject: Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys!
Date: Thu, 30 Nov 2000 14:19:20 GMT
In addition... if you actually watch the packets on the supposed
encrypted line, you'll find that they aren't encrypted at all... The
user/password were the only things encrypted for me.
In article [EMAIL PROTECTED],
Eric Smith [EMAIL PROTECTED] wrote:
I've been trying to find an FTP client for Windows that supports SSL,
and tried WS_FTP from Ipswitch. It's inexpensive, and they provide
a time-limited demo.
I'm very glad that they provided the demo. If I'd paid money for it
I'd demand a refund. I found out the
Cryptography-Digest Digest #246
Cryptography-Digest Digest #246, Volume #12 Wed, 19 Jul 00 09:13:01 EDT
Contents:
Re: PGP US Versions Broken,no good?? (jungle)
Re: RC4-- repetition length? (Bill Unruh)
Re: Good free stream cipher ? (Boris Kazak)
Re: PGP US Versions Broken,no good?? (Dave Ashley)
Stream Ciphers one way hash Question (Nemo psj)
Re: PGP US Versions Broken,no good?? (Stray Cat)
Re: Cipher Block Chaining (Mok-Kong Shen)
Re: RC4-- repetition length? ("Scott Fluhrer")
Re: Good free stream cipher ? ("Scott Fluhrer")
Re: Carnivore and Man-in-the-middle (Steve Rush)
Re: Good free stream cipher ? (Runu Knips)
TAGGED INFORMATION (+wuff)
how strong is my own encryption? ([EMAIL PROTECTED])
Re: Good free stream cipher ? (Sébastien SAUVAGE)
Re: how strong is my own encryption? (Eric Hambuch)
Re: Crypto source code library suggestions? (Bob Deblier)
Re: Crypto source code library suggestions? (Tom Anderson)
Re: Win2000 Encryption (Daniel James)
Project (Teo Li Xi)
Re: PGP US Versions Broken,no good?? (Richard Herring)
Re: Carnivore and Man-in-the-middle ("matt")
Re: how strong is my own encryption? (Runu Knips)
From: jungle [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: Tue, 18 Jul 2000 23:34:17 -0400
you are showing by your writing,
that you don't have any idea, after reading my post, what I did say ...
complete lack of intelligence, at least ...
An Metet wrote:
viper wrote:
I've heard from a few people(one who is a
programer of encryption software) that the
US versions of PGP(6.5.3 etc) are broken,
no good and the US gov. can break them
because these versions are made so they
can be broken so the gov. can read anything
encrypted by the US versions. Could just be
an urban myth but I 've dumped my 6.5.3 for
6.5.1i(international)(supposedly safe)
jungle wrote:
it's not what you did hear, but what you can confirm ...
I did hear that v651i is broken ...
the reliable one is only v262 ...
Jesus, jungle. I don't know why I keep using temporary kill
filters on you. They expire after 14 days and I come back
to yet more of your non sequiturs.
You are a bona fide idiot. I'm making this filter permanent.
*PLONK*
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4-- repetition length?
Date: 19 Jul 2000 04:07:44 GMT
In 8l32co$q9t$[EMAIL PROTECTED] "Scott Fluhrer" [EMAIL PROTECTED]
writes:
- It is now known that RC4 is efficiently distinguishable from random data
after 2Gb.
What is the distinguisability (Ie, how is it distinguishable).
--
From: Boris Kazak [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Good free stream cipher ?
Date: Wed, 19 Jul 2000 04:58:58 GMT
Runu Knips wrote:
I'm looking for a good free stream cipher algorithm.
Does anybody have a suggestion ?
=
Recipe: Take BLOWFISH and run the key setup procedure.
You will have 5 arrays of subkeys.
P[72], S0[1024], S1[1024], S2[1024], S3[1024]
Now your stream cipher will look like following:
Ct[i] = Pt[i]^P[i%71]^S0[i%1019]^S1[i%1021]^S2[i%1023]^S3[i%1024]
(you can verify yourself that 71, 1019, 1021, 1023 and 1024 are
all mutually prime)
The period of this generator will be equal to the product of
all 5 numbers = 77380915780608 ~ 2^46.
Any intermediate byte from this series is available once you
know the index.
I hope that your message will be shorter than that, in any case
you always have the option of rekeying.
Best wishesBNK
--
From: Dave Ashley [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: Wed, 19 Jul 2000 04:53:03 GMT
If I understand PGP correctly, there is an easy way to check.
Just encrypt the same file or text using the same key on both products.
If the output is the same, the later version has not been "broken".
Hope this makes sense.
Dave.
In article [EMAIL PROTECTED],
jungle [EMAIL PROTECTED] wrote:
you are showing by your writing,
that you don't have any idea, after reading my post, what I did
say ...
complete lack of intelligence, at least ...
An Metet wrote:
viper wrote:
I've heard from a few people(one who is a
programer of encryption software) that the
US versions of PGP(6.5.3 etc) are broken,
no good and the US gov. can break them
because these versions are made so they
can be broken so the gov. can read anything
encrypted by the US versions. Could just be
an urban myth but I 've dumped my 6.5.3 for
6.5.1i(international)(supposedly safe)
jungle wrote:
it's not what you did hear, but what you can confirm ...
I did hear that v651i is broken ...
the reliable one is only v262 ...
Cryptography-Digest Digest #246
Cryptography-Digest Digest #246, Volume #11 Fri, 3 Mar 00 14:13:01 EST
Contents:
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? (wtshaw)
Re: CRC-16 Reverse Algorithm ? (Scott Nelson)
Cellular automata based public key cryptography (Tim Tyler)
Re: Best language for encryption?? (wtshaw)
Re: Best language for encryption?? ("Brian Hetrick")
Re: Cryonics and cryptanalysis (Darren New)
Re: Cryonics and cryptanalysis (Darren New)
Re: New US export regs (was Re: Crypto.Com, Inc.) (wtshaw)
Re: Hidden computation (Re: Cryonics and cryptanalysis) (Mike Rosing)
Re: very tiny algorithm - any better than XOR? (Terry Ritter)
Re: IDEA question. (Chris DiTrani)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:17:29 -0600
In article 89n2ju$np6$[EMAIL PROTECTED], [EMAIL PROTECTED] (Paul
Schlyter) wrote:
In article [EMAIL PROTECTED],
wtshaw [EMAIL PROTECTED] wrote:
No mention of these is in the literature I have on C/C++,
Are you sure? Really sure? If so, your literature is bad and should
be replaced.
When clear and conciseness is obvious, fine. It is not, so programming in
C/C++ remains art rather than science. I'll play along.
...
which makes my point...that there is too little standardization
in how the languages are fully used, as opposed to a set of commands
that are easily learned, at least by many who I have taught.
I'm sorry, but these are deficiencies in the literature and/or the
programmers -- not in the languages themselves!
Stroustrup omits it too.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:38:44 -0600
In article [EMAIL PROTECTED], "Trevor Jackson, III"
[EMAIL PROTECTED] wrote:
Djikstra commented on this issue, claiming that people he encountered
(students)
who learned languages like BASIC first were mentally damaged in that it
was very
difficult for them to think certain ways. I'd be willing to bet the effect is
measurable.
This could be that people trained to cut through the crap are unsettled
when they meet those that like to pile it on.
BASIC was developed before C. It was based largely on Fortran, rather an
offshoot of it. The difference is simply a single versus double
bookkeeping system of logic. People natively think in single entry. It
is more that lawyers and bureaucrats do double entry so that they can
check each others' work. Computers are generally dumb, so something like
Cobol works, but is uninspired when compared with mature languages.
Higher language compillers are more intelligent, to take some of the
burden away from programmers, find myrids of mistakes early, and guide
correction. Programming is not the end, it is the means, and the same for
computers and humans. Depending on compiler of any language, the code
produced can rival honed assembly.
This has lots to say about crypto, and the deficiency of thinking in
limited ways. It isthe big myth that we fight against, that things must
be difficult that are not inately required to be. Progress is doing away
with the innane.
Good algorithms are not that hard to fine, and good immplementations not
that hard to write if you think top-down and use the tools that get better
every day. The same goes for security matters in gneral. I am learning why
so many think otherwise; what a shame. The unwelcomed result of the
prevalence of how things are is that many live to cultivate problems
rather than using adequate solutions.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Figure that they will expense it all
before figuring out what is wrong with their planning personel.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 10:46:42 -0600
In article [EMAIL PROTECTED], "Douglas A. Gwyn"
[EMAIL PROTECTED] wrote:
I sure as heck hope you're not trying to "teach" C as you see it.
C is *quite* well standardized, and how to use Standard C to
program portably has also been quite fully developed.
Of course not, you are the authority there. I yield to your expertise,
but I am not afraid of analysing the philosophy and methods of lower
versus higher languages, or deficiencies of any.
Technology generally has outrun console programs as final product, and
people need not continue to walk when the can or need to fly.
--
Present Government Security is a sandcastle build on a beach
beside a lagoon at low tide. Fig
Cryptography-Digest Digest #246
Cryptography-Digest Digest #246, Volume #9 Wed, 17 Mar 99 15:13:04 EST
Contents:
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Mark Currie)
Re: Crypto transmission in noisy ambient (Mark Currie)
Re: a5 (Andrew Haley)
Re: One-Time-Pad program for Win85/98 or DOS (Patrick Juola)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Doug Stell)
CUNY CRYTOGRAPHY SEMINAR (MikeAt1140)
? Random et BigInteger (Gallicus)
TESTINTONLY (sb5309)
Re: PGP Protocol question (Jim Gillogly)
Re: a5 ("Maciej Maciejonek")
Re: PGP Protocol question (Medical Electronics Lab)
Re: a-8d~0.2844.5k:-89y (JimB417)
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: 17 Mar 1999 10:24:32 GMT
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says...
And, because of this concern, I expressed some doubt that, as some books
have claimed, that the STU-III or other current advanced encryption
equipment would operate without key material in the manner of a copy of
PGP. But I noted that one could still use public-key techniques, even if
one doesn't fully trust them, as one leg of a 'triad', to use a term from
nuclear defense terminology. And so, I will summarize a point I tried to
make in another post some time ago:
Key hidden in hardware - compromised through reverse-engineering of
captured hardware.
Key loaded by personnel - vulnerable through suborning of personnel.
Key generated and used via public-key mechanisms - vulnerable through
mathematical advances.
If you're handling military secrets, use all three mechanisms - each one
with a key big enough so that if one of the three keys only remains
secure, your communications are secure. If the 'big boys' _aren't_ doing
this, they should start thinking about it.
It is probably wise to combine secret cryptography techniques with public key
ones, however, do you not then create problems with key management. Now you
have to maintain a secret key management system with all its limitations that
the public key systems were supposed to cure. Quite often the real security
problems with secret key systems were in fact in the management thereof. Unless
the concurrent secret key management system provides relatively the same
security level as the public key one, then it may end up only being an extra
nuisance factor for a serious attacker.
I guess that where the big boys are concerned however, they can afford the
overhead of providing a strong secret key management system as well.
Mark Currie
--
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Crypto transmission in noisy ambient
Date: 17 Mar 1999 10:41:49 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] says...
[snip]
2) Use a pure stream cipher with no error-propagation, with a message
format (i.e. uncompressed text) that can still be read in case of error.
[snip]
This can be a very useful method. However, another problem that tends to
occur in a noisy comms environment is "bit slip/gain". i.e. when the data is
reconstructed, it has shifted by one or more bits. On a stream cipher, this is
disasterous since you loose key stream synch permanently. There are however
techniques that can be applied to correct for this such as bit-wide cipher
feedback or inserting synch characters in the data stream. However, these
techniques obviously propagate errors, and may only be useful where the data
itself is error tolerant such as voice, graphics, etc.
Mark Currie
--
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: a5
Date: 17 Mar 1999 11:30:32 GMT
Maciej Maciejonek ([EMAIL PROTECTED]) wrote:
: Anybody knows any facts about cipher a5 (a3,a8).
It's not a very good cipher.
: I'm interested in algorithm of this cipher, becouse I'm considering
: its implementation in hardware ( Altera environment )
Search for the following news artile on http://www.dejanews.com
From: [EMAIL PROTECTED] (Ross Anderson)
Newsgroups: sci.crypt,alt.security,uk.telecom
Subject: A5 (Was: HACKING DIGITAL PHONES)
Date: 17 Jun 1994 13:43:28 GMT
Andrew.
--
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: 17 Mar 1999 08:25:36 -0500
In article 7cnkt1$2bme$[EMAIL PROTECTED],
Johan Hartzenberg [EMAIL PROTECTED] wrote:
Hi
I'm probably going to put my foot in it, but that's the way I learn.
+
A true random number is one that is produced by a process that is
capable of generating all finite sequences equiprobably. That process
is called a True Random Number Generator (TRNG) and can never be the
reulst of algorithmic calculation. Equiprobable means independent and
equidistributed.
+
whic
