Cryptography-Digest Digest #793, Volume #12      Thu, 28 Sep 00 21:13:00 EDT

Contents:
  Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - the first I 
thought also becoming crazy, but realized that my logic and reasoning was 100 % 
accurate and based on clear facts and observations .... here are some other specifics 
... (William A. Nelson)
  Re: On-line Turing test? (David A Molnar)
  Re: Adobe Acrobat -- How Secure? ("David C. Barber")
  Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
  Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - just 
interested if this microwave attack was due to my massive communications on specific 
cryptography and encryption issues starting in the mid of 1999 .... (William A. Nelson)
  Blowfish Key length C code issue ([EMAIL PROTECTED])
  Re: Josh MacDonald's library for adaptive Huffman encoding (Mok-Kong Shen)
  Re: Adobe Acrobat -- How Secure? ("David C. Barber")
  Re: Deadline for AES... (John Savard)
  Re: Question on biases in random-numbers & decompression (Benjamin Goldberg)
  Re: Tying Up Loose Ends - Correction (Benjamin Goldberg)
  Yet another LFSR idea. (Benjamin Goldberg)
  another AONT idea (Benjamin Goldberg)
  Re: RSA T-shirt (Benjamin Goldberg)

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

From: William A. Nelson <[EMAIL PROTECTED]>
Crossposted-To: soc.culture.iranian,soc.culture.soviet,sci.physics
Subject: Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - the 
first I thought also becoming crazy, but realized that my logic and reasoning was 100 
% accurate and based on clear facts and observations .... here are some other 
specifics ...
Date: Thu, 28 Sep 2000 23:14:04 GMT




Some facts ....

1. Already in early 1960īs scientist discover that some audio and words
can be heard by humans when microwaves are used without any additional
devices.

2. Extensive research and publications written in 1970īs on auditory
perception and microwaves.

3. Pulse-modulated microwaves produce perceptible acoustic sensations
in man and other mammals, even  in subjects with impaired hearing.

4. A study suggest a direct interaction between the neuron and the
electric field.

5. The EEG of the cat demonstrates considerable similarities between
evoked potentials produced by simple acoustic stimulations and by
specific microwaves.

6. The Soviets were the first to envison the possibility of a low-
level, non-thermal mechanism affecting the cardiac rythm.....

And few links ....

http://www.brooks.af.mil/AFRL/HED/hedr/hedr.html

http://www.brooks.af.mil/AFRL/HED/hedr/dosimetry.html

http://www.brooks.af.mil/AFRL/HED/hedr/reports/home.html

http://www.brooks.af.mil/AFRL/HED/hedr/reports/dielectric/home.html

http://www.brooks.af.mil/AFRL/

I am sure you can find more details. Also heard that somebody had some
good Soviet studies on this subject matter.



Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: On-line Turing test?
Date: 28 Sep 2000 23:11:18 GMT

John Myre <[EMAIL PROTECTED]> wrote:


> Are we guinea pigs in an experiment?

"I am Baphomet. Perhaps you have heard of me?" 

Interesting idea. I wonder how many interactions we'd need to establish it
one way or the other. Maybe we can use notions of "computationally
indistinguishable ensembles" to define some kind of security notions for
newsgroup-posting-bots...

-David

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

From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Thu, 28 Sep 2000 16:29:56 -0700

Thanks. That worked better than my previous attempt.

    *David*

"Mark Carroll" <[EMAIL PROTECTED]> wrote in message
news:8r0gbj$8rk$[EMAIL PROTECTED]...
> In article <8r0e0c$2dn7$[EMAIL PROTECTED]>,
> David C. Barber <[EMAIL PROTECTED]> wrote:
> >Where would this documentation be found?
> (snip)
>
> How hard did you look? I just typed 'portable document format
> specification' into Google and got some useful links on the first
> page.
>
> -- Mark



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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Fri, 29 Sep 2000 01:50:08 +0200



