Cryptography-Digest Digest #211, Volume #14      Sun, 22 Apr 01 22:13:01 EDT

Contents:
  Re: Note on combining PRNGs with the method of Wichmann and Hill (Bryan Olson)
  Re: Can this be done? (John Wasser)
  Re: Cryptanalysis Question: Determing The Algorithm? (wtshaw)
  Re: OTP WAS BROKEN!!! (Bryan Olson)
  Re: OTP WAS BROKEN!!! (Benjamin Johnston)
  Re: Censorship Threat at Information Hiding Workshop (wtshaw)
  Re: PK Algorithm Idea ("Michael Scott")
  Re: Cryptanalysis Question: Determing The Algorithm? ("Dramar Ankalle")
  Re: OTP WAS BROKEN!!! ("Scott Fluhrer")
  Re: OTP WAS BROKEN!!! ("Mark G Wolf")
  Re: research on polymorphic crypto/Best Possible Privacy? ("Mark G Wolf")
  Re: OTP WAS BROKEN!!! (newbie)
  Re: Cryptanalysis Question: Determing The Algorithm? ("Dramar Ankalle")
  Re: OTP WAS BROKEN!!! (Ben Cantrick)
  Request for comments, criticism, or suggestions ("Rickey Braddam")

----------------------------------------------------------------------------

From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Sun, 22 Apr 2001 17:05:41 -0700



Mok-Kong Shen wrote:
> 
> Bryan Olson wrote:
> >
> [snip]
> > You cannot justify a bogus result by restating it a
> > different form.  You've no evidence that one cannot break
> > your scheme if he cannot solve the corresponding problem
> > against Wichmann-Hill.
> [snip]
> 
> I think that you are too much theory-oriented (I am not
> against that).

Do you have some practical results?  Can you cite 
cryptographic uses of Wichmann-Hill that are flawed and show 
that your modification fixes the problem?  So far you've shown 
nothing, and since you lose desirable properties of WH, your 
method has less than nothing to recommend it.


> Wichmann and Hill (WH for short) has
> the effect of producing more uniformity with practically
> available not very uniform generators. That effect is
> non-perfect but tends (in general) to be better when the
> number of PRNGs increases. Now this effect is also
> dependent on the quality of the PRNGs themselves.
> If these are bad enough, then the result will also be
> quite poor. So with WH one is not doing any 'perfect' job
> anyway. Now given R1 = r1 + r2 mod 1, one achieves 'some'
> uniformity. The same holds for R2 = r3 + r4 mod 1,
> where I define r3 = c1*r1 and r4 = c2*r2. It is true
> that r3 and r4 would be non-uniform if r1 and r2 were
> perfectly uniform. But r1 and r2, being obtained in
> practice, are more or less non-uniform from the outset.
> r3 and r4 are in general worse PRNGs than the (also
> non-perfect) r1 and r2. How much worse evidently depends,
> among others, on the magnitude of c1 and c2. My opinion
> is that small enough deviations from 1.0 of c1 and c2
> would lead to deterioration of R2 (in comparison to R1)
> that is practically negligible.

Didn't you recently criticize someone's assertions saying 
"his results did not conform to common practice in 
statistics"? Is there any discipline that would accept the 
rambling nonsense above?

> Gladman strongly opposed
> to that, saying that even slight deviations from the
> original WH would give results that are 'very non-uniform'.
> Currently Gladman and I are discussing directly via E-mail
> to settle that issue, as I said in another follow-up. Now,
> even if it turns out that statistical tests show the
> 'practical negligibility', you certain could claim that
> that's not a 'proof' that is acceptable to you. You could
> say that the tests are not sufficient, etc. etc. and that
> these are empirical and not 'rigorous' in the sense of
> theory, etc. etc. Yes, one can certainly maintain a very
> strict theoretical spirit. But then please also consider
> the question e.g. whether AES has a 'rigorous' theoretical
> proof that it is unbreakable. (Anyway I am not aware
> of one.)

