Cryptography-Digest Digest #447, Volume #13 Tue, 9 Jan 01 21:13:00 EST
Contents:
Re: xor'd text file ("Paul Pires")
Re: SOFTWARE BETA TESTERS URGENTLY REQUIRED (Nemo psj)
Re: Crypto book with mathematical explanations? ("M.S. Bob")
Twofish for dummies ("Robert Larsen")
Re: xor'd text file - Cryptanalyis of Simple Aperiodic Substitution Systems
(Warning: LONG post) ("Paul Pires")
Re: secure DOS files ("Thomas J. Boschloo")
Re: Password security for file transfer w/o speed loss? (Thomas Wu)
Re: Comparison of ECDLP vs. DLP (D. J. Bernstein)
Re: NIST hmac fips (David Hopwood)
Re: Comparison of ECDLP vs. DLP (Gregory G Rose)
Re: secure RNG (Tom St Denis)
Re: Need of very simple algorithms? (AllanW)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: xor'd text file
Date: Tue, 9 Jan 2001 13:06:40 -0800
Forrest Johnson <[EMAIL PROTECTED]> wrote in message
news:93dfq9$[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joshua Cryer) wrote in
> <SmO56.16021$[EMAIL PROTECTED]>:
>
> >> I dont quite understand what you mean by 'seed'. The number 65535 is
> >16bits
> >> in binary. Do you mean the number which is <= 65535 has been XOR'd
> >> with
> >every
> >> 16 bits in the text file? If that was the case then frequency analysis
> >would
> >> still work pretty well on the file. Look at how many times each byte
> >occurs
> >> in the text file. The highest frequencied items will most likely be
> >plaintext
> >> space or E. From there you can figure out what number would transfer
> >> the ciphertext letter into space or E. Apply this to the whole file
> >> and see
> >what
> >> happens.
> >
> >What I mean is this. The file is XOR'd to a pseudo-random number
> >generator which is limited to 65535 possible seeds (yeah, 16 bits). I
> >actually know many words, and even complete sentences that were used in
> >the original text file. I just don't know how I could begin to reverse
> >engineer since I know for certian that it was XOR'd at least twice
> >(maybe more) with two different seeds. Someone told me that this is very
> >crackable. Well. How?
> >
> >
>
> You mentioned in your original post that the enciphered file is very large.
> Is it larger than 65535 bits? If so, you should be able to take advantage
> of the fact that a PRNG has a period that is very commonly equal to the
> size of the seed space. Thus, the cipher stream from the PRNG will start
> repeating after 65535 bits.
Another chance to learn :-) I think there are problems with the above
statement, correct me if I am wrong. It's the "very commonly" part.
He said the seeds were 65535 bits and that he did not know the PRNG
used, so I assume he doesn't know the size of the internal state, what I
assume you are refferring to as the "seed space". The cipher must repeat
when it's output exceeds it's internal state (It cannot exibit more complexity
than it contains) but when it acually does this is drivin by the actual PRNG
and the particular seed used unless it is a very bad PRNG indeed. If the
internal
state was 2048 bits like RC-4, then you are in for a fair job of hunting. Kind
of a birthday paradox. Figure out how big the population of a room needs to
be to have two states be identical whith a certain probability when there are
2^2048th different ones. This should tell you how often it is likely to occur.
The required population is the expected cycle at that probability. Finding the
lucky couple in order to exploit the effect sounds challenging.
Paul
>
> Even if the text was enciphered several times, using the same PRNG with
> different keys would still produce this cyclic pattern. The XOR function
> is commutative, so it doesn't matter what the order of application is -- A
> XOR B XOR C is equal to A XOR C XOR B. In addition, the operation of A XOR
> B XOR C is equivalent to A XOR Z where Z is equal to B XOR C. In other
> words, repeatedly XORing the plaintext file with a succession of values is
> the equivalent of XORing it with some other single value.
>
> Given this property and the cyclic nature of the PRNG, an XOR of the first
> enciphered bit with the 65536th bit will produce a a result equal to the
> two plaintext bits (1 and 65536) XORed together (providing the cycle is
> 65535). If you know the plaintext value of bit 1, you could then extract
> the plaintext value of bit 65536.
>
> You said that you knew some plaintext already. If you know the position of
> this plaintext in the file, you could test what I've suggested:
>
> 1) Take a string of enciphered text equal to the length of the known
> plaintext from the same position as the known plaintext.
>
> 2) XOR this string with another string equal in length and positioned one
> cycle away. The result should be two plaintext strings XORed together.
>
> 3) Finally, take your known plaintext and XOR it with the result of step 2.
> This should produce the second plaintext string. If you get gibberish, it
> means that the cycle length is wrong, the known plaintext is wrong, or the
> position of the known plaintext is wrong.
>
> You can also recover the portion of the cipher stream used for that string
> by XORing the enciphered text with the plaintext. If your file is several
> cycles long, you can then apply this recovered cipher stream to the proper
> positions in each cycle to extract the plaintext.
>
> If you don't know the position of the known plaintext, try a sliding window
> approach (using a technique similar to that described above) on enciphered
> strings that are a cycle apart and check the results for non-gibberish.
>
> If you don't know either the cycle length or the position of the known
> plaintext, you can still attack the enciphered text but it is going to be
> very tedious. It involves sliding the known plaintext throughout the file
> until you discover a cycle length that yields non-gibberish.
>
> Once you recover some plaintext from the enciphered file, make some guesses
> as to what other plaintext might be and apply the 3-step approach to check
> your guesses. (If you get gibberish at a cycle away, your guess was
> wrong.)
>
> Of course, this attack depends on the file being longer than one cycle of
> the PRNG. If it's shorter than that, this type of attack will not work.
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Date: 09 Jan 2001 21:21:45 GMT
Subject: Re: SOFTWARE BETA TESTERS URGENTLY REQUIRED
Jese you spammed this everywhere almost every news group I go to.. Althouhg I
know youll prob never see this.. I had to say it.
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Crypto book with mathematical explanations?
Date: Tue, 09 Jan 2001 21:27:50 +0000
Ingmar Grahn wrote:
>
> I'm looking for a book like "Applied Cryptography" by Bruce Schneier -
> however I want one that goes into a bit more detail in explaining the
> mathematical background, and possibly also one that covers the most modern
> algorithms too (since Schneier's book is a couple of years old). Any ideas
> of what might be a suitable book for me?
If you want to concentrate on understanding the mathematics of the
algorithms, and analysis I would recommend you consider these one of two
books first off.
Cryptography: Theory and Practice by Douglas Stinson
CRC Press; ISBN: 0849385210
<http://www.cacr.math.uwaterloo.ca/~dstinson/CTAP.html>
For full table of contents, and more details
1.Classical Cryptography
2.Shannon's Theory
3.The Data Encryption Standard
4.The RSA System and Factoring
5.Other Public-key Cryptosystems
6.Signature Schemes
7.Hash Functions
8.Key Distribution and Key Agreement
9.Identification Schemes
10.Authentication Codes
11.Secret Sharing Schemes
12.Pseudo-random Number Generation
13.Zero-knowledge Proofs
More theory then practice.
According to Amazon.com, there is suppose to be a new edition in June
2001.
A Course in Number Theory and Cryptography by Neil Koblitz
Springer Verlag; ISBN: 0387942939
Table of Contents
1: Some Topics in Elementary Number Theory
2: Finite Fields and Quadratic Residues
3: Cryptography
4: Public Key
5: Primality and Factoring
6: Elliptic Curves
Lots of number theory, nothing about block ciphers like DES and AES.
These books do not back off from the math required, so don't expect to
read these a chapter in one sitting, with ease.
Unfortunately they do not add to Applied Cryptography as far as being
up-to-date, they are textbooks aimed at giving a firm understanding with
a lots of math content.
If you want more of a reference, which is slightly (1-2? years) more
up-to-date, but is not designed to be a textbook, but a reference. The
web site includes downloadable PDFs of all the chapters.
Handbook of Applied Cryptography by by A. Menezes, P. Van Oorschot,
S. Vanstone
CRC Press ISBN: 084938523
<http://www.cacr.math.uwaterloo.ca/hac/>
------------------------------
From: "Robert Larsen" <[EMAIL PROTECTED]>
Subject: Twofish for dummies
Date: Tue, 9 Jan 2001 23:42:38 +0100
Hi all
I am new to cryptography and only a decent C++ programmer.
I have read Mr. Schneiers book about the Twofish algorithm and thought I
understood the key schedule (I haven't tried the encryption algorithm yet),
so I implemented it. The problem is, that given the test vectors my code
produces a wrong extended key. I tried reading the code by the designers but
none of the code seemed familiar to me even after knowing the design.
Does anybody have an easy to understand implementation of the algorithm
(preferably in C/C++ or Java) they are willing to share ?
Thanks in advance
Robert Larsen
[EMAIL PROTECTED]
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: xor'd text file - Cryptanalyis of Simple Aperiodic Substitution Systems
(Warning: LONG post)
Date: Tue, 9 Jan 2001 14:53:47 -0800
Matt Timmermans <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > [...]
> > For a cipher, stream or otherwise, to authenticate, you need one of two
> > things: it either must output garbage if an opponent changes some bits
> > of the ciphertext, or it must have appended to it some sort of secure
> > error checking code.
> >
> > For a stream cipher, the second can be done by appending a CRC or secure
> > hash. [...]
>
> Not a CRC. Since CRCs are linear, your encrypted message is still
> susceptible to bit flipping -- flip a bit, then flip the CRC bits that
> depend on it. The CRC will still match after decryption -- now that would
> be an amusing attack:
>
> "That's not the transaction I sent -- I said 5 dollars, not 262149!"
>
> "Sorry, but it has to be the transaction you sent -- it was encrypted with
> your key and the CRC matches."
Point taken. It would surely ruin my day :-)
Paul
>
>
>
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: secure DOS files
Date: Tue, 09 Jan 2001 22:32:28 +0100
Peter Osborne wrote:
>
> I've always dreamt of a real private computer, buttttt....
> Since I have probed around with "Scramdisk" and PGP, both seem to be
> well-featured, but that's not what I wanted. Isn't there a really
> simple programme anywhere which exactly does the following steps:
> You type in passphrase before working with your "top-secret"
> directory; these files will be decrypted by a quite poweful AND fast
> algorithm; files can be used as usual; when work is done, all
> sensibel files will be encrypted by that powefull AND fast algorithm,
> and, at last, passphrase or keys will be destroyed automatically
> before system gets shut down.
> Do such code already exist? I don't like to "engineer" it from adam
> and eve...
Write a batch-file for Scramdisk. It takes commandline options and
supports autorun.ini files under MS Windows 9x (NT payware, Linux is
work in progress). There is a scramdisk oriented newsgroup for further
questions and a scramdisk website at <news:alt.security.scramdisk> and
<http://www.scramdisk.clara.com>. Make sure you get the 3.02 version!
Thomas J. Boschloo
Den Helder
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Password security for file transfer w/o speed loss?
Date: 09 Jan 2001 15:17:39 -0800
Chris Kantarjiev <[EMAIL PROTECTED]> writes:
> You might take a look at SRP: http://srp.stanford.edu/srp/ which is
> designed for authentication only. There are some questions about the
> license, but the Stanford licensing office is trying to work them out.
SRP is free for both commercial and non-commercial use worldwide.
It handles secure password-based authentication and key exchange, so
it can be used to bootstrap a secure session based only on a user-
memorizable password.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Comparison of ECDLP vs. DLP
Date: 9 Jan 2001 23:08:32 GMT
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> All the RO crowd has is arguments for security, not proofs.
What the _proofs_ say is that you can factor public keys if the success
chance of your attack, averaged over all hash functions, is large.
---Dan
------------------------------
Date: Tue, 09 Jan 2001 23:23:59 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: NIST hmac fips
=====BEGIN PGP SIGNED MESSAGE=====
Roger Schlafly wrote:
> Keyed-Hash Message Authentication Code (HMAC)
> On January 5, 2001, NIST announced that a Draft FIPS for HMAC
> (keyed-hash message authentication code) is available for public review
> and comment.
> http://csrc.nist.gov/cryptval/hmac.html
>
> The HMAC specification in this draft FIPS is a generalization
> of HMAC as specified in Internet RFC 2104, HMAC, Keyed-Hashing for
> Message Authentication, and ANSI X9.71, Keyed Hash Message
> Authentication Code.
> http://csrc.nist.gov/cryptval/hmac/fr-hmac-200101.html
>
> It wasn't obvious to me how the new HMAC spec differs from
> RFC 2104. Anyone else notice?
The only minor difference I can see is that RFC 2104 says
# The key for HMAC can be of any length (keys longer than B bytes are
# first hashed using H). However, less than L bytes is strongly
# discouraged as it would decrease the security strength of the
# function. ...
whereas the draft FIPS says
# The size of the key, K, shall be equal to or greater than L/2, where
# L is the size of the hash function output. ...
This is not technically a generalisation, though.
Also the RFC talks about truncating the output to a given number of
bits, while the draft talks about truncating it to a number of bytes.
(In practice, no-one truncates HMAC to bit lengths that are not a
multiple of 8, so this makes no real difference.)
Neither the RFC nor the draft FIPS explicitly define "byte" as octet,
which they should (although that is implied in the draft by stating
that the input block size of SHA-1 is 64 bytes, and in the RFC by
stating that the output size of MD5 is 16 bytes or 128 bits).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOlptOjkCAxeYt5gVAQEMOQf/VghpPrjFrlEMap9l8OBI9VRh8Ruiv/tR
LSUVnUK894jwitTs1mYyRkBcq6T4+5pOFE2JjBkLbM8RN3cFSum7DwDHQ+ebyy71
P/+s8MVItF1q9jMNw5xYn4191Zt35sYgkkRhUxKy395LhnvXbPufJUnpqmw3jdBi
kYFaJqCvXsrNTJRsHHaANetn9p86/iNqDW08GD+r0Hp0pqm54nl30l9EO2ocmHFk
UXKUT/VpbyKn6Rxb6HpKBiRW4G73B3znHgeBB5509Q/UmHrE8Ji7I2Z1Nt8nGzGw
UH7sojnkFRa2/Fo+LdOEK9u9TRLiGgU1zKLs+1u/jrp/V60x/M5rjg==
=a9eB
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Comparison of ECDLP vs. DLP
Date: 9 Jan 2001 16:16:18 -0800
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>Some assumptions of the OTP are:
>1) You can generate true randomness.
>2) More importantly, you can distribute it ahead of time in sufficient
>quantities.
>3) You can ensure against reuse and solve sync problems.
These are assumptions about whether or not the OTP
is useful. They are in no way necessary for the
information-theoretic proof that the OTP is
secure.
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
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: secure RNG
Date: Wed, 10 Jan 2001 01:04:27 GMT
In article <93da5a$5j1$[EMAIL PROTECTED]>,
"Dobs" <[EMAIL PROTECTED]> wrote:
> I am looking for good random number generator which can be used in
> cryptography, ( for example in key generating) . If anybody knows where I
> can find such a secure generators implemented in C ( not in Visual C :),
> Could You please write me back or send it to me. I need 3,4 or 5 such a
> generators to compare. I would be greatful for help:))))
What is your definition of good? Compared to what tests? What speeds? What
hardware?
Often source code plays NOTHING todo with the quality of the prng. I.e take
the best implementation of Yarrow in a static shell (perhaps a AVR with no
I/O pins) obviously it can't work!
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Need of very simple algorithms?
Date: Wed, 10 Jan 2001 01:53:18 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> SMS is limited to 160 characters, as far as I know. Like
> telegrams, that has apparently proved to be useful in
> practice nevertheless. The degree of secrecy of a message
> is rarely correlated with its length, I believe. In
> particular, if a key is not 'over-used', I guess that
> even a rather simple algorithm could well serve its
> purpose in case of need for sending a short message.
A well-known principal is that short messages are much
easier to protect than long messages.
To borrow an example from encoding (which is different
than encryption but has similar objectives), imagine that
you have intercepted the following message:
"Anthropod. Repeat: Anthropod."
Does this mean "Attack at midnight, the guards should be
gone?" Or does it mean "I'm getting hungry, please bring
lunch?" Or maybe it means "All is well." One final
possibility is that it doesn't mean anything; it's just
flotsam, sent from time to time in order to make it more
difficult to recognize messages that do mean something.
If you don't have the codebook, there is absolutely no
way to break this code except to keep checking for other
codes and looking for patterns. For instance, if "Anthropod"
is frequently said in late morning or early afternoon, and
rarely at any other time, it probably means lunch. If it's
heard every hour on the hour it could mean "All is well."
And if you've listened to hundreds of previous messages but
never heard this word before, it could be flotsam, or it
could be the order to attack -- or it could be that they've
just started using a new codebook, in case you broke the
old one. (Or maybe the code changes every month.)
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
