Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #14 Thu, 7 Jun 01 18:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: MD5 for random number generation? (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Re: Brute-forcing RC4 ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Brute-forcing RC4 (Ichinin)
Any Informed Opinions? ("Robert J. Kolker")
Re: Alice and Bob Speak MooJoo (Ichinin)
Re: MD5 for random number generation? ("Tom St Denis")
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 16:48:45 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>: Tim Tyler <[EMAIL PROTECTED]> writes:
>:
>:> My claim is that the chances of collisions are generally greater if
>:> compression has been employed than if not.
>:
>: You are wrong to say ``generally greater''; you have not proven that
>: they actually are greater. You can only say they are ``no less''.
>
> ...the net effect is that they will be more frequent.
You don't have any idea what the net effect will be. In fact, I gave a
fairly thorough explanation why the net effect is almost certainly no
such thing. You need to *prove* that the ``net effect'' will be what
you say.
> If you have a fishtank and all the fish swim towards one end, the
> chances of finding fish at that end will be generally greater.
> Sometimes if you look by the castle you will find greater, fewer or
> an equal number of fish in its neighbourhood - but *on average* the
> density of fish at that end of the tank will be greater.
> The fish are plausible plaintexts. The tank represents files
> sorted by size. Files at the end of the tank are shorter than ones
> further away. The directional swimming of the fish represents
> compression.
GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
submit it to the Acta Mathematica, will you? You must be Isaac Newton
reborn!
Question: If there are 50 billion billion eels, and 2000 guppies, and
they all start in one end of the tank--which is 45,000 light-years long,
when can I expect to catch a guppy at the far end of the tank?
Translation: You keep using words like ``some'' or ``a lot'' or
``greater than'' or ``better'' without any attempt whatsoever to
verify that the hypothetical ``improvement'' will *ever* affect an
attacker.
> Did you miss my 129 bit message?
If that's not the only message you send, then we're NOT dealing with
only 129 bits; we're dealing with all the bits you encrypted with that
key. On the other hand, if you DID send only 129 bits with a 128-bit
key, and then throw the key away--but DIDN'T use a one-time pad, then
you're an idiot.
>: Bottom line: ``All BICOM gives you, assuming its correctness, is an
>: increase in the work required to brute-force the key.''
>
> If that's your bottom line then I have to say your panties are showing.
Didn't you used to date Ludwig Plutonium?
Len.
--
Performance speculation is bad. Performance hypocrisy is much worse.
-- Dan Bernstein
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 20:44:35 GMT
John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I see. You think you know better how to explain how Matt Timmermans
:> compressor operates than Matt Timmermans himself.
: Where does that come from?
http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
: On the whole, Len's posts are more convincing to me than
: yours are. [...]
Well, this isn't a popularity contest - this is a scientific forum.
Is there anything specific you don't agree with?
: He may be wrong, but he
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #13 Fri, 26 Jan 01 12:13:01 EST
Contents:
Re: Windows encryption: API and file system ("Ben Newman")
Re: Some Enigma Questions (Jim Reeds)
Weak DES keys/Weak Plaintexts ([EMAIL PROTECTED])
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Barrett modular reduction ([EMAIL PROTECTED])
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (John
Savard)
History Question: signatures in nuclear test ban verification? (Gerard Tel)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Paranoia (JCA)
Re: Why Microsoft's Product Activation Stinks (Richard Heathfield)
ICCIT2001 (CFP) ([EMAIL PROTECTED])
Re: What do you do with broken crypto hardware? (John Savard)
Re: What do you do with broken crypto hardware? (John Savard)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Ben Newman" <[EMAIL PROTECTED]>
Subject: Re: Windows encryption: API and file system
Date: Fri, 26 Jan 2001 14:41:34 GMT
Good point. I do think that they should at least zero out the sectors on
disk that contain the temporary file.
> Isn't it more a question of what kinds of attacks this encryption is
> supposed to defend against? Surely if the user's login record / password /
> whatever is used to encrypt the files, and no passphrase is needed for
> accessing an encrypted file, stealing the disk will give you all the
> information you need to decrypt the encrypted files anyway, yes?
>
> What kinds of attacks does Microsoft think this defends against? Theft of
> backup materials, maybe? Reading of files by administrators?
>
--
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: Some Enigma Questions
Date: Fri, 26 Jan 2001 14:52:52 GMT
In article <[EMAIL PROTECTED]>, "Yeah" <[EMAIL PROTECTED]> writes:
|> Didn't the British Government invent the worlds first programmable computer
|> to crak the enigma code. (Suck that America, IBM more precisely)
|> I think i once heard the lead designer on TV commenting that it too about 5
|> minutes to crack the code on their computer and that he once got the paper
|> reel spinning at 3 times the RPM of usual before it broke.
No.
You are thinking of the "Colossus", an electronic special
purpose calculator designed by Tommy Flowers of the British
Post Office labs to break a different German cipher. Colossus
used vacuum tubes and high speed (5,000 characters per
second) punched tape, but it was not programmable in the modern
sense of the word. (One had to set switches and plug plugboards
to change the parameters of a run.) It was definitely the
most technologically advanced instance of use of digital logic,
large-scale use of vacuum tubes, etc, at its time, but was (I
think) matched in conception by several contemporary computing
projects in America and Germany.
I suspect, but have no evidence, that the special purpose
number theoretical calculators built by D. H. Lehmer in the
1930s in California were a kind of mental jumping off point
for the Colossus team. The team that used Colossus, and
which commissioned Flowers to design and build it,
was full of pure mathematicians, who would have known of
Lehmer's machines.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
--
From: [EMAIL PROTECTED]
Subject: Weak DES keys/Weak Plaintexts
Date: Fri, 26 Jan 2001 10:01:12 -0500
I know that DES has some weak keys that make plaintext recovery easy.
Q. Are there weak DES plaintext that make key recovery easier?
Example: I control the plaintext, someone else does a single
des_ecb_encrypt(), and I receive the cyphertext. Is there a
particularly weak plaintext I could select to be encrypted to make the
unknown key be recovered eaiser?
Thanks for the help.
Please Reply or CC' me if possible, since I have limited newsgroup
access.
- Aaron
==
Disclaimer:
The views and opinions are soley mine and not my companies.
--
Date: Fri, 26 Jan 2001 09:25:33 -0600
From: Lord Running Clam
Subject: Re: Why Microsoft's Product Activation Stinks
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
=BEGIN PGP SIGNED MESSAGE=
On Fri, 26 Jan 2001, Richard Heathfield <[EMAIL PROTECTED]> wrote:
>Anthony Stephen Szopa wrote:
>>
>> Pointless program where to stop software piracy could increase
>> revenues by tens of billions of dollars each year? Pointless?
>
>Pretty much, yes. It's lik
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #12 Mon, 28 Aug 00 13:13:00 EDT
Contents:
Re: Stream Cipher ([EMAIL PROTECTED])
Re: PGP Bug: IMPORTANT Personal test report (Steven Markowitz)
Re: Additional fix to ADK bug (John Savard)
Re: PRNG Test Theory ("Tony T. Warnock")
Re: SHA-1 program (cool!) (Daniel Leonard)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: My (New) New algorithm ("Slava K.")
Re: UNIX Passwords (JCA)
Re: Fly ball in left field... (JCA)
Re: My (New) New algorithm ("Scott Fluhrer")
Blowfish question (and others) (Chris J/#6)
Re: Blowfish question (and others) (Kent Briggs)
Re: Blowfish question (and others) ([EMAIL PROTECTED])
Re: Blowfish question (and others) (David A Molnar)
ZixIt Mail ([EMAIL PROTECTED])
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher
Date: Mon, 28 Aug 2000 14:04:19 GMT
In article <8odpvs$4g5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi all!
>
> Stream Cipher using OTP and Random Number Generator approach.
> Delphi source code and executable can be download at
> www.alex-encryption.de
First off very unoriginal stuff, second off your site is a disgrace to
the profession. Your block ciphers are poorly documented and your
RSA/DES Null attacks are just plain wrong.
Arrg... read a book/posting or two would ya?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Steven Markowitz)
Crossposted-To: comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: 28 Aug 2000 14:00:48 GMT
In article <8o5kqk$mls$[EMAIL PROTECTED]> "Michel Bouissou" <[EMAIL PROTECTED]>
writes:
[ snip ]
>==> IMPORTANT NOTE:
>THIS IS MOST IMPORTANT. Reading carefully Ralf's paper, the ADK public key
>seems NOT to be actually included in public keys that mention mandatory use
>of this ADK. YOU MUST HAVE THE ADK public key as well. Only the ADK's key ID
>is included in the key that holds and ADK, which is not enough to allow
>encryption to the ADK by itself.
If the public key contains only the key id of the ADK, then isn't that a
serious security flaw? My understanding is that it is possible for an
attacker to create a new key having the same key id as an existing key,
although the fingerprints will differ. I have read that this can be done
for RSA keys; I'm not sure about DH/DSS keys. This would allow an
attacker to cause messages to be encrypted to himself, instead of to the
intended ADK, as long as the sender had the attacker's ADK on his
keyring.
This attack would apply even if the recipient's key had not been tampered
with. It seems to me that in order for the ADK mechanism to be secure,
the signed portion of a key would have to include the key id, length, and
key fingerprint of the ADK.
Am I misuderstanding something, or is the current ADK setup inherently
insecure?
Steven Markowitz
--
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the
views of D. E. Shaw & Co., L.P. or any of its affiliates.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Additional fix to ADK bug
Date: Mon, 28 Aug 2000 14:09:38 GMT
On Mon, 28 Aug 2000 13:58:03 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Essentially, a sender ADK is one imposed by the sender's employer or
>government, and a recipient ADK is one imposed by the recipient's
>employer or government. Distinguishing them, by ensuring that all ADKs
>obtained from a version of the recipient's key block are labelled as
>recipient ADKs,
Of course, it would be trivial for a man-in-the-middle to alter
messages to change this labelling. That could be avoided without
sending signatures to the individual keys; one could have the sender
sign the list of ADKs.
But even without such a precaution, this would still have a benefit,
since although attacks using the ADK bug are a kind of
man-in-the-middle attack, they are easier than a real MITM attack,
because they only require uploading a bad certificate once, and can be
used by attackers who don't have the capability of mounting a true
MITM attack.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Mon, 28 Aug 2000 20:35:51 -0600
Reply-To: [EMAIL PROTECTED]
Kolmogorov (of course) has an article about this. I don't know the
reference, but it's in Knuth's volume II. Kolmogorov discusses the
number of bit strings of a given length that pass a certain number of
tests. It's in the Indian Statistics Journal, (Sankhya or something
similar.) The i
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #11 Sun, 16 Apr 00 08:13:01 EDT
Contents:
Re: One Time Pads Redux (Jim Gillogly)
Re: Why is this algorithm insecure? (Newbie flamefodder) (Richard Heathfield)
Re: Why is this algorithm insecure? (Newbie flamefodder) (Richard Heathfield)
Re: Non-standard shift register sequences ("Peter L. Montgomery")
Re: Is AES necessary? (Bryan Olson)
Re: Miami Herald article about ATM ripoffs (Norman D. Megill)
Re: Miami Herald article about ATM ripoffs (Norman D. Megill)
Re: ? Backdoor in Microsoft web server ? [updated] (Francois Grieu)
Re: Q: Entropy (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: General principles of design (Mok-Kong Shen)
My STRONG data encryption algorithm ([EMAIL PROTECTED])
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: One Time Pads Redux
Date: Sun, 16 Apr 2000 05:14:59 +
Joaquim Southby wrote:
> A) Bob and Alice each have a RNG at their disposal. These do not need to
> be synchronized or even similar -- they just have to create numbers
> acceptably random for an OTP.
So far so good.
> B) Bob enciphers a message by XOR'ing the plaintext with numbers from his
> RNG; he keeps a temporary copy of the numbers he used for this message.
> He sends the enciphered message to Alice.
Mallet intercepts the message, and now has M XOR Rng[A].
> C) Alice repeats this process using her RNG and sends the result back to
> Bob.
Mallet intercepts the message M XOR Rng[A] XOR Rng[B] and XORs it
with the first message. He now has Rng[B].
> D) Bob uses his temporary copy of the numbers he used the first time,
> XOR'ing them with Alice's return message to remove his stuff from the
> mix. He sends the result to Alice.
Mallet intercepts the message M XOR Rng[B] and XORs it with Rng[B],
and reads M a little bit sooner than Alice.
> E) Alice uses her temporary copy to remove her encipherment and retrieve
> the original plaintext message.
Mallet acts on the information slightly before Alice does.
> F) Both of them destroy their temporary copies of their RNG numbers.
Mallet holds onto both of them in hopes of cracking the RNGs before
the next version of the protocol is developed.
> OTP's to multiple users. It seems so simple (other than the correlation
> of messages to RNG output) that there must be something wrong with it.
Good intuition.
--
Jim Gillogly
Hevensday, 26 Astron S.R. 2000, 05:08
12.19.7.2.6, 11 Cimi 9 Pop, First Lord of Night
--
Date: Sun, 16 Apr 2000 08:30:15 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
"NFN NMI L." wrote:
>
>
> 128-bit, maybe 256-bit keys are fine. The larger the key, the more unwieldy it
> is. If you don't care about large keys, just use an OTP!
Well, there's large and then there's infinite. ;-)
Thanks for your speedy reply.
>
> < Pick some number B with which that byte of the key is uniquely
> identified (I used a bunch of primes)
> Rotate the buffer left by B bits.
> Perform a Vigenere-style XOR of the key all the way along the buffer.>>
>
> So, you repeat this process Q times, where Q is the number of bytes in the key,
> and the first time, you rotate the plaintext by 2 bits, the second time, by 3
> bits, and the Qth time by P[Q] bits?
Er, no - my description was less fastidious than my source code, I'm
afraid. Actually it's P[K[n]] where n is the byte we're on, in the range
0 to N - 1 (if the key has N bytes).
And after each rotation you just XOR the
> value KEYKEYKEYKEY...KEY to the plaintext?
Yes.
> Obviously, you can just start with
> ...000 and then do this process, producing a really munged key, and then
> XOR that key with the plaintext (this is equivalent to your algorithm).
I'm not sure whether that's true, given the above correction (which
stems from my poor explanation).
> This
> algorithm obviously fails horrendously for keys that are all 0's. What if your
> key is one byte: 01101100, say? See how little your algorithm can munge this
> key: rotating it by 3 bits is the same as rotating it by 11 bits.
Actually, whilst an 8-bit key is naturally a weakness, it would still
mung a reasonable amount, I think:
plaintext 0010 00111011 10011011
key01101100
So we start off by rotating by P[K[0]] - in my example source code I
used primes, and this byte of the key, 01101100 (108) gives us P[108]
which is 571. So we're going to rotate the buffer left by 571 bits.
Clearly, with a ciphertext of only 24 bits, there's no point in 571: we
can use 571 % 24 (which turns out to be 19. We would therefore take 19
bits o
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #10 Fri, 12 Nov 99 15:13:02 EST
Contents:
Re: Intelligence System Behavior Newsletters - few additional ones ("Markku J.
Saarelainen")
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.ukrainian,soc.culture.europe,alt.security,soc.culture.soviet
Subject: Re: Intelligence System Behavior Newsletters - few additional ones
Date: Fri, 12 Nov 1999 12:37:54 +
This is a multi-part message in MIME format.
==A22746DA99CF006A425B06D8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
==A22746DA99CF006A425B06D8
Content-Type: text/html; charset=us-ascii;
name="isbn1099.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="isbn1099.htm"
Intelligence Systems Behavior Newsletter
Copyright 1999 Markku J. Saarelainen
INTELLIGENCE SYSTEMS BEHAVIOR NEWSLETTER
October, 1999
by
Markku J. Saarelainen
Competitive Intelligence (CI), Business Ethics and Economic Espionage
Act (EEA) of 1996
One of the main differences between ethics and law is that ethics vary
from one person to another and the interpretations of laws should remain
exactly same regardless of a person. How facts are presented, when cases
are established and whether these facts are correct or incorrect, these
differ from one lawyer to another.
To understand all legal concepts and frameworks it is essential to read
trade secret and some other intellectual property laws and regulations
in all regions, where you conduct your business. There are also some international
treaties that may be quite relevant for the study - these may also be applicable
in some computer security cases. You may also want to visit some sites
of the professional CI societies and other similar organizations. Just
using a search engine you can actually find many URLs with varying intelligence.
(NOTE: Your query information may be used for some commercial purposes
- be aware of this).
If you like to read any EEA related cases, you may find some on the
Internet, in some law libraries and newspaper articles. Sometimes these
cases may be pure public relations and propaganda activities targeting
certain companies and enterprises by certain interest groups. (In fact,
there have been some interesting cases, where locals in the U.S.A. have
been very deceitful to their international managers and ownerships for
the benefit of local investments ---> actually international management
may use the EEA to fight against these deceitful behaviors.) In addition,
many law schools may have some good information at their sites. To find
any discussions relating to the EEA's regulatory process prior to is becoming
a part of a tangled subject-matter legislation, you may want to search
the Federal Register and/or any other relevant congressional records. You
may also visit the Whitehouse's archieves and other .gov sites. However,
often some documents are providing clearly a one-sided view, but if you
can use a simple method: "Turn your YESes to NOs, and your NOs to YESes",
you can learn some other points of views and conclusions hidden between
some lines.
However, the EEA and related issues can be viewed in many different
ways. National law enforcement agencies tend to have their own views for
allocating their resources to specific activities in certain subject matter
areas. Sometimes their counter-intelligence activities may just be offensive
and hostile activities against certain commercial interests. Corporate
security personnel have their own approaches and not necessarily dependent
on any CI professionals and/or law enforcement agencies. Competitive intelligence
professionals have their views and are often confused about their roles,
their codes of ethics, if any, and their legal liabilities, if any. Then
there are those intelligence agencies such as the C.I.A., N.S.A. and certain
unspecified agencies who really do not care about any ethics or any legislations
- they just steal and steal. And finally there are lawyers who have their
views and interpretations. Personally, I have found lawyers' interpretations
and points of views most beneficial and helpful.
There is one good seminar proceeding from the SCIP's (Society for Competitive
Intelligence Professionals) conference: "Trade Secret Law, The EEA and
CI", Chicago, 1998 - CI-803. This session addresses many legal aspects
of the EEA, trade secret laws in general and how they are often misinterpreted.
In general, most CI professionals many have extreme misunderstandings and
may not be qualified to interpret existing legislation and law. The presentation
also addresses many legal and ethics issues. In practice, many EEA threats
and public advices by some SCIP members
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #9 Mon, 17 May 99 05:13:04 EDT
Contents:
Re: Mandlebrot transform ([EMAIL PROTECTED])
Computer-generated random numbers (was Re: Magic) ("Riboflavin")
Re: Security ([EMAIL PROTECTED])
Can Somebody Verify My DES execution? ("Zulkifli Hamzah")
Re: Security (David A Molnar)
Re: On Contextual Strength (wtshaw)
Re: On Contextual Strength ([EMAIL PROTECTED])
Re: Security (wtshaw)
Computer-generated random numbers (was Re: Magic) (Frank Palmer)
From: [EMAIL PROTECTED]
Subject: Re: Mandlebrot transform
Date: Mon, 17 May 1999 01:16:16 GMT
> The Mandelbrot transform transforms a complex number a + bi into
> c= (a+bi)^2 + (d+ei)
>
> The number of iterations repeated when c is transformed by the same
procedure
> without having the tranformed point "leave the room" is the height of
the
> fractal at the point a + bi.
This 'c' value is the output (usually the color) right?
Since you can zoom any point of a mandelbrot to form another mandelbrot
(MB for short), this transformation is discrete. If you map a 2d plane
(dimensions X by Y) over a MB when z=1 you will have X * Y points to
use, you could also modify z such that X and Y are not known. The
complexity would be limited by the range of z and your other
calculations only.
Also there must be a equal number of outputs 'c' which are equal
probable. I don't think that's the case in a MB which may make it less
usefull.
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
From: "Riboflavin" <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.science
Subject: Computer-generated random numbers (was Re: Magic)
Date: Sun, 16 May 1999 21:10:56 -0400
[crossposted to sci.crypt]
Frank Palmer wrote in message <7hmo5v$qeq$[EMAIL PROTECTED]>...
>: [EMAIL PROTECTED] (Frank Palmer) writes:
>: > Start with text, rotate each byte, XOR with the next byte;
>: > repeat nine times. Result, random bytes.
>: >
>"Random byte" simply means that the preceding bytes provide no way of
guessing
>which byte will come next. Each byte provides 8 bits of information.
>
>All the text need do is contain information for this system to work after
some
>number of repetitions. English text generally contains 1 bit of
information
>per letter. I used 10 letters to provide some margin.
>It wouldn't work for pages of the letter, A; it would work for normal
English
>text.
No, this would not produce random numbers (unless you perform your XORs an
infinite number of times). The numbers might look random to a casual glance,
but would have certain patterns that would make any crypto based off of them
much easier to crack. I crossposted this to sci.crypt, I think one of the
experts there can do a better job of explaining why this is so than I can.
--
Kevin Allegood [EMAIL PROTECTED]
Remove the pants from my email address to reply
"If you can put this postmodernist gibberish to music, I'll dance to it."
-Cleve on some leftist blathering
--
From: [EMAIL PROTECTED]
Subject: Re: Security
Date: Mon, 17 May 1999 01:10:17 GMT
> Of course, that would need to be proved. Such proofs are quite rare.
>
I conjecture that such proofs are impossible. Since there can exist a
algorithm to solve a AES (which would be??) message faster then brute
force. However the actual effort/plaintext/memory required will most
likely make such attacks infeasible or useless (you could just steal
the information physically).
Large keys used properly are good to avoid brute force, however the
underline algorithm must be secure.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
From: "Zulkifli Hamzah" <[EMAIL PROTECTED]>
Subject: Can Somebody Verify My DES execution?
Date: Mon, 17 May 1999 10:11:09 +0800
Reply-To: "Zulkifli Hamzah" <[EMAIL PROTECTED]>
Hi Forum,
I'm newbie to encryption software development (and newbie to this
group either) but ...
I've made a simple program implementing stadard DES as described in
Cryptography and Network Security by William Stallings, using exactly
same tables and s-boxes.
Here some output of my program (spaced manually for readability), using
the same key input with 3 plaintext inputs each differ by 1 bit. (The book
gives some output reference for SDES, but not much on