Your posts have nothing in common with a serious scientific 
endeavor such as AES.  Just because we cannot yet prove 
computational security is no excuse for posting made-up 
results.

 The multipliers c1, etc. are introduced to
> make the scheme (as such) of pseudo-random number
> generation somewhat more complicated, necessitating
> the opponent to spend some more effort to work around
> that.

Do you recall proposing introduction of a random permutation 
on words of a message between rounds of a cipher?  As I 
recall, your purpose was to introduce more variability and 
complexity. It turned out that in realistic cases, what you 
actually introduced was a defect that broke the cipher.  For 
that proposal too, you had a rambling, incoherent argument 
by which you claimed to show your modified scheme was at 
least as strong. Have you learned nothing?


--Bryan

------------------------------

Subject: Re: Can this be done?
From: John Wasser <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2001 00:12:42 GMT

In article <3ae2fb47$0$15029$[EMAIL PROTECTED]>, Mark Lomas
<[EMAIL PROTECTED]> wrote:

> "John Wasser" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > In article <3ae12b5e$0$15023$[EMAIL PROTECTED]>, Mark Lomas
> > <[EMAIL PROTECTED]> wrote:
> > >
> > >  how can bob tell whether Eve is duplicating Alice's messages or Alice 
>duplicating Eve's?
> > >
> >
> > He can't.  That was not a requirement.  
> >
>
> It may not have been stated explicitly, but it is requirement
> implied by use of the word 'source'.
> 
����  
If you look a the original message:

http://groups.google.com/groups?ic=1&q=msgid:987190067.12509.0.nnrp-07.9
[EMAIL PROTECTED] 

You will see that the the term "source" is never used.  In fact Bob is
apparently not supposed to know who is sending the messages: "The
result being: all the messages are proven to come from the same place,
despite that place remaining anonymous.".  

 Perhaps you should ask the original poster if they made a mistake in
