Cryptography-Digest Digest #666

2000-09-12 Thread Digestifier

Cryptography-Digest Digest #666, Volume #12  Wed, 13 Sep 00 01:13:00 EDT

Contents:
  Re: Intel's 1.13 MHZ chip ("Abyssmal_Unit_#3")
  Re: question on the bible code ("Mikal 606")
  Weak keys in RC4 (Patrick Schultz)
  Re: ExCSS Source Code (Eric Smith)
  Re: question on the bible code (Mr. Noel Yaki)
  Re: Ciphertext as language (wtshaw)
  Re: For the Gurus (wtshaw)
  Crypto Related Pangrams (wtshaw)
  Re: Bytes, octets, chars, and characters (Jerry Coffin)
  Re: Getting Started, advice needed (FAQs , yes I read them) (David Hopwood)
  Re: MAC (David Hopwood)
  Re: SV: Intel's 1.13 MHZ chip (Greggy)
  Re: SV: Intel's 1.13 MHZ chip (Greggy)
  Re: Intel's 1.13 MHZ chip (Greggy)
  Re: S.I. unit names, off-topic (was re Intel's 1.13 MHZ chip) (Greggy)
  Re: Intel's 1.13 MHZ chip (Greggy)
  Re: Intel's 1.13 MHZ chip (Greggy)
  Re: Intel's 1.13 MHZ chip (Greggy)
  Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
  Re: OutLook Express  SMIME (Greggy)



From: "Abyssmal_Unit_#3" [EMAIL PROTECTED]
Subject: Re: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 20:10:02 -0400

yes, i believe you are correct regarding individual gate ratings.  paralleling enough 
of them and retaining coherent and usable
timing performance is a nighmare requiring device selection  that is another 
hamstring. single die matching has nearly eliminated
this constraint entirely.

--
best regards,
hapticz

X(sign here)

John Savard wrote in message [EMAIL PROTECTED]...
|On Mon, 11 Sep 2000 13:18:54 -0400, "Abyssmal_Unit_#3"
|[EMAIL PROTECTED] wrote, in part:
|
|MECL (Motorola Emitter Coupled Logic) architecture has been available for close to 
|25 years with capability to perform at 1 to 2
gig
|rates.
|
|Note, though, that ECL has much higher power consumption than CMOS,
|and supports much lower chip densities. (It's worse than bipolar,
|because it gains its speed by not driving its transistors to
|saturation.)
|
|Also, the 1 GHz speed of a microprocessor is for a machine cycle,
|which involves many elementary logic operations. The figure you quote
|may be the speed of individual NAND gates.
|
|John Savard
|http://home.ecn.ab.ca/~jsavard/crypto.htm



--

From: "Mikal 606" [EMAIL PROTECTED]
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Tue, 12 Sep 2000 20:38:24 -0700

I understand many peoples deep desire to believe in this code.
But I ask you, what else does it add?Are you not already a believer?
Do you understand what I mean?




"TaoenChristo" [EMAIL PROTECTED] wrote in message
news:8pm1ig$a2f$[EMAIL PROTECTED]...
 In article 8pbko1$n2m$[EMAIL PROTECTED],
   "Mikal 606" [EMAIL PROTECTED] wrote:
 
  "John Kennedy" [EMAIL PROTECTED] wrote in message
  news:9lcu5.20946$[EMAIL PROTECTED]...
  
   Then explain it.
   Whats your interest in the matter?
   I think it's just interesting to see the names pop up
 
  heres a good handling of ELS-
  /
  http://www.nctimes.net/~mark/fcodes/elsyesh.htm
 
 

 To explain why the ELS in the Bible is unique, you must understand, it
 is not just the occurance of words at certain skip lengths, as the
 author of this web page assumes. Even if the word Yeshua occured with
 cross (or whatever) in differant text, that shows nothing, but a neat
 coincidence... now find me ANY text that has the following words:

 Herod, Annas and Judas, ALL 12 diciples,"the Marys weep bitterly," "let
 him be crucified," "true Messiah" and "son of Mary"

 These in turn are intersected by hundreds of other similar ELSs.


It *has to be reconstructed* from the Hebrew alphabet and you can rebuild
all kinds of words when the original alphabet is missing vowels!


 All of these words and phrases are found intersecting Isaiah 52-53. The
 odds of all of the above phrases and words being found in ELS code, in
 only 2 chapters of one book of 66, would be somewhere around 1 in
 3,408,749,015,176,240,000,000,000,000,000,000,000,000,000,000.


Really now!


 though you might be able to find Yeshua intersecting Christ or some
 other such combinations in other books, I find it to very unlikely that
 you will EVER find the combinations above in any other book anywhere!

 --
 Romans 1 20 For the invisible things of him from the creation of the
 world are clearly seen, being understood by the things that are made,
 even his eternal power and Godhead; so that they are without excuse:



Jeremiah 14:14
Then the LORD said unto me, The prophets prophesy lies in my name: I sent
them not, neither have I commanded them, neither spake unto them: they
prophesy unto you a false vision and divination, and a thing of nought, and
the deceit of their heart.




 Sent via Deja.com http://www.deja.com/
 Before yo

Cryptography-Digest Digest #666

2000-04-30 Thread Digestifier

Cryptography-Digest Digest #666, Volume #11  Sun, 30 Apr 00 02:13:01 EDT

Contents:
  Re: How would a 15 year old start? (David Formosa (aka ? the Platypus))
  Re: How safe am I using a subset of the bytes returned by SHA-1? (stanislav shalunov)
  Re: Intel drops serial number (Isaac)
  S/MIME + Netscape v47 serious problem in symmetric encryption ... (jungle)
  Hushmail style idea (Tom St Denis)
  Tempest Attacks with EMF Radiation ("Ryan Phillips")
  Re: The Illusion of Security (Uri Blumenthal)
  Re: Extending the sboxgen and differential analysis (David A. Wagner)
  Mathmatical concepts (Ryan Senior)
  Re: Intel drops serial number (David A. Wagner)
  Re: sboxes for the bored... (David A. Wagner)
  Re: Mathmatical concepts (David A. Wagner)
  Re: sboxes for the bored... (David A. Wagner)
  Re: sboxes for the bored... (David A. Wagner)
  What is the strongest encryption rate so far possible/achived? ("Monolo")
  Re: What is the strongest encryption rate so far possible/achived? (David A Molnar)
  Re: Tempest Attacks with EMF Radiation (Guy Macon)
  Re: How safe am I using a subset of the bytes returned by SHA-1? (Mark Thomson)



From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: How would a 15 year old start?
Date: 30 Apr 2000 01:14:27 GMT
Reply-To: dformosa@[202.7.69.25]

On Sat, 29 Apr 2000 09:34:42 -0700, Monolo [EMAIL PROTECTED] wrote:
As I said, in my pervious post, I would love to learn, I read Tom's post
back to me after I sent it, sorry for the duplication. I was wondering, what
would be the best way to start? Are there any good online resources?

Buy Applied Cryptography By Bruce Schneier.

-- 
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money?  Email me.

--

Subject: Re: How safe am I using a subset of the bytes returned by SHA-1?
From: stanislav shalunov [EMAIL PROTECTED]
Date: Sun, 30 Apr 2000 01:20:04 GMT

Mark Thomson [EMAIL PROTECTED] writes:

 I'm coding up a shell extension for Win32 platforms that will show a
 hash for a file when you right click on it.

How would this be used?

 I'm using SHA-1, for the simple reason that I have source to it, and
 it works.  The problem with SHA-1 is that it's a bit on the chatty
 side: it produces 20 bytes of digest, which equates to 40 characters
 when printed in hex, plus some formatting to make it readable.

You can use base64; that'll make it 27 characters.

 I am very tempted to simply take the first 8 bytes of the digest, and
 display them in this format:
 - -
 since this is a managable amount of data for a context menu addon.

Is the user supposed to memorize 64 random bits?  I've been trying in
vain for years to make users memorize 56 bits.  They won't.

This data will be cut-and-pasted only.  So, why bother with size?

 Given that the security of the entire western world won't be riding on
 this app, how much danger am I in doing this.  The naive answer is
 2^64, since I have 64 bits of data, which in all honesty is plenty
 enough for what I'm doing.  However is there something that I don't
 know that could cause problems?

If you have 2^32 files, it's probable that you'll have a collision.
Whether this matters for your application, I don't know.

It's also possible to modify a file and make it have the same checksum
(though it's going to take a few hours to do so).

 As an alternative, is there any reason not to drop back to the CCITT
 CRC32, which produces only 4 bytes of output?  That'd give me a 1 in 4
 billion (give or take) chance of a false match, which again is
 probably plenty enough for what I'm doing.

If the possibility of somebody changing the file without changing
checksum doesn't bother you, it's OK.  It's also not a one-way
function, so information is leaked.

-- 
stanislav shalunov  | Speaking only for myself.

--

From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: Sun, 30 Apr 2000 01:29:45 GMT

On 29 Apr 2000 10:23:37 -0600, Vernon Schryver [EMAIL PROTECTED] wrote:

The evil is that the kooks fooled the clue-free masses into thinking
that they were protecting their privacy by fighting the PIII ID.
The idiot masses were distracted from real and quite serious privacy
threats.  If I were paranoid, and if I didn't know that the kooks
do such evil for free, I'd suspect that Doubleclick and the FBI
had tricked Intel into making it's silly noises and then funded

I think this is the silly idea.  Nobody let Doubleclick get away
with anything by distracting them with the CPU ID smoke.  If anyone
was guilty of distracting people it had to be Intel.  Exactly why
the kooks get some much credit when at worst they were guilty of
fall

Cryptography-Digest Digest #666

1999-12-02 Thread Digestifier

Cryptography-Digest Digest #666, Volume #10   Thu, 2 Dec 99 17:13:01 EST

Contents:
  Re: Why Aren't Virtual Dice Adequate? (John Savard)
  Re: newbie question (John Savard)
  Re: Random Noise Encryption Buffs (Look Here) (Mattias Wecksten)
  Re: Quantum Computers and Weather Forecasting (Uncle Al)
  Re: Noise Encryption (Mattias Wecksten)
  Re: Elliptic Curve Public-Key Cryptography ("Michael Scott")
  Re: NSA should do a cryptoanalysis of AES ("Brian Gladman")
  Re: The Code Book - Part 4 ("Scott Williamson")
  Re: dictionary (drickel)
  Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
  crypto faculty position (Christof Paar)
  Re: smartcard idea? (Shawn Willden)
  Re: High Speed (1GBit/s) 3DES Processor (Shawn Willden)
  Re: smartcard idea? (Shawn Willden)
  Re: Use of two separate 40 bit encryption schemes (Shawn Willden)
  Re: Quantum Computers and Weather Forecasting (John Bailey)
  Is there an analog of Shor's algorithm for elliptic functions? (John Bailey)
  Microsoft Crypto API ([EMAIL PROTECTED])
  Re: crypto faculty position  What is the $ range for the positions  
([EMAIL PROTECTED])
  Re: Quantum Computers and PGP et al. (Greg)



From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Thu, 02 Dec 1999 19:29:33 GMT

[EMAIL PROTECTED] (Guy Macon) wrote, in part:


Good info!  I have a clueless newbie question about something that
I found while reading the above:

| "Nor does even a theoretical one time pad imply unconditional security:
| Consider A sending the same message to B and C, using, of course, two
| different pads. Now, suppose the Opponents can acquire plaintext from
| B and intercept the ciphertext to C. If the system is using the usual
| additive combiner, the Opponents can reconstruct the pad between A
| and C. Now they can send C any message they want, and encipher it
| under the correct pad. And C will never question such a message,
| since everyone knows that a one time pad provides "absolute" security
| as long as the pad is kept secure. Note that both A and C have done
| this, and they are the only ones who had that pad." 

It seems that the attacker needs to also have to know that A sent
the same message to B and C.  Knowing B's plaintext and knowing
that B and C got the same message resolves to knowing C's plaintext.
I see no way that a man in the middle attacker can know whether or
not A sent the same message to B and C.

The attacker can't know that for sure. But such an active attack is
still possible: it is at least _possible_ that, if two messages of the
same length are involved, this has happened. If this is done, either
the false message is inserted, or C will simply recieve undecodable
nonsense. (The idea is that the _chance_ of both messages being the
same is MUCH greater than the chance of a particular message guessed
at random.)

The idea is that B and C belong to the same side, but B is secretly
one of your spies. It can be refined by leaving header fields in C's
message alone. (Imagine B, C, D, E, F, G, H... and B and D are both
your spies, and they have on previous occasions both recieved
identical messages, but on their own OTPs.)

While not disproving the security properties the OTP does have, it
shows that there is still a possibility of attack that can very easily
be overlooked - and has been overlooked, as I haven't seen this
mentioned anywhere else - *an OTP does not provide perfect
authentication of any message sent to more than one recipient*.

John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

--

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: newbie question
Date: Thu, 02 Dec 1999 19:32:43 GMT

Kyle Hayes [EMAIL PROTECTED] wrote, in part:

but I can't figure out how to use the Crypto API to
get the actual binary string of the key (it is a session key).

It is *intended* that you cannot access that, since the Crypto API is
intended to _prevent_ interoperable use of any cryptographic software
that isn't signed by Microsoft.

This ensures that non-US customers cannot make use of encryption
software with a key size over 40 bits in connection with exportable
software that allows, through the Crypto API, the use of encryption
_within the terms of the U.S. export laws_.

John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

--

From: Mattias Wecksten [EMAIL PROTECTED]
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 02 Dec 1999 20:43:14 +0100

I hope I enter this thread at the right point.

I started to get curious about why this conversaion spun off at all?
When using a OTP the key-randomness is not critical.
Transfering the key is.

MvH M WxX

* Suddenly I realized that it was possible to create a secure system for use on a