Bryan Olson wrote:
> 
[snip]
> I assumed the attacker could get the same permutation in
> different messages.  Your only specific suggestion of how
> the PRNG is seeded divided the message in half and used each
> half to determine the permutation for the other, which is
> obviously repeatable in a chosen plaintext attack.  If the
> attacker cannot re-start the PRNG, then choosing all blocks
> of x the same, except the block that differs from x', looks
> like a promising tactic.

In my original post, I first said of using a PRNG, 
which I intend not to reseed (see answer to Tom St. Denis), 
i.e. the permutations are different for different messages. 
That would pose some difficulty to attack, if I correctly
understand what you wrote above. But I also mentioned 
using one half of the result of the previous cycle to 
permute the other half and vice versa as an alternative 
means of doing the permutation. This alternative is 
certainly poor under your chosen plaintext attack.

Perhaps I may ask a global question that has interested me
from the start, for I doubt that the answer is yet very 
clear to me owing to the not too small volume of texts of 
debate involved in a number of follow-ups: In your opinion 
does my introduction of the permutation steps diminish or 
enhance the security, i.e. whether the additional 
computational cost involved has caused a negative or 
positive effect? Thanks.

M. K. Shen

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

From: William A. Nelson <[EMAIL PROTECTED]>
Crossposted-To: soc.culture.iranian,soc.culture.usa
Subject: Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - just 
interested if this microwave attack was due to my massive communications on specific 
cryptography and encryption issues starting in the mid of 1999 ....
Date: Thu, 28 Sep 2000 23:26:33 GMT

In article <8r0j95$uhe$[EMAIL PROTECTED]>,
  William A. Nelson <[EMAIL PROTECTED]> wrote:
>
>
> Some facts ....
>
> 1. Already in early 1960īs scientist discover that some audio and
words
> can be heard by humans when microwaves are used without any additional
> devices.
>
> 2. Extensive research and publications written in 1970īs on auditory
> perception and microwaves.
>
> 3. Pulse-modulated microwaves produce perceptible acoustic sensations
> in man and other mammals, even  in subjects with impaired hearing.
>
> 4. A study suggest a direct interaction between the neuron and the
> electric field.
>
> 5. The EEG of the cat demonstrates considerable similarities between
> evoked potentials produced by simple acoustic stimulations and by
> specific microwaves.
>
> 6. The Soviets were the first to envison the possibility of a low-
> level, non-thermal mechanism affecting the cardiac rythm.....
>
> And few links ....
>
> http://www.brooks.af.mil/AFRL/HED/hedr/hedr.html
>
> http://www.brooks.af.mil/AFRL/HED/hedr/dosimetry.html
>
> http://www.brooks.af.mil/AFRL/HED/hedr/reports/home.html
>
> http://www.brooks.af.mil/AFRL/HED/hedr/reports/dielectric/home.html
>
> http://www.brooks.af.mil/AFRL/
>
> I am sure you can find more details. Also heard that somebody had some
> good Soviet studies on this subject matter.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED]
Subject: Blowfish Key length C code issue
Date: Thu, 28 Sep 2000 23:30:14 GMT



Hi ;

I have downloaded the blowfish C code from counterpane siet, however I
can not seem to find out the varaible that uses the key length in the
code.

I would like to be able to change the key length and check the system
performance.

Anyone knows a good source code that I can easily change the key length
variable to something like 32, 128, etc. I would appreciate it. Or even
if you point me out the varaible to change the key length should be
fine.

Thanks

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,comp.theory
Subject: Re: Josh MacDonald's library for adaptive Huffman encoding
Date: Fri, 29 Sep 2000 02:28:56 +0200



"SCOTT19U.ZIP_GUY" wrote:
> 
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in 
> >If one starts from nothing, then one has to use NYT
> >followed by ASCII or its equivalent (i.e. a 'standard'
> >representation of the same space), I suppose. Otherwise
> >I don't see how a new symbol could be transmitted.
>    Then you don't have a basic understanding of huffman
> code. I get tired arguing with you. SInce you don't ever
> seem to learn. Yes this is not friendly but MOK get with it.
> Like I have told you many many times look at my code.
> I would try to help more but past experience shows me
> that you really don't want to know.