not including a requirement that Bob be able to determine that the
source of the mesage was the expected source. I don't see how Bob could
determine that any messages came from any particular source since he
has no way of contacting the anonymous source ("the flow of data is
solely from Alice to Bob")  and no way to know  which anonymous source
to trust as the expected anonymous source.  He can only tell the
sources apart because they use different keys.  He can't even tell if a
man-in-the-middle attack is filtering one or more of the sources.

 I chose to believe that the requirements were correct as given.

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 22 Apr 2001 18:03:47 -0600

In article <9busiv$7m2$[EMAIL PROTECTED]>, "Dramar Ankalle"
<[EMAIL PROTECTED]> wrote:


> Well you write children say children instead of spoiled brats.You wanna know
> spoiled?I have, strangely enough, a black book of phone numbers from some
> ex-stripper girlfriends that have current policians in them, and their drugs
> of choice, and phone numbers.I think it is spoiled to turn around and punish
> youthful discretion, being a youthfull ``disc ressor" themselves.I mean,
> Navy Offers and Crystal meth in Long Beach?
> Whats that all about?
> 
> Spoiled in Whittier,
> 
>  A P O L L Y O N

Watch it, they will be after you now to shut you up or get the dirt on any
foes, perhaps both.  You obviously have missed what confidentiality means
when you say, "I've got a secret."

Everybody messes up, but if you are  a sworn member of the military or an
office holder, you had better been awfully young for a pass on bad
judgement.  Now, if this is true, what you say, it's necessary for you to
do something other that shoot you mouth off; that is not destruction of
evidence.
-- 
Nafta, etc.?  No way Jose.  

------------------------------

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Sun, 22 Apr 2001 17:20:27 -0700



nugatory wrote:

> So here's a challenge:  What is the shortest possible
> argument that will convince an intelligent layman
> that an OTP cannot broken (as long as the "one-time" part
> is honored)?

How about:
    All keys are equally probable, so the ciphertext and
    plaintext are independent.

An intelligent layman might have to look up "independent".


--Bryan

------------------------------

From: Benjamin Johnston <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Mon, 23 Apr 2001 10:26:51 +1000

> xxx
> xyz
> :a?
> izx
> ixz
> oqx
> etc...
>
> They are still enormous.


Your explanations are alway complex, confusing and difficult to follow. I
think that by paying too much attention to the process involved in your
"proofs", you haven't sat back and asked yourself, "What does this really
mean?... What am I really showing?".


What I believe you are describing is some method of producing a set of
candidate sentences, and nothing more.

If you recieve a one time pad encrypted message, it could theoretically
have been any plaintext... but if you assume the sender is a human, we
might guess it is a written language.

Your method will give us every "reasonable" plaintext, but it cannot
distinguish the correct one if it has been encrypted with one time pad.

Its not possible to obtain any information from a properly encrypted
one-time-pad cipher text (except, maybe, the length of the message).

Your procedure is equivalent to asking, "What do I think this sender may
have sent to the recipient"... if your method can decrypt a OTP message,
then it should be able to decrypt ANY message, even if you don't know
plaintext, ciphertext or key... even if the only thing you know is that
"a message has been sent".


Here's a simple example.

Lets say I want to email my friend one of;
yesyesyesyesyesyesyes   or
nonononononononononon

And after I encrypt with one time pad I get this ciphertext;
akjnalksdnckasjhdfklj


If I send that message, there is no way you can decide whether I have sent
yesyesyes... or nonono...

Even though you know EXACTLY what messages I'm going to send, even though
there are only two valid decryptions out of all possible decryptions...
you can never tell me which of the two possible messages I sent with
greater than 50% certainty.


-Benjamin Johnston
[EMAIL PROTECTED]


------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Sun, 22 Apr 2001 18:14:35 -0600

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:

> wtshaw wrote:
> > It is an attack on individuals who dare fight corporate greed and
> > corporate welfare.
> 
> Funny how pirates always find rationalizations like that.
> 
> If it hadn't been for rampant piracy, the music publishing industry
> would never have resorted to copy-protection in the first place.

Not being a music downloader and knowing people in the music business, I
still cannot take a side on that one.  Means of copy protection seem
always to be inadequate and may cause more problems than they considered
beforehand.  The old idea of what was publishing is obsolete for sure, as
in what technology gives, it can also nullify with other advances.
-- 
Nafta, etc.?  No way Jose.  

------------------------------

From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: PK Algorithm Idea
Date: Sun, 22 Apr 2001 19:51:54 -0500


"David Hopwood" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Tom St Denis wrote:
> > Has anyone considered a hybrid DH-RSA system?
>
> Yes, a system similar to the one you described (with some additional
> constraints) was proposed in:
>
>   K. S. McCurley,
>   "A key distribution system equivalent to factoring,"
>   Journal of Cryptology, 1 (1988), pp. 95-105.
>
> and proven as secure as the harder of finding discrete logs in GF(p)
> and GF(q), and factoring pq. Also see section 3.8 of HAC, and the
> following paper if you can find it:
>
>   Z. Schmuely,
>   "Composite Diffie-Hellman public key generating systems are hard
>    to break,"
>   Technical Report #356, TECHNION - Israel Institute of Technology,
>   Computer Science Department, 1985.
>
> I suspect that one reason why composite DH isn't commonly used, is that
> for taking discrete logs in p and q to be hard, p and q have to each be
> about as long as an RSA or DH modulus would be. So, in order for this
> to actually result in a cryptosystem that is at least as hard as
> factoring and taking discrete logs, the key length has to be doubled
> (and hence the encryption/decryption times are multiplied by 8, assuming
> full length exponents), relative to DH over GF(p).
>

Actually you can get around this problem using Lucas exponentiation as
outlined in

http://www.compapp.dcu.ie/CA_Working_Papers/wp98.html#0498


Mike Scott

> In other posts, you wrote:
> > Why not use the set of rationals (i.e a/b where a and b are int Z
> > and b != 0) in say DH?  Basically you pick g = a/b and perform DH
> > like normal but all your numbers are in a/b (except the exponent).
>
> and
>
> > You find a prime p (preferable a s.g prime)  Then you make up a RxR
> > matrix which is a generator in Zp^R space (somehow).  Then you perform
> > DH like normal using matrices.
>
> Both of these are no harder (up to a constant factor) than standard DH.
>
> - --
> 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
>
> iQEVAwUBOts3ozkCAxeYt5gVAQFxKgf/d0FYG77RnEqgsR1hVQkcydw6oO66RJfH
> T5XFdywF2igGOvAlpMZ1g/qwtE7MqSdxddp5uOg/gudkGgKG37I5Q7OKRf/VHyqh
> LKDiXzhQG7TM65OWfNN/PNBXNwy3yZZoSUhAAuFKaNPWsj870PAw5EY6PAwBwP1u
> CXL95ryCRhu00eVmACI71A1EQrOpQqwN1gAsWKxZMyy/IARQFgr6TB+HddGwWNUm
> CTmvY8wtq3hOx3C569ZbfOsf4yi0DNa9uIWPrSFA6XPhY5OWcl6gPELXYP8tT/Tm
> lrrIWwhsnKS+Snmd44/41ATBS4tMJd2N+Yuv2AHtX9vyo6Cv3ZrGCQ==
> =Cyqf
> -----END PGP SIGNATURE-----



------------------------------

From: "Dramar Ankalle" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 22 Apr 2001 21:24:36 -0400


wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <9busiv$7m2$[EMAIL PROTECTED]>, "Dramar Ankalle"
> <[EMAIL PROTECTED]> wrote:
>
>
> > Well you write children say children instead of spoiled brats.You wanna
know
> > spoiled?I have, strangely enough, a black book of phone numbers from
some
> > ex-stripper girlfriends that have current policians in them, and their
drugs
> > of choice, and phone numbers.I think it is spoiled to turn around and
punish
> > youthful discretion, being a youthfull ``disc ressor" themselves.I mean,
> > Navy Offers and Crystal meth in Long Beach?
> > Whats that all about?
> >
> > Spoiled in Whittier,
> >
> >  A P O L L Y O N
>
> Watch it, they will be after you now to shut you up or get the dirt on any
> foes, perhaps both.

Oh well.
They already tried in Clearwater.




  You obviously have missed what confidentiality means
> when you say, "I've got a secret."
>

Its not a secret any more.


> Everybody messes up, but if you are  a sworn member of the military or an
> office holder,

no


 you had better been awfully young for a pass on bad
> judgement.  Now, if this is true, what you say, it's necessary for you to
> do something other that shoot you mouth off; that is not destruction of
> evidence.
> --
> Nafta, etc.?  No way Jose.

Destruction of evidence?
heavens no, its sitting right here.

Buhbye.






------------------------------

From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Sun, 22 Apr 2001 18:16:50 -0700


newbie <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> OTP was broken!
> It is not a joke.

Obvious question: how would your scheme function if instead of getting a
encrypted message C, I gave it a random sequence of bits that is of the
right length?  Would it then be able to produce the same plaintext or not?

If it does produce the same plaintext, then how it is able to produce
correct plaintext in the absence of any information?  After all, an attacker
would be able to create a random string, and then proceed to use your
procedure to break it, without the bother of actually intercepting a
message, or for that matter, without the bother of the sender actually
sending one.

If it doesn't produce the same plaintext, then how is your procedure able to
distinguish between a random bit string xored with a message, and a random
bit string?

--
poncho





------------------------------

From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Sun, 22 Apr 2001 20:27:54 -0500

> It is based on the simulated re-use of OTP.
> If I reuse twice OTP you can break it for sure.

Sure if you reuse the whole same pad you can break it.  Really my previous
questions are very pertinent to the security of an OTP or stream cipher.
You really have to stop thinking of an OTP as a block of random bits and
start thinking of it as a stream.  The more random the stream and the more
diffuse the data your hiding is in that stream, the more difficult it is to
crack it.

I'd say more but... "there may be gold in them there hills!".  NSA spooks
probably recognize what I'm saying since confusion and diffusion are the
fundamental building blocks in cryptography.  The confusion is the
randomness of the stream, the diffusion is the message density within that
stream; after that it's only a question of computing power and mathematics.
Remember the whole idea is to transmit "useful" information as efficiently
and  as securely as possible.  Security is a direct trade off for
efficiency.  If I had a "large"  OTP I'd have to asses my adversaries
computing capabilities and use just as much of it to get the level of
security I felt necessary.  After my pad is used up, it's time for the
stereotypical courier with the handcuffed briefcase to make another trip.
Or is it?





------------------------------

From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: Sun, 22 Apr 2001 20:32:31 -0500

> I'm looking for research that anyone may have done regarding the product
> Best Possible Privacy.  The underlying technology is described as a
> polymorphic encryption scheme.   There is a description of the algorithm
> at www.identification.de/crypto/descript.html with a related site
> selling the product at www.ciphers.de/bpp.  I have searched for other
> references to either of these pages and found nothing so far.  I have
> read the snake oil faq and this seems to fall into that category but I
> am not an expert so I turn to those of you who are.

I hope your just a coincidence.  Absolutely not.  Thou doth protest too
much.




------------------------------

From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Sun, 22 Apr 2001 21:32:41 -0300

What it makes me angry is that no one has read carefully my proof.
Take the time to read carefully what I wrote and then you may ask me if
you need some precisions.
I know that my english is not fully correct.
But, please read my proof.


newbie wrote:
> 
> OTP was broken!
> It is not a joke.
> 
> Let encipher with truly random key a message M.
> M is a plaintext
> M =( M1 M2 M3 .... Mn)
> K is a Keystream
> K = ( K1 K2 K3......Kn)
> C is a Ciphertext
> C = ( C1 C2 C3 .... Cn)
> ___________________________
> 
> What I know before breaking is C.
> 
> What I could know using extra-information is the specific langugage used
> in my ciphertext
> Sample : military communication. If I know that I can still assign a
> high probability to occur to
> all the words and and sentences used by militaries in their mails.
> So I'm going to use a specific database to break my ciphertext.
> I'm going to show you that even I have not extra-information, it makes
> my breaking more difficult but not impossible.
> ___________________________
> 
> FIRST TEP
> 
> GOAL : selection of messages which have a "sense".
> 
> 1.1. I choose the size of the block that I have to break.
> 
> This choice depends on my power computation( it could be 32 bits or
> more)
> 
> Let the size of the block = 128 bits.
> 
> 1.2. So let suppose that my domain of messages that have a sense is PM.
> 
> PM = ( Pm1, Pm2, ..... Pms)
> S is the number of all possible messages.
> The size of every PM is = s = 128 bits.
> 
> If I try all 2^128 possible messages without any constraint, a large
> part of them have no sense.
> If I convert those bit-sequences to plaintext using i.e Ascii code, many
> output have no sense.
> What I mean by sense is not only semantic.
> Sample : the sequence-text  "ossi" has a sense because it is included in
> the word p...ossi..ble.
>               the text "xzyh" has no  sense because it is impossible to
> find an english word including the
>               the sequence-text "xzyh"
> 
> That means that only a low percentage of the 2^128 possible messages has
> a sense.
> 
> If my choice is right and correct, only one of my PMi is matching the
> message I'm trying to uncover.
> The domain of possible solution is then defined and listed.
> I  still do not know wich of PM(i) is the "right one".
> All are equiprobable. But I had limited the number of possible
> solutions.
> 
> 1.3. I sort my list of PM(i).
> 
> This sort operation has to be done according the position of the block
> in the plain-text. All the PM(i) which likely to be in the head of the
> plaintext are the first in the list. Sample (Dear, My dear etc...).
> The more likely to be in the head of the message will be the first one
> in the list.
> This operation will be repeated after each broken-block.
> 
> SECOND STEP :
> 
> This step if the core of the OTP breaking algo.
> 
> GOAL : finding the right message and breaking the ciphertext.
> 
> How could we do that?
> 
> 2.1  I choose the first PM(1) in the previous list (1.3)
> 
> 2.2. I compute Output 1  ( K'(i) =Ouput (i)  ).
> 
> K' (1) = PM(1)  Xor C(1)
> 
> 2.3 I choose a plaintext of 128 bits ( 16 letters ) that have a sense.
> 
> Choosen plaintext = CHP= "I am an amateur!"
> I can choose any plaintext of 128 bits that have a sense.
> I can use the same text in all my next operations.
> 
> 2.4. I compute a second "ciphertext"
> 
> C'(1) = K'(1) Xor CHP.
> 
> C'(1) will allow me to find the solution.
> 
> How it works?
> 
> The ciphertext analyzed is C1.
> 
> I have 2 equations :
> 
> C1 = M1 Xor K1                                          (1)
> 
> C'(1) = K'(1) Xor CHP                                   (2)
> 
> If I Xor C1 with C'(1) I will obtain
> 
> C1 Xor C'(1) = (M1 Xor K1) Xor (K'(1) Xor CHP)    (3)
> 
> I know C1, C'(1), K'(1) and CHP.
> 
> I do not know M1 and K1.
> 
> We have 2 cases :
> 
> First case :
> 
> Now let suppose that K1 = K'(1).
> 
> Hence K1 Xor K'(1) = 0000000....
> 
> C1 Xor C'(1) = M1 Xor CHP         (4)
> 
> I know C1, C'(1) and CHP. It is easy now to find M1.
> 
> C1 Xor C'(1) Xor CHP will give me a text that have NECESSARLY a sense
> which is M1. I found the right solution.
> 
> In this case K(1) NEUTRALIZE K1, the randomness disappear. And the
> equation is easily solved.
> 
> Second case :
> 
> K1 is different from k'(1). What it could happen in this case?
> 
> My equation will be
> 
> C1 Xor C'(1) = (M1 Xor K1) Xor (K'(1) Xor CHP)
>                   = (M1 Xor CHP) Xor (K1 Xor K'(1))
> 
> I know C1, CHP, K'(1).
> 
> I do not know M1 and K1.
> 
> But, knowing that K1 is a random key, K1 Xor K'(1) is necessarly random
> string.
> 
> K1 does not neutralize the randomness of K1.
> 
> The result is that
> 
> C1 Xor C'(1) Xor CHP = M1 Xor (K1 Xor k'(1)  will give me  a random
> string. If I convert this sequence string I will obtain
> 
> with a high probablity a text that have no sense.
> 
> Nevertheless, if  M1 Xor (K1 Xor K'(1)) is corresponding, when I convert
> it to plaintext, to a message which have a "sense" I have to select it.
> It is possible solution. Hence I have to select it for the time being.
> 
> THIRD STEP
> 
> GOAL : reducing the number of possible rearranging the listing of  PM(i)
> 
> 1. List the selected  valid messages (broken messages)
> 
> 2. Eliminate all PM(i) that are not useful for the breaking of the
> second block.
> 
> 3.  Go to the step 1.3 and repeat all the operations until the breaking
> of all the messages.
> ____________________________________________
> 
> The breaking strategy is based on the removing of randomness. That is
> the core of the strategy.
> This strategy may be used to break all stream ciphers even DS. And is
> valid only and only if the plaintext before encryption is DIRECTLY coded
> in known way (Ascii code or others ).
> This algo can be improved to be more efficient.
> I'm waiting for your comments.
> 
> Thank you.
> 
> Newbie

------------------------------

From: "Dramar Ankalle" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 22 Apr 2001 21:51:54 -0400


wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...<snip>

As an aside, you cant kill the truth.
I hope you realize that.

tanq = e"/e'

e* = e' - je"



------------------------------

From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: OTP WAS BROKEN!!!
Date: 22 Apr 2001 19:53:55 -0600

In article <[EMAIL PROTECTED]>,
newbie  <[EMAIL PROTECTED]> wrote:
>I'm not talking about random  or non random. You have just to read.
>Nothing more than that.You are inventing what I said.
> 
>I NEVER SAID THAT!!!!!!!!!!!!
>
>
>You say "well it looks non-random so it must be the solution".
>> You fail to recognize that the number of non-random plaintexts is
>> astronomical....
>
>THE NUMBER OF MESSAGES WHICH HAVE A SENSE IS INFINITESIMAL COMPARING TO
>THOSE WHICH DOES NOT HAVE A SENSE!!!!!!!!!!!!!!!!!!!

  Infinity squared is bigger than infinity, but it's still impossible
to pick the correct message out of an infinite number of equiprobable
choices.

  Must I rub your nose in your own stupidity by posting an OTP encrypted
messaged and then asking you to crack it?


          -Ben
-- 
Ben Cantrick ([EMAIL PROTECTED])        |   Yes, the AnimEigo BGC dubs still suck.
BGC Nukem:     http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs:  http://www.dim.com/~mackys/spamdogs
Advanced Supersonic Titanium Nazi Hell Creatures from beneath the hollow earth!

------------------------------

From: "Rickey Braddam" <[EMAIL PROTECTED]>
Subject: Request for comments, criticism, or suggestions
Date: Mon, 23 Apr 2001 02:04:35 GMT

I would like to use the sequence of operations described below to exchange
messages between two users, across the Internet. At present, I'm using
symmetric ciphers only, but plan to add public key methods in the future.

The system would use two keys, ciphers, and hashes. Users can select one of
fourteen ciphers for the Message cipher, and the same or a different one for
the Master cipher. They can select one of nine hashes for each of the
ciphers, and one of seven feedback modes for each. Defaults are Blowfish for
both ciphers, CBC with ciphertext stealing mode for both ciphers, and SHA-1
for the hash used with each cipher.

A Message Key would be generated which is maximal length for the message
cipher, and used with a randomly generated IV when the selected mode
requires an IV.

A Master Key would be generated from a user-entered passphrase by hashing
with a second selected hash, using password stretching as needed. The Master
Key would be made maximal length for the master cipher.

A digest would be calculated over the plaintext message using a commonly
available hash like SHA-1. The digest would be prepended to the plaintext
message and the result encrypted with the message key, giving ciphertext1.

The message key, IV, and date/time value would be concatenated in that order
and encrypted with the Master key, giving ciphertext2. Ciphertext 2 would
then have ciphertext1 appended to it, giving ciphertext3.

A second digest is calculated over the concatenation of the Master key and
ciphertext3.

Ciphertext3 is appended to the second digest, giving ciphermsg.

Ciphermsg is base64 encoded, giving the message which is transmitted to the
other party.

On reception, the message is base64 decoded and the digest verified. If the
digest does not verify correctly, the message is ignored. Further processing
recovers the original plaintext message and its digest is verified. If that
verification fails, the user is notified of a security compromise.

Both users must enter the same passphrase, and be using the same combination
of master and message ciphers, hashes, and feedback modes. These things must
be agreed upon in advance or communicated from one to the other using means
that meet their security requirements. Any one of the selectable parameters
being different, or the passphrase not being identical, will result in loss
of the message without notification to the receiving user.

Multiple users logged into the same server on the same channel (socket) can
be participating in group discussions using the same passphrase and
parameters or individual discussions using privately known passphrases
and/or parameters. Each will see only those messages for which the
passphrase and parameters are correct.

Well, what do you think?

Rick




------------------------------


** 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
******************************

Reply via email to