Cryptography-Digest Digest #852, Volume #9 Thu, 8 Jul 99 17:13:03 EDT
Contents:
Re: Stream Cipher != PRNG (John Savard)
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (Toby Kelsey)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (John Savard)
Re: somewhat optimization works... (PRNG code) (Terje Mathisen)
Re: Summary of 2 threads on legal ways of exporting strong crypto (wtshaw)
Re: Help With Key Algorithm For Software Unlock (david avery)
Re: Weakness of MLCG style encryption ([EMAIL PROTECTED])
Re: Weakness of MLCG style encryption (wtshaw)
Re: Properties of Chain Addition? (John Savard)
Re: Summary of 2 threads on legal ways of exporting strong crypto (wtshaw)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day ("Robert C.
Paulsen, Jr.")
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day ("Tony T. Warnock")
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Help With Key Algorithm For Software Unlock ([EMAIL PROTECTED])
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: Stream Cipher != PRNG ([EMAIL PROTECTED])
Re: Stream Cipher != PRNG ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Stream Cipher != PRNG
Date: Thu, 08 Jul 1999 19:14:05 GMT
[EMAIL PROTECTED] wrote, in part:
>For those without the book....
It should be noted that a number of chapters have been made available
in PDF format. Can you run Acrobat Reader on your computer? I've found
PDF documents more convenient to look at than PS ones.
However, I agree that your question could be answered directly, so I
have replied to your original posting.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
Date: Thu, 08 Jul 1999 18:48:34 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
However, if there are sufficient number of people who
> regularly encode their e-mails, whatever the nature of the contents
> may be, using a diversity of encryption algorithms (primitive as
> well as sophisticated ones) then the WWI will not have enough
resources
> to deal with that. If one only sends sensitive messages with
encryption
> and ordinary messages in the clear, then they can have a pretty good
> chance of success since they can concentrate their work on these low
> volume traffic. I am not sure that using steganographic techniques
that
> hide bits in pictures to send mails is a good counter measure to WWI,
> since that's quite resource intensive. If sending coded messages
> is allowed, why don't just do that? And, if one takes the trouble,
> one can employ an extremely secure encryption to defeat decryption.
The problem is most cryptographic packages are technical. Even PGP is
somewhat difficult for complete newbies to learn. And if you
just 'trust' the vendor you get snake oil (i.e totally unbreakable
magical code).
As long as their is snake oil to spread around people will assume
that's the best. Even if their code is trivial to break (or makes no
sense) people will trust it (for them their really is no standard of
cryptographic strength).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Toby Kelsey <[EMAIL PROTECTED]>
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Thu, 8 Jul 1999 19:09:03 +0100
In article <7lst5f$cts$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
>In theory the OTP is truly the only secure method.
Really?
I intercept your OTP encoded message, for which I know the plaintext to
be either "Yes" or "No". The ciphertext is 2 characters long......
So much for "theoretically unbreakable".
The OTP allows any same-length decrypted message to be equally likely,
but requires a key the same length as the message. You can devise
methods which have shorter keys and still allow many possible decrypted
messages. The OTP is only "simpler" and "more secure" because the
algorithmic complexity is hidden in the RNG and its testing. There is
less latitude for error in the encryption implementation, but more
reliance is placed on the quality of the RNG and the secure channel.
The bottom line is, I would not feel safer just knowing a OTP was being
used to encrypt my messages.
Cheers,
Toby
--
Toby Kelsey
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Thu, 08 Jul 1999 19:20:08 GMT
Toby Kelsey <[EMAIL PROTECTED]> wrote, in part:
>The OTP is only "simpler" and "more secure" because the
>algorithmic complexity is hidden in the RNG and its testing.
Since conventional ciphers need keys that can't be guessed, and since
such true RNGs as dice have proven their efficacy in centres such as
Monte Carlo and Las Vegas, I'm not sure that I can fully endorse this
statement.
(Of course, in a sense, it does raise a valid point. After all, the
tumbling of a die is merely a very complicated classical physical
process, to which a computer simulation could be equivalent...but
"hidden" is not really the word. One could say that dice are a
remarkably efficient special-purpose computer...)
Naturally, OTP-encoded messages must be padded so that their length
doesn't leak information, to address your other point.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: somewhat optimization works... (PRNG code)
Date: Thu, 08 Jul 1999 21:19:53 +0200
[EMAIL PROTECTED] wrote:
>
> Could someone please take a peak at my C++ file (arng.cpp) that I have
> posted on my website. I optimized the additive rngs to use a simpler
> index (which was suggested by another sci.cryptster). Basically the
> rngs work like this
>
> return state[x = ni[++x]] += state[y = ni[++y]];
>
> To keep the state design I subtracted one from all the initialization
> values of x and y.
>
> Could some please check to make sure that it still works the same
> (basically proof read the code). They are minor changes (but it's
> normally the minor stuff that becomes major.)
OK, I'll do some proof reading for you:
Your version will run at least one cycle slower/iteration because you
are using pre-increment of the indices, which means that you have two
additional load operations in the critical path.
Otherwise it should work just like your original code, except that all
accesses will be one item later.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Thu, 08 Jul 1999 13:57:47 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> ... I proposed a legal way of "exporting" strong crypto that
> doesn't involve using the plain paper loophole...
>
> simply make available a clear, cogent, and understandable description
> of your proposed cryptographic method. One that can be easily turned
> into program code by anyone with a moderate inclination to try.
>
This is highly desirable, for any algorithm. Some algorithms have rather
strange details that are hard to describe in loose terms. A good test of
adequateness is for the description such as you suggest to be proven
through independent implementation in a variety of programming languages.
If proven inadequate, then sufficient plaintext description needs be
added.
Being able to think clearly in algorithm and sourcecode terms does not
mean that you are a natural wordsmith. I for one would plead for patience
with those who try to put forth best descriptions, and plead for
initiative in programmers to pursue such tasks until they are really
completed.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (david avery)
Subject: Re: Help With Key Algorithm For Software Unlock
Date: 8 Jul 1999 19:17:40 GMT
In message <[EMAIL PROTECTED]> - [EMAIL PROTECTED]
(CanoeDad) writes:
:>
:>I definitely don't trust lawyers to pay for software that they are
:>using. They are the most cynical of any customer base you can have.
:>The software is not shareware but demo ware. After a number of uses
:>they will be urged to pay for it, that's all. If they don't want to
:>then the uninstall option will be present for them to use.
:>
you might try the approach some people use make the "demoware" time or usage
locked and if they pay for it send a completely different version on paymant
that is unrestricted
this mean you would have to make 2 builds , but there is no hacking potential
Dave Avery
[EMAIL PROTECTED]
United Airlines Simulator Support
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Weakness of MLCG style encryption
Date: Thu, 08 Jul 1999 17:50:08 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Single LCPRNGs are easy to break, also the ones using truncated
> output, see works by Boyar and others. But you can use a number
> of LCPNGs and let these be activated in a (pseudo-)random order.
> Nobody has yet attempted to analyze such a scheme. By using a large
> number of constituent generators, the period of the output can be
> rendered very large and the difficulty of analysis obviously also
> increases. Code of a compound generator based on constituent LCPRNGs
> is available at:
>
> http://www.stud.uni-muenchen.de/~mok-kong.shen/#paper9
I will check it out. Some comments about the posting though.
Why use LC generators? They are slower then additive generators and
are more preditcable (although you can solve additive generators).
Also what you are talking about is really similar to Algorithm M.
Basically you want to throw the order of the output off.
I implemented a variation in my C++ code (called DDARNG) if you want to
toy with it. It seems to work quite well.
The benefit of Algorithm M over what you described is you really only
need one generator (although it has a longer period with two).
Implementing 256 generators will be costly in ram (not really in
code). If each generator takes 4 bytes (32-bit words) you are using
1KB of ram... In my scheme (DDARNG) i use about 370 bytes of ram.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: sci.math
Subject: Re: Weakness of MLCG style encryption
Date: Thu, 08 Jul 1999 14:26:51 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Logically it goes like this: An LCG has a very small amount of state.
> Examining some of the key stream gives plenty of information about past
> states. Once a complete previous state is known, all future states are
> known. The key stream can be obtained from a known plaintext. Many
> message formats have invariant sections that will reveal portions of the
> key stream.
For simple algorithms, what you say is certainly true, but one need not
proceed is such a simplistic manner at all. An LCG can be throughly
masked, making recovery of any of the series almost impossible to recover.
And, an LCG can be reseeded, perhaps making the initial states of all
series need be recovered before any can be used to solve a message.
>
> Also, the period is not the critical factor. The small amout of state
> corresponds to a small key. A small key can be broken with no analysis
> by brute force testing of every possible initial state (key). With some
> analysis or a bit of the keystream brute force is not necessary.
LCG's seems by their own nature to cry to use them in stream ciphers,
which is not their only use.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Properties of Chain Addition?
Date: Thu, 08 Jul 1999 19:11:40 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>I fell into a typo in a
>popular book about cryptography.
I see it's already in the errata, although he corrects the error by
shifting the exponents one over instead of by reversing the direction.
(The reversal propery allows a choice.)
However, it's one of the few errors still in the fifth printing of the
second edition.
>On my web site, at
>http://members.xoom.com/quadibloc/co041101.htm
>the page now has added, at the beginning, a bit more information on
>the properties of shift registers, and the proper direction in which
>to assign the terms of the characteristic polynomial to the cells of a
>shift register is illustrated - with an explanation of why it has to
>be that way.
Print it out and paste it in your copy?
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Thu, 08 Jul 1999 14:07:58 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> That the approach is legal is in my humble view beyond question,
> given the experience and knowledge potential available at RSA.
> As I said, this is very inconvenient for the author, there being no
> software for automatically converting an ARBITRARY program in
> C or other programming languages to natural language descriptions
> (at least as far as availability in the public is concerned).
> For the reader, who has to convert the natural language descriptions
> into code and, moreover, debug the program, the inconvenience is even
> higher. Anyone can see how inconvenient that is by doing an excercise
> on a toy algorithm.
>
It is *inconvenient* to have to write any code. It is *inconvenient* to
fight pitched battles with government bureaucracies. It is *inconvenient*
to bother with security at all. Being *inconvenient* only means that only
a few or one might choose to work through the details of doing something.
I suppose that to write a program of the sort is to start with something
simple, not even in the crypto line. Surely, you would be simulating the
advice on how to do something that a text or tudor might give you on the
same particuliars. One real requirement is that the advice be conclusive,
definitive, and complete; I don't know about you, but that is how I like
help to come anyway.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: "Robert C. Paulsen, Jr." <[EMAIL PROTECTED]>
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Thu, 08 Jul 1999 15:01:17 -0500
John Savard wrote:
<clip>
> (Of course, in a sense, it does raise a valid point. After all, the
> tumbling of a die is merely a very complicated classical physical
> process, to which a computer simulation could be equivalent...but
> "hidden" is not really the word. One could say that dice are a
> remarkably efficient special-purpose computer...)
The rolling of dice may have a deeper randomness. I think they are
subject to both chaos theory (a pseudo randomness) and quantum
randomness (a true randomness).
Chaos theory says that even though a process can be completely
deterministic (and therefore not random) it can be so dependent on
initial conditions that it is "random" in practice (e.g. the
flapping of a butterfly's wing affecting the weather a continent
away). This would not be enough to say that rolling dice gave true
randomness.
But the next thing to consider is that the tiny degree to which
quantum randomness affects the initial conditions may be enough so
that the quantum randomness is magnified to be the primary factor
in the results. (These "initial" conditions get applied at every
bump and bounce the dice take.)
Just a thought.
--
____________________________________________________________________
Robert Paulsen http://paulsen.home.texas.net
If my return address contains "ZAP." please remove it. Sorry for the
inconvenience but the unsolicited email is getting out of control.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Date: Thu, 08 Jul 1999 14:32:10 -0600
Reply-To: [EMAIL PROTECTED]
Toby Kelsey wrote:
> In article <7lst5f$cts$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
> >In theory the OTP is truly the only secure method.
>
> Really?
>
> I intercept your OTP encoded message, for which I know the plaintext to
> be either "Yes" or "No". The ciphertext is 2 characters long......
>
> So much for "theoretically unbreakable".
>
> The OTP allows any same-length decrypted message to be equally likely,
> but requires a key the same length as the message. You can devise
> methods which have shorter keys and still allow many possible decrypted
> messages. The OTP is only "simpler" and "more secure" because the
> algorithmic complexity is hidden in the RNG and its testing. There is
> less latitude for error in the encryption implementation, but more
> reliance is placed on the quality of the RNG and the secure channel.
>
> The bottom line is, I would not feel safer just knowing a OTP was being
> used to encrypt my messages.
Of course the Soviet spies used a super-encypherenment with a OTP during
(and prior to) WWII. The Venona project broke them anyway.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
Date: Thu, 08 Jul 1999 19:44:47 GMT
In article <7m2o42$i15$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Government is not reason. Government is force. -- George
Washington
> >
>
> Here is a relevant question. How many u.s citizens actually want
> crypto control? It seems people are in favor of envelops on snail
> mail, why would they be against crypto on email? Do these same people
> want the government to read their letters to grandma?
>
> Hmm, it seems that most governments (espescially canadian and us) have
> a hard time trying to figure out what the people really want.
>
> In that A&E special they said about 75% of all u.s citizens believe in
> gun control, yet their is still no functional laws about it. This is
> ot, but it's kinda the reverse of the crypto situation.
People don't seem to believe in the Constitution anymore. The idea that
the government can supress certain common information or technology
that it deems "sensitive" is ludicrous.
>
> One last question, how does controlling export of crypto technology or
> it's use stop a criminal from using it? Really I mean if a criminal
> can program in C they can write their OWN programs to use a relatively
> strong algorithm. It's not productive.
Government works by intimidation. Laws, in and of themselves, don't
prevent anything. They never have and they never will. Compliance is
voluntary with the understanding that getting caught will have possible
repercussions.
The information is freely available and enforcing a ban on technology
is next to impossible in this day and age.
>
> Anyways my two cents. I just thought it's interesting their is no
laws
> against stengagraphy (spelling?) but there are against cryptography...
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
Date: Thu, 08 Jul 1999 20:43:56 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > This coding thing is good for for the security of the
> > implementation or is just a coding convention??
Tom St Denis's code is not a good example.
> Well for cleaness and optimizations. Most compilers can optimize
lines
> of code if they are companded.
Today, most optimizing compilers will produce the
same code either way.
> i.e take part of RC4
>
> ---
> x = (x + 1) & 255
> y = y + state[x]
> ---
>
> Can be written as
>
> ---
> y += state[x = (x + 1) & 255]
But definitely not as
y += state[x++];
which is what Tom used in his C++ code. If the
increment of x were a separate statement, it would
not matter that it's a post-increment where RC4
requires a pre-increment. Tom's also assuming
(without comment) that unsigned char holds only the
values 0 through 255. ANSI/ISO C requires it to
hold at least that range of values.
> In fact RC4 can be written in about 3 or so lines of code. This makes
> the code faster on most machines and more compact on microcontrollers.
> It makes it harder to read as well.
Tom has now given us two implementations of the
simple RC4 algorithm, both of them wrong. He had
an example implementation code to work from, so it
seems that both bugs were the result of his
attempts at optimization.
> Take a look a my PRNG C++ file, you will notice that the stepping of
> the PRNGs look like
>
> ---
> return state[x = ni[++x]] += state[y = ni[++y]];
> ---
Terrible code. Much better is,
x = ni[x+1];
y = ni[y+1];
state[x] += state[y];
return state[x];
> Everything should be in the accumulator as required (i.e MCU
> friendly). Most compilers can optimize code like this better then if
> it were done in 3 or so lines...
Keeping recently used values handy is among the
first optimizations compiler authors implement.
Optimizing away the side effect in the ++x and ++y
is less common. A decent compiler will do both,
but why code a useless side effect? It's one
possibly valuable feature is that it makes the
reader suspicious of the code's correctness.
> For security reasons you want to avoid putting round keys on stack
(i.e
> auto/locals).
Nonsense. Static storage and the heap are at least
as bad as the stack.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help With Key Algorithm For Software Unlock
Date: Thu, 08 Jul 1999 20:40:57 GMT
In article <7m0k8h$bth$[EMAIL PROTECTED]>,
"Steve" <[EMAIL PROTECTED]> wrote:
> I've got the Schneier book "Applied Cryptography" and I'm trying to
devise a
> method for preventing unauthorized copies of my software to be made.
Once
> the user hits a usage metric, the software will stop until the user
> registers. Upon registry the user will get a key. The key will be
somehow
> verified by the program and the user will be free to continue using
it. If
> the user moves the software to another box then it will immediately
notice
> that the key is not present in the windows registry and stop working.
>
> I am thinking of using some form of signature algorithm for this but
my
> question is whether there is a standard method for doing this sort of
thing.
> If it is in "Applied Cryptography" then I'd love to know where.
What you can do is when the software is installed it an time stamp and
sign the file. When the software starts it can simply check the
signature with it's internal key (the installer has the other key).
This is not totally safe but it keeps most hackers from phreaking the
time stamp file. Of course if you have the patient you can hack thru
the program and find the file. Then right a program to phreak it, but
going thru all this you might as well pay for the program.
WSFTP does this and I bet many others as well. It keeps almost all
users at bay.
Another step to help security is to store the key in a weird format
that the attacker might not suspect. You could embed it in your logo
or store among other data. Basically stenogagraphy (damn spelling!)
will help as well..
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
Date: Thu, 08 Jul 1999 20:01:39 GMT
In article <7m2v3b$l80$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> People don't seem to believe in the Constitution anymore. The idea
that
> the government can supress certain common information or technology
> that it deems "sensitive" is ludicrous.
Cuz where does the government stop?
> Government works by intimidation. Laws, in and of themselves, don't
> prevent anything. They never have and they never will. Compliance is
> voluntary with the understanding that getting caught will have
possible
> repercussions.
>
> The information is freely available and enforcing a ban on technology
> is next to impossible in this day and age.
Yeah but encrypting messages is not illegal. It doesn't hurt anyone,
in fact it is suppose to give a sense of security.
Ideally one would not have to use cryptography to ensure that prying
eyes are away, but that doesn't always happen and you get things like
PEM and PGP. They want to make PGP illegal, why? You cannot open mail
(snail) without a warrant, why should it be easier to read email?
If you get a warrant I think you should get access to the persons PGP
private key (or whatever they are using). This would make sense.
Things like the clipper chip means that an attacker can read the
messages AT ANY time, which is not the same.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher != PRNG
Date: Thu, 08 Jul 1999 20:04:00 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Several chapters of the Handbook can be downloaded. I am not sure
> at the moment whether these chapters contain the materials you need.
>
Silly me, I have that chapter (CHAP 6: Stream Ciphers). BTW they talk
about LFSRs and SEAL in that chapter. So let me ask again, are stream
ciphers PRNGs or not?
(looking for confirmation, I already have my own thoughts on the
matter).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher != PRNG
Date: Thu, 08 Jul 1999 20:09:51 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] wrote, in part:
>
> >In a private email I was told that stream ciphers and PRNGs are
> >completely different beasts. Am I missing something? I always
thought
> >Stream ciphers were PRNGs which are difficult to solve (i.e
> >intractable).
>
> Well, most of the stream ciphers you will read about in Applied
> Cryptography are exactly that.
>
> Here are two kinds of ciphers:
>
> a) The plaintext is taken in blocks of 64 or 128 bits, and enciphered
> by a method that doesn't change from block to block, but is always the
> same for every block enciphered with a given key.
>
> b) The plaintext is taken bit by bit, and each bit either stays the
> same or is inverted, as determined in a way that changes from bit to
> bit in a complicated fashion.
>
> (a) is a block cipher, and (b) is the kind of stream cipher you're
> talking about.
>
> But there are other kinds of cipher which are in between (a) and (b),
> and they're usually also called stream ciphers (although some are also
> called special modes - other than ECB, electronic codebook mode - of
> block ciphers).
>
(a) is a permutation of the input
(b) is a state (the state is time based) permutation of the input. The
state changes with time meaning the permutations are not fixed
(although they do repeat).
> For example, the plaintext can be taken in chunks of eight bits, and
> the fate of each byte in the plaintext can change from byte to byte,
> perhaps with more than 256 possibilities for the rule to be applied to
> each byte. For example, a rotor machine, which might produce
> 26*26*26*26*26 different alphabets with five movable rotors, produces
> a stream cipher applied to letters.
Well you mean a LFSR which is block into 8 bits is a block cipher?
That is not correct. A block cipher is a key-dependant permutation and
that is that.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
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
******************************