You were apparently answering to what I said about
starting from nothing, i.e. with no symbols in the tree.
But then using NYT and a standard encoding (needn't
be the same as ASCII) is what is given in standard
textbooks on data compression. If you have better
ideas, then post that. Perhaps you could apply
for patents and join the rank of gurus.

M. K. Shen
> 
> 
> 
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>         http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
>         http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
>         http://radiusnet.net/crypto/  then look for
>   sub directory scott after pressing CRYPTO
> Scott famous Compression Page
>         http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:

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

From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Thu, 28 Sep 2000 17:55:01 -0700

My real intent was to ensure that author, copyright, and original location
references could not easily be separated from the document.  Also, it would
make for easy inclusion of pictures with the text in proper orientation.  I
always knew someone could retype the text and screen capture the pictures,
but my thinking is most people would find that not worth the effort,
particularly while the original could to easily be viewed.

This does lead to an interesting question about Acrobat security though.  If
one is to mount an attack against an Acrobat encrypted document, does it
make more sense to: 1) Attack the reader code (as you suggested below that
some attacks have been done, though I haven't tried any of them); 2) Attack
the document itself with some sort of filter to remove/alter the protection
specification value(s); or 3) Write a viewer from the specification that
ignores the protection?

I would think the document itself would be the weak point, given that the
full specification is known.

See, now you've gotten me thinking in illegal ways.

    *David Barber*

"Stephan Eisvogel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "David C. Barber" wrote:
> > I am looking to distribute some documents I don't want the user to be
able
> > to alter or print.  Acrobat was suggested, but IIRC, wasn't the Steven
King
> > story distributed through Acrobat, and it was broken quickly just by
loading
> > it into the full fledged Acrobat program?
>
> There are several patches for Acrobat Reader which reenable printing of
> protected documents (by Phrozen Crew and others). I have not seen patches
> for the real Acrobat but think it is easy to break that too, an obscure
> Russian crack site may even already have it.
>
> Depends whom you face, if its Joe Xerox, PDF should be enough because
> the patches are tricky to apply with all those heaps of Acrobat versions
> around. Hours of stupid ftp searching guaranteed. If its a determined
enemy,
> and your document is worth something, avoid electronic distribution.




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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Deadline for AES...
Date: Fri, 29 Sep 2000 00:52:34 GMT

On Thu, 28 Sep 2000 15:48:59 -0600, John Myre <[EMAIL PROTECTED]>
wrote, in part:

>Yes - but he's got a point.  See http://csrc.nist.gov/nissc
>and the top of page 5 in http://csrc.nist.gov/nissc/NCSC.pdf
>for the phrase he quoted.

And that phrase might not yet be true, but is expected to be the truth
by October 16th. But definitely, the claim that

on Monday, October 16th, 2000

from 1:30 PM to 3:00 PM,

room 308 of the Baltimor Convention Center will contain Elaine Barker,
Jim Foti, and Bill Burr of NIST, Marcus Leech of Nortel Networks - and
the "submitter of the selected AES algorithm" (to be determined)

does indeed sound to me like a statement of several empirical facts,
among which is that the AES will be chosen on or before October 16th.
Presumably, that we hear this there first is due either to an
oversight - or because it is only *hoped* that there will be a
selection made by October 16th.

The text quoted: "the standard is ready for public comment" does make
it possible the announcement will take place there, since that implies
it won't have been released by that date.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Question on biases in random-numbers & decompression
Date: Fri, 29 Sep 2000 01:04:02 GMT

D.A.Kopf wrote:
> I see. Efficient use of random bits would then seem to be the reverse
> mapping of an optimum compression of the result. For example mapping a
> series of 1-of-6 random choices into the fewest possible binary
> digits, would also provide a mapping from the fewest possible binary
> digits to the greatest number of random 1-of-6 decisions.
> 
> So the original poster was correct, the inverse of an arithmetic
> compresser would be effective. Just "decompress" the random bitstream
> into the needed bin size.

Yes, precisely.  Especially since the reason I want to "decompress" the
stream is not actually for generating random numbers, but because a type
of encryption I am currently looking at expects plaintexts to be a
vector of integers in the range -1,0,1.  The inverse of an optimum
3-symbol-to-2-symbol compressor should optimally convert a binary
plaintext [which actual plaintexts are] into a trinary plaintext [which
is what NTRU requires].  After encrypting and decrypting, I should then
be able to "compress" the trinary plaintext and get back the original,
binary plaintext.

--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)



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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 29 Sep 2000 01:04:13 GMT

Tim Tyler wrote:
> I am trying to locate a method of adding the random bits in such a
> manner that:
> 
> 1) the recipient can unambiguously strip off the random padding;
> 2) the attacker is given the minimum opportunity to reject keys.
> 
> As an example of a scheme that fails the second criterion, imagine
> the message as a prefixed size 64-bit field prepended to it, which
> describes the length of the plaintext (anything after that is
> padding).
> 
> An attacker can reject huge numbers of keys by checking to see that
> the MSB of the length field is 0000000 (and that the length field is
> shorter than the entire message).
> 
> This method is dreadful.  It adds lots of known plaintext to each
> message.
> 
> I'm interested in a scheme that has a similar aim, but has the fewest
> possible security-related side effects.

I have an idea which is slightly better... Take the length of the
message as a binary number in 7-bit chunks, with the last chunk being
right aligned.  Discard all leading 0-chunks.  Write all but the last
chunk as 1xxxxxxx, and write the last 7-vit chunk as 0xxxxxxx. The enemy
can still try to decode the first few bytes and look for the length
field being shorter than the message, BUT he won't get that string of 0s
at the front, so he'll have slightly more work to do.  Note that in
PERL, there is a template in the pack() function to do this conversion.
(I think it's the string "w", but I'm not sure... I don't have perl on
this computer).

--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)



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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Yet another LFSR idea.
Date: Fri, 29 Sep 2000 01:04:16 GMT

This idea is based on running 8 LFSRs in parrallel using bitslicing.

Create a circular array of N bytes, and fill it randomly.
To update, combine the current byte with the XOR sum of a selection of
the "previous" N-1 bytes, using a primitive polynomial as the selector,
and output it.

The problem with this scheme, is that it is entirely linear: it is
essentially taking 8 lfsrs and outputing one bit from each.

To fix that, change the XOR sum to an additive sum.  The lowest bit in
each byte is still perfectly linear, but the top bit should be
nonlinear.  We could use this, using ONLY the top bit, but that seems
wasteful.

Now make one more change:  Do a circular shift left by 1 bit after
adding.  This brings the nonlinear top bit to the bottom.

The method can be extended to use 32 or 16-bit words, instead of 8-bit
bytes, and of course there's no limit on the size of the array, so long
as you can find a primitive polynomial that large.

What do you all think?

Also, what do you think of using that circular shift left with a
[lagged] fibbonacci generator to increase nonlinearity?

--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)



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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: another AONT idea
Date: Fri, 29 Sep 2000 01:04:19 GMT

It occurs to me that my previous idea is an entirely reverible scheme,
and could be used with the data directly to make a kind of AONT.

1) First prepend the data with a random IV.
2) Second, load all the data into a big circular array of 32-bit words.

3) For each block Add to the current block a selection of the previous
blocks, using some polynomial, followed by a circular shift left.

4) repeat step 3 as many times as the order of the polynomial.

This idea takes O(N) time, is easily reversible, and should be quite
nonlinear.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)



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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: RSA T-shirt
Date: Fri, 29 Sep 2000 01:04:20 GMT

David A Molnar wrote:
> Mean R. K. Oily <[EMAIL PROTECTED]> wrote:
> 
> > pointer in your shirt pocket, a calculator on your belt with
> > functions like "hyperbolic cotangent", and plastic rimmed glasses
> > that have been repaired with band-aids. The shirt will round that
> > out nicely when it finally comes.
> 
> actually, the function "modexp" would be more appropriate for this
> crowd.  or better yet "findord" (but that one takes a while).
> 
> -David ("what's that?" "a grouping calculator.")
A calculator groupie?  What about a groping calculator?

--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)


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


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

Reply via email to