Cryptography-Digest Digest #661
Cryptography-Digest Digest #661, Volume #10 Thu, 2 Dec 99 02:13:01 EST
Contents:
Re: more about the random number generator (NFN NMI L.)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: Why Aren't Virtual Dice Adequate? (fungus)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: Decyption proof cellphones in Europe? [x3] ("Douglas A. Gwyn")
Re: brute force versus scalable repeated hashing ("Douglas A. Gwyn")
Re: The Code Book - Part 4 ("Douglas A. Gwyn")
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Some feedback from the USA --- my story is real .. ("Douglas A. Gwyn")
Re: Encrypting short blocks ("Douglas A. Gwyn")
Re: Paradise shills?? ("Douglas A. Gwyn")
Re: VIC cipher strength? (UBCHI2)
Re: digraph frequencies ("r.e.s.")
Re: Elliptic Curve Public-Key Cryptography (David A Molnar)
Re: VIC cipher strength? ("r.e.s.")
Re: The $10,000.00 contesta (Johnny Bravo)
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: more about the random number generator
Date: 02 Dec 1999 01:22:18 GMT
<>
What's that machine look like? And the 5 state machine that prints 1000-odd
states? At least the 4 state busy beaver is precisely known...
Wow! My long .sig returns!
-*---*---
S.T.L. (NFN NMI L. also) -===> [EMAIL PROTECTED] <===- 2^6972593 - 1 IS PRIME!
Quotations: http://quote.cjb.net Main site: http://137.tsx.org F00FC7C8 MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 Mail block
is gone, but will return if I'm bombed again. It was an easy fix. Address is
correct as-is. Giving the correct address is COURTEOUS; junk gets in anyway.
Join the Great Internet Mersenne Prime Search at http://entropia.com/ips/ My
.sig is even shorter, and contains 3046 bits of entropy including next line:
-*---*---
Card-holding member of the Dark Legion of Cantorians, People for the Ethical
Treatment of Digital Tierran Organisms, the Holy Order of the Catenary, the
Great SRian Conspiracy, the Triple-Sigma Club, the Polycarbonate Syndicate,
the Union of Quantum Mechanics, the Roll-Your-Own Crypto Alliance, the
Church of the New Epoch, and the Organization for the Advocation of
Two-Letter Acronyms (OATLA)
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "When Renormalization Fails", "World's
Most Energetic Cosmic Rays", and "When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #27: Laziness Increases With Time.
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 21:24:40 GMT
On Wed, 01 Dec 1999 13:48:36 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>> The burden of proof is on the claimant. If has a point to make, it
>> is up to him to prove he is right, it is not up to us to prove him
>> wrong.
>>
>Well, you might be well liked in a class on legalities, but, science makes
>no demand, merely that the evidence speaks for itself, whatever the
>source.
Vague claims without testable, repeatable evidence to back them up
are not science. They make good pseudoscience though, as regularly
shown over in talk.origins.
>A *good* scientist willing reveals everything if part of the evidense he
>exposes is against him. There is no expectation regarding his feelings as
>long as the data is there.
But tossing out a theory, and saying "That is the truth, prove me
wrong or admit I'm right." is not science by any stretch of the
imagination.
Best Wishes,
Johnny Bravo
--
From: fungus <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Thu, 02 Dec 1999 02:37:30 +0100
Bennett Standeven wrote:
>
> On Thu, 25 Nov 1999, Tim Tyler wrote:
>
> > In sci.crypt John Savard <[EMAIL PROTECTED]> wrote:
> >
> > : However, in practice, random numbers derived from throwing dice or
> > : flipping coins are adequate for producing secure one-time-pads.
> >
> > Really? How do you judge how secure they are?
> >
> > What coins, or dice would you recommend using - and what manufacturing
> > process produced them?
>
> Casino dice should do nicely.
Any dice/coins should do if you change them around.
eg. Throw a die then flip a coin the number of times shown
on the die, outputting that many bits. Toss another coin
twice to decide whether to swap the coin/die for another
one in the set.
You can complicate th
Cryptography-Digest Digest #662
Cryptography-Digest Digest #662, Volume #10 Thu, 2 Dec 99 09:13:01 EST
Contents:
Re: One Round Block Cipher and 8-bit block Cipoher (Scott Fluhrer)
Re: Use of two separate 40 bit encryption schemes (Bill Unruh)
Re: Encrypting short blocks (Markus Peuhkuri)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Decyption proof cellphones in Europe? [x3] (Gurripato)
Re: One round or 8-bit block cipher (Thomas Pornin)
Re: A dangerous question (Guy Macon)
Re: more about the random number generator (CLSV)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: The $10,000.00 contesta (Alan Braggins)
Re: been a while since I used pgp ("Julian LEWIS")
dictionary ("Olaf Dokter")
Will ScramDisk recover ? >> After another round of tests ... YES, it
([EMAIL PROTECTED])
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: One Round Block Cipher and 8-bit block Cipoher
Date: Thu, 02 Dec 1999 07:23:00 GMT
In article <[EMAIL PROTECTED]>,
Seongtaek Chee <[EMAIL PROTECTED]> wrote:
>(a) Suppose I use an 1-round block cipher
> with
>1) 128-bit key addition
>2) a large S-box(128 x 128, e.g., x^{-1} in GF(2^{64}),
> which can be calculated directly, even though very slow).
> Is it safe?
> Which attacks can be considered?
Is step 2 independent of the key? If so, then the attacker obtains a
single plaintext/ciphertext pair, and then applies the inverse of step
2 to the ciphertext. The difference between that and the plaintext is
the key.
Hint: there's very little point in doing key-independent operations
at the very front or at the very end of a block cipher.
>
>
> (b) Suppose I use a 64-round block cipher
> with
> 1) 128-bit key
> 2) 8-bit Input/Output size.
> Is it safe?
> Which attacks can be considered?
Well, the attack obtains several (say, 200 bytes worth) of known
plaintext/ciphertext. Then, for any unknown ciphertext, the
ciphertext blocks are likely to appear somewhere in the known text,
and so can be looked up. This is called a 'code-book' attack, and
is why serious block ciphers have blocks of at least 64 bit.
(Actually, for a block that small, the attacker might very well
attack it as a Caesarian cipher, without any known plaintext.
However, this attack doesn't generalize quite as well).
--
poncho
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Use of two separate 40 bit encryption schemes
Date: 2 Dec 1999 07:48:39 GMT
>>as I do not live in the land of the free, I'm not permitted to have
>>more than 40 bit DES
By whom? Do you also not read Playboy since many countries around the
world ban it? Do you refuse to read about Tibet because China does not
like it? Why do you care what the USA thinks?
--
From: Markus Peuhkuri <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: 02 Dec 1999 10:07:22 +0200
> "w" == wtshaw <[EMAIL PROTECTED]> writes:
Thanks for all who replied. One thing I didn't remember to
write up was thet stream cipher or OTPs are not suitable for
my application. As far I've understand there the result
depends on order of blocks (or data). While this is generally
desirable property of encryption, it is not in my case.
What I want is following property: given message M1 (length N
bits) produces same encrypted message E1 (length N bits) every
time run. Message M2 produces message E2, which is different
from E1 iff message M2 is different from M1. However, I'm
willing to accept some probability of collisions, less than
1/1000 (different messages M1 and M2 produce same result E1).
w> algorithm. When you change an algorithm, you have a different
I took look at blowfish, but I don't have knowledge if it is
possible to modify it to use shorter block lengths than 64
bits _without_ weakening security. Maybe I'll have try to
find out if it is technicaly feasible.
w> Pick a block length, pick a usable keylength, design a good
w> algorithm, case closed.
As I're read enough about poor implementations, I would not
risk spending two years of my life in restricted freedom.
I would like to make sure.
--
Markus Peuhkuri ! [EMAIL PROTECTED] ! http://www.iki.fi/puhuri/
Never underestimate the power of human stupidity
... and don't forget you are a human too.
--
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 2 Dec 1999 08:41:31 GMT
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>Regarding RW being shown to be equivalent to factoring, as shown by the recent
>breaks of ISO 979
Cryptography-Digest Digest #663
Cryptography-Digest Digest #663, Volume #10 Thu, 2 Dec 99 09:13:01 EST Contents: Avoiding bogus encryption products: Snake Oil FAQ (C Matthew Curtin) From: C Matthew Curtin <[EMAIL PROTECTED]> Crossposted-To: alt.security,comp.security,comp.infosystems,comp.answers,sci.answers,alt.answers,news.answers Subject: Avoiding bogus encryption products: Snake Oil FAQ Date: 2 Dec 1999 13:41:38 GMT URL: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Version: 1.9 Archive-name: cryptography-faq/snake-oil Posting-Frequency: monthly Snake Oil Warning Signs: Encryption Software to Avoid Copyright © 1996-1998 Matt Curtin <[EMAIL PROTECTED]> April 10, 1998 Contents * Contents * Introduction * Basic Concepts o Symmetric vs. Asymmetric Cryptography o Secrecy vs. Integrity: What are you trying to protect? o Key Sizes o Keys vs. Passphrases o Implementation Environment * Snake Oil Warning Signs o ``Trust Us, We Know What We're Doing'' o Technobabble o Secret Algorithms o Revolutionary Breakthroughs o Experienced Security Experts, Rave Reviews, and Other Useless Certificates o Unbreakability o One-Time-Pads o Algorithm or product X is insecure o Recoverable Keys o Exportable from the USA o ``Military Grade'' * Other Considerations * Glossary * Index * References Administrativia Distribution Distribution of this document is unlimited. We're specifically trying to reach people who are not experts in cryptography or security but find themselves making decisions about what sorts of crypto (if any) to use, both for their organizations and for themselves. The Snake Oil FAQ is posted monthly to sci.crypt, alt.security, comp.security, comp.answers, and comp.infosystems. It is available in PostScript and PDF form (ideal for printing) via the web at http://www.interhack.net/people/cmcurtin/snake-oil-faq.ps http://www.interhack.net/people/cmcurtin/snake-oil-faq.pdf and HTML at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves. This is a compilation of common habits of snake oil vendors. It cannot be the sole method of rating a security product, since there can be exceptions to most of these rules. From time to time, a reputable vendor will produce something that is actually quite good, but will promote it with braindead marketing techniques. But if you're looking at something that exhibits several warning signs, you're probably dealing with snake oil. Every effort has been made to produce an accurate and useful document, but the information herein is completely without warranty. This is a work-in-progress; feedback is greatly appreciated. If you find any errors or otherwise wish to contribute, please contact the document keeper, Matt Curtin <[EMAIL PROTECTED]> Document History With the rise in the number of crypto products came a rise in the number of ineffective or outright bogus products. After some discussion about this on the cypherpunks list, Robert Rothenburg <[EMAIL PROTECTED]> wrote the first iteration of the Snake Oil FAQ. Matt Curtin took the early text and munged it into its current state with the help of the listed contributors (and probably some others whose names have inadvertently missed. Sorry in advance, if this is the case.) Contributors The following folks have contributed to this FAQ. Jeremey Barrett <[EMAIL PROTECTED]> Steven M. Bellovin <[EMAIL PROTECTED]> Matt Blaze <[EMAIL PROTECTED]> Bo Dvmstedt <[EMAIL PROTECTED]> Gary Ellison <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Larry Kilgallen <[EMAIL PROTECTED]> Dutra Lacerda <[EMAIL PROTECTED]> Felix Lee <[EMAIL PROTECTED]> Colin Plumb <[EMAIL PROTECTED]> Jim Ray <[EMAIL PROTECTED]> Terry Ritter <[EMAIL PROTECTED]> Robert Rothenburg <[EMAIL PROTECTED]> Adam Shostack <[EMAIL PROTECTED]> Rick Smith <[EMAIL PROTECTED]> Randall Williams <[EMAIL PROTECTED]> Introduction Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security. Why ``snake oil''? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor's claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just
Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #10 Thu, 2 Dec 99 12:13:01 EST
Contents:
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Hey, NSA! Venona html errors! ("John K. Taber")
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: been a while since I used pgp (Johnny Bravo)
Re: Encrypting short blocks (Eric Lee Green)
Re: Pleasantville: civilty under duress ([EMAIL PROTECTED])
Re: The $10,000.00 contesta (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: Elliptic Curve Public-Key Cryptography (David Wagner)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Noise Encryption ("Tim Wood")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 15:10:00 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Brian Chase wrote:
>> I think what I'm finding most disturbing, if not just outright disgusting,
>> is how quickly disregarded are Scott's challenges to the conventions of
>> the cryptology community. Sure he's an asshole, but as a community is it
>> not true that we don't conclusively know how secure the contemporary
>> algorithms are?
>
>Neither does D.Scott! The main problem with his arguments is that
>he asserts weaknesses in everybody's encryption schemes except his,
>but doesn't *demonstrate* the weaknesses. When he claims, for
>example, that CBC itself creates exploitable weaknesses, yet there
>happen to be solid mathematical papers demonstrating that CBC used
>with a *strong* block cipher is not substantially weaker than the
>block cipher by itself, it is incumbent on *him* to prove his claim,
Again I see the assholes misquote me. I never said that
CBC makes a cipher weaker. What I have said is that the diffusion
is not more than 2 blocks. So that an attacler using a small number of
blocks would never have to look at the whole file. Since all the 3 letter
modes that you dumb people ever use really add very little strength
the the cipher. I even give examples that show the information is not
distributed through the whole file. Most are to stupid to understand this
fact. Of those smart enough to understand most don't seem to care.
In the three letter modes when some one does even a partical plain
text attack you can get the input output pairs to the underlying
blokc cipher. These may or may not be of use to the person breaking
the cipher. With 3 rounds of "wrapped PCBC" this information is not easily
available. So it can't be used. One is forced to examine the encryption
as a whole. Something that the nomral block chaining methods have
gone out of there way to avoid. To me the reason is obvious.
The NSA has done a good job of keeping people stupid about using
chaining to secure a ciper.
>or at least to exhibit an error in the previous work that proved the
>opposite. That's not only standard professional practice, it's
>plain common sense. Since he doesn't make a convincing case,
>preferring to curse and challenge the integrity of anyone who
>disagrees with him, it is not surprising that he is being almost
>entirely ignored by the professional community.
I guess I just like to call a spade a spade big fucking deal.
you can call it a shovel.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
--
From: "John K. Taber" <[EMAIL PROTECTED]>
Subject: Hey, NSA! Venona html errors!
Date: Thu, 2 Dec 1999 08:18:50 -0600
You have duplicate gif names on the Aug 43 page, for the 12th and
19th. Are the duplicates supposed to be, or is this an error?
Also, there are apparent html errors on the Jul 43 page that
cause non-selected hyperlinks to appear as if selected.
Finally, you really need a webmaster email address for queries
like this. How about it?
--
Consuming is dirty business, but somebody has to do it. Robert McTeer
--
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 02 Dec 1999 14:52:25 GMT
For info on coming up with crypto schemes based on math primitives, see IEEE
P1363. I agree there are many factors to consider and many traps to avoid.
Regarding timings, this is not my area of expertise. Certicom
Cryptography-Digest Digest #665
Cryptography-Digest Digest #665, Volume #10 Thu, 2 Dec 99 14:13:02 EST Contents: Any negative comments about Peekboo free win95/98 message encryptor ([EMAIL PROTECTED]) Re: What part of 'You need the key to know' don't you people get? (wtshaw) Re: NSA should do a cryptoanalysis of AES (wtshaw) Re: AES cyphers leak information like sieves (wtshaw) Re: Why Aren't Virtual Dice Adequate? (Guy Macon) Re: Encrypting short blocks (wtshaw) Re: Use of two separate 40 bit >> tony >> Where you posting from ? [ ([EMAIL PROTECTED]) Re: Elliptic Curve Public-Key Cryptography (Medical Electronics Lab) Please Check my understanding of Montgomery Algorithm (Vasudev Pai) Re: Quantum Computers and PGP et al. (Jim Dunnett) Re: Ultimate Crypto Protection? (Jim Dunnett) Re: Decyption proof cellphones in Europe? [x3] (Jim Dunnett) Quantum Computers and Weather Forecasting (John Savard) Re: Decyption proof cellphones in Europe? [x3] (Eric Pinnell) From: [EMAIL PROTECTED] Crossposted-To: alt.security.pgp Subject: Any negative comments about Peekboo free win95/98 message encryptor Date: Thu, 02 Dec 1999 12:09:41 -0500 Any / negative comments / evaluations / possible back-door entry / stableness / known software & hardware conflicts / about Peekboo free win95/98 message encryptor program ? It is listed on site http://www.counterpane.com/products.html because it is using Blowfish [ some sort of endorsement from Blowfish creator ]. The main site is at http://www.cell2000.net/security/peekboo/index.html The program is provided in 1 [ ONE ] executable only >> extremely secure in extremely insecure win95 environment. Executable is extremely small >> less than 50 kB. Peekboo is freeware & current Source Code publicly available. The program is modestly new [ the first Public Key on site is dated Sep 28 / 1999 ] Peekboo is a free win95/98 message encryptor program. It has many features which will be discussed on the other pages. It basically allows for secure communication with any person (even people you have not physically met yet) using any text medium (such as email or chat programs). Current Release is v1.73 (Nov 23rd 1999) The main problem it tries to solve is insecure transportation of text messages over any text medium (such as email, chat and usenet). To obtain this goal I had to add symmetric ciphers to actually encrypt the message, a hash function (which is used in many places) and diffie-hellman key exchange. Nothing else was added (such as swap file cleaning, file wiping) because they would not solve my problem. The author is claiming these features : Diffie-Hellman Key Exchange Secure method for people to share a private key remotely. Simple to use. Uses a 2048 bit strong prime as the modulus *** Group Shared keys planned for V2.0 *** Seven Symmetric Ciphers Allows you to use the symmetric cipher you feel most comfortable with. Includes: Cast, Blowfish, RC4, RC5, RC6, Twofish and Rijndael. 160 bit symmetric keys. Each message uses a independent symmetric key which is the hash of the shared key and a 128 bit random SALT. File Encryption Simple to use file encryption routines. Compact The executable is only about 50 kb. The size is growing slowly as new features are added, although right now it's quite comparable to the popular cryptosystems [only 75 times smaller]. Any input will be appreciated. -- Thanks, Richard -- From: [EMAIL PROTECTED] (wtshaw) Subject: Re: What part of 'You need the key to know' don't you people get? Date: Thu, 02 Dec 1999 11:36:08 -0600 In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote: > wtshaw wrote: > > [EMAIL PROTECTED] (Johnny Bravo) wrote: > > > The burden of proof is on the claimant. If has a point to make, > > > it is up to him to prove he is right, it is not up to us to prove > > > him wrong. > > Well, you might be well liked in a class on legalities, but, ... > > Johnny Bravo is right and you are wrong. If scientists had to take > seriously every crackpot claim, they'd never have time to make any > real progress. It is a simple matter of practicality that the > proponent of a new idea that challenges established knowledge needs > to make a *convincing* case for his idea, so that at least some > scientists will be motivated to look into it. There are so many cases of everybody being wrong when someone else is right. You honestly cannot reject a single detractor on sight. I assure you that I want to see evidence of his claims if possible, or define them at least worth more study. The last thing I am going to do is reject claims if there is reason to believe that they might be true. Being open to such things may seem a burden, but it is a requirement nonetheless. Personaly, I have a few rather unpopular ideas myself, backed up by my experience; if they prove accurate according to ad
Cryptography-Digest Digest #666
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 (jsavardecnabca)
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 (jsavardecnabca)
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 any
free web server at all, only using JAVAS
Cryptography-Digest Digest #667
Cryptography-Digest Digest #667, Volume #10 Thu, 2 Dec 99 18:13:01 EST
Contents:
Re: smartcard idea? ("anonymous intentions")
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
Re: Encrypting short blocks (Anton Stiglic)
Re: Use of two separate 40 bit encryption schemes (Eric Lee Green)
Re: Encrypting short blocks (Anton Stiglic)
Re: What part of 'You need the key to know' don't you people get? ("Trevor Jackson,
III")
Re: Encrypting short blocks ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Trevor Jackson,
III")
Re: Decyption proof cellphones in Europe? [x3] ("Trevor Jackson, III")
Re: more about the random number generator (Anton Stiglic)
Re: more about the random number generator (Anton Stiglic)
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: Why Aren't Virtual Dice Adequate? ("Douglas A. Gwyn")
Re: NP-hard Problems (James Pate Williams, Jr.)
Re: NP-hard Problems (Anton Stiglic)
From: "anonymous intentions" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Thu, 2 Dec 1999 14:28:15 -0600
Unless of course you create a rechargeable device in the HID proximity
card, but then you have the issue of spoofing via RF. Contactless isn't such
a great idea even if it is only transmitting a session hash. Contacts would
be better if they contained a pin on-board the card itself or on an
interpreter module on the card in which the PIN would never leave the card
or IM itself. Even better than that is a biometric thumbstamp that would
activate PIN access on the card interpreter.
kill4u at hushmail dot com
Shawn Willden <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
>
> > Your LED docking could be a LOT cleaner and more trouble free than
> > magnetic stripes or electrical contact pin connections.
>
> I wasn't suggesting the LED would be used for communication
> with the ATM,
> just with the user. Using it instead of electrical contacts
> would mean the
> card would have to contain its own power source (e.g. a
> battery) which isn't
> currently feasible, AFAIK.
>
> Shawn.
--
Date: Thu, 02 Dec 1999 17:32:58 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
> Anyone who thinks that NSA will get at information in future by
> breaking such algorithms (rather than their implementations) has not
> understood the closing of the cryptographic knowledge gap between the open
> and closed worlds.
How did you reach the conclusion that "the crypto gap" (shades of the 1950's
"missile gap") has closed? Why do you believe your supposed gap closing should
be obvious?
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 17:33:48 -0500
"Douglas A. Gwyn" wrote:
> Markus Peuhkuri wrote:
> > Is there an encyprion algorithm that can be used for short
> > blocks (variable from ~10 to 24 bits) _and_ the result is same
> > length as original data.
>
> Yes, most binary-oriented stream ciphers have that property.
A stream cipher is not a block cipher.
--
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Use of two separate 40 bit encryption schemes
Date: Thu, 02 Dec 1999 15:30:57 -0700
Shawn Willden wrote:
> double encryption to 41 bits. However, if you
> triple-encrypt your packets
> with 40-bit DES before transmitting them, you can get 80-bit
> strength (you
> can use either two or three 40-bit keys, but if you use two
> keys, make
> sure to alternate their usage).
One thing to note for us Amurricans is that the BXA would consider this to be
an 80-bit cipher, rather than multiple applications of a 40 bit cipher, and
would regulate it as such. Obviously I cannot say what a foreign government
would believe, but given the amount of incest at top levels, I suspect their
policies would be similar.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 17:35:19 -0500
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, Markus Peuhkuri
> <[EMAIL PROTECTED]> wrote:
>
> > Is there an encyprion algorithm that can be used for short
> > blocks (variable from ~10 to 24 bits) _and_ the result is same
> > length as original data. The key may be much larger (128, 256,
> > ...).
> >
>
> >
> > Could some existing algorithm be changed to work like that?
> >
> Sure thing, block length and key length have little relationship aside
>
Cryptography-Digest Digest #668
Cryptography-Digest Digest #668, Volume #10 Thu, 2 Dec 99 19:13:01 EST
Contents:
Safeboot is it really safe (Matt)
Re: Quantum Computers and Weather Forecasting (John Savard)
Re: NSA should do a cryptoanalysis of AES ("Brian Gladman")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: newbie question (Kyle Hayes)
Re: Why Aren't Virtual Dice Adequate? (John Myre)
Re: Use of two separate 40 bit encryption schemes (fungus)
Re: Why Aren't Virtual Dice Adequate? (Mickey McInnis)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
From: Matt <[EMAIL PROTECTED]>
Subject: Safeboot is it really safe
Date: Thu, 02 Dec 1999 23:13:50 +
Hi,
Which is the better for encription of HDD or partitions
safeboot or PGP for WinNT/Win95/Win98/Win2000
and Linux ?
Regards
Matt
--
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Thu, 02 Dec 1999 23:13:36 GMT
Joseph Bartlo <[EMAIL PROTECTED]> wrote, in part:
>My initial comment is that although an interesting concept, I think the
>entire system must be considered, as do any intelligent modifications
>on it. What does your concept say about a person dropping dry ice in
>a cloud & causing rain ? Or dare I say with the risk of extreme criticism
>of people in the group who evidently feel this is completely impossible,
>that possibly from another being with far greater capabilities ?
>If you are talking about a *perfect* forecast, even if a butterfly flapping
>its wings disturbed the weather 2 weeks later a *known way*, you'd still
>have to know when & where it'd flap its wings :)
No; my post specifically states that while the *butterfly effect* sets
an _irreducible_ limit to forecasting, at present the number of sites
measuring the wind/air pressure/temperature leaves holes big enough
for things to slip through that _don't_ exist to create random
perturbations in the weather.
>Perhaps I'll have more comments after reading & correcting your site.
>Well, I am probably kidding about the latter ;)
My site doesn't really address the topic of this post, however I
flatter myself to think that it _is_ an interesting site none the
less.
John Savard (jsavardecnabca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 2 Dec 1999 23:18:40 -
Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > Anyone who thinks that NSA will get at information in future by
> > breaking such algorithms (rather than their implementations) has not
> > understood the closing of the cryptographic knowledge gap between the
open
> > and closed worlds.
>
> How did you reach the conclusion that "the crypto gap" (shades of the
1950's
> "missile gap") has closed? Why do you believe your supposed gap closing
should
> be obvious?
Becaue it a lesson about technology generally and not about cryptography in
particular. And it stretches back into pre-history. I don't want to bore
people with the details but my expereience has been that technolgies that
start in the closed government world most often migrate into civil
applications where over time more resources are deployed with the result
that the positions of the two worlds reverse.
In my career I have seen the move from defence to civil dominance in a
number of areas - in computer systems, in integrated circuits, in software
operating systems, in high level languages, in computer networking, in
display technologies, and now, in my view, in computer and cryptographic
security.
What happens is that government resources tend to be constrained but can be
spent on things that are not profitable since government does not need to
make money. Government funded developments hence make the early running in
new technology areas. But as civil intersts become clearer and profits
become a driver civil resources get deployed and these are not bounded by
the limits on government expenditure and hence eventually grow to be much
greater in scale. Moreover, since government R&D resources are needed to
make the next breakthrough, once civil investment develops in a technology
area the incentive to put government money into it goes away.
And I see no reason to believe that this pattern will be any different for
cryptographic and security technologies now that the civil world has woken
up to the need for these.
Brian Gladman
--
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Thu, 2 Dec 1999 15:20:17 -0800
"John Savard" <[EMAIL PROTECTED]> wrote ...
: [EMAIL PROTECTED] (Guy Macon) wrote, in part:
: > [EMAIL PROTECTED] (Tim Tyler) wrote:
: > > http://www.io.com/~r
Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #10 Thu, 2 Dec 99 20:13:02 EST
Contents:
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
Re: more about the random number generator (CLSV)
"Fingerprinting" an algorithm? (John Savard)
Re: Any negative comments about Peekboo free win95/98 message encryptor program ?
(Steve K)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
Date: Thu, 02 Dec 1999 19:26:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
John Savard wrote:
> Quantum computers potentially offer the possibility of performing a
> computation in parallel for an enormous number of different
> combinations of input parameters, and then producing a result for only
> one such combination if that combination produces a result that meets
> certain criteria.
>
> This may be useful to extend the range and accuracy of weather
> forecasting.
>
> Although chaos theory sets an irreducible limit to the useful range of
> advance forecasts of weather, based on the growth of random inputs
> caused by nonlinearities in the system,
>
> in practice, the limit imposed by the limitations in the precision and
> detail of input data about the state of the weather at a given moment
> impose a stricter limit.
>
> It is theoretically possible to obtain information about the missing
> components of the state of the Earth's atmosphere at a given time by
> the following technique: for each possible set of values for the state
> of the unobserved part of the Earth's atmosphere, run the equations
> backwards to obtain a long-term "prediction" of the weather on
> preceding days. That hypothetical state of the atmosphere which
> produces the longest-term accurate forecast in the reverse direction
> is the state most likely to be correct.
>
> Quantum computers would seem to directly lend themselves to such a
> computation, should they become practical. (However, the limit on
> search algorithms may be fatal, as even the square root of the number
> of possibilities here is prohibitively large.)
>
> Perhaps there is a mathematical technique possible that avoids such
> extravagance, by working with the state of the weather several days
> ago, and incrementally updating missing parts of the atmospheric state
> in response to forecast errors. The principle would be the same: to
> use the depth of available atmospheric data in time to substitute for
> the lack of detail in our knowledge of the state of the atmosphere at
> any one moment.
A critical threshold exists in all such modeling systems. One must insure
that the error bounds on the modeled state values grow more slowly that
the information gained at each step. In essence, the backward prediction
has to converge.
One may run such a simulation backwards by increments, and thus detect
improbable initial states early in the search. The ability to prune the
state/search space reduces the size of the problem but does not improve
the "convergence" rate.
--
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Fri, 03 Dec 1999 00:24:42 +
Anton Stiglic wrote:
> Brian Chase wrote:
> > Naive question here. Let's say you had access to some "optimum
> > compressor" which would take arbitrary data sets distill them into their
> > most compact form. By definition, the resulting data must have no
> > predictable redundancies, yes?
Correct.
> > Could you use optimally compressed data
> > sets as sources for random numbers?
That would be nice, however optimal compression can not be computed
in reasonable time.
> Your input would have to be random, so might as well just use the input
> (you'd have more bits of randomness).
> If you don't use random input, and I know about the compression algo
> you use, I could just reverse the output (decompress) and look at the
> results. If they don't look random, I know you are not using random inputs,
> and might be able to predict futur outputs.
In Kolmogorov complexity an incompressible string is
as random as you can get. The intuition is that a string that is
optimally compressed has no redundancy or patterns that you can
use to compress it. Because it has not (useful) patterns it is
also random. If you could decompress a string into a larger
random string. That larger string obviously has some patterns
so it isn't random.
Regards,
Coen Visser
--
From: [EMAIL PROTECTED] (John Savard)
Subject: "Fingerprinting" an algorithm?
Date: Fri, 03 Dec 1999 00:41:59 GMT
On 19 Nov 1999 09:21:36 -0700, crippa <[EMAIL PROTECTED]>
wrote in sci.crypt.research:
>Is
Cryptography-Digest Digest #670
Cryptography-Digest Digest #670, Volume #10 Fri, 3 Dec 99 00:13:01 EST
Contents:
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
Re: Encrypting short blocks ("Dan Schwartz")
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: Quantum Computers and PGP et al. (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: The $10,000.00 contesta (Johnny Bravo)
Re: Any negative comments about Peekboo >> how to confirm designer
([EMAIL PROTECTED])
Re: Any negative comments about Peekboo >> How to verify that promised
([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
repeated DH over MOD P (jerome)
Re: NP-hard Problems (Bill Unruh)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 01:09:42 GMT
In article <8274av$hn0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>I trust it's security enough to send a message across irc, but I wouldn't
>choose to use it to say, encrypt my credit card to another person.
This thread has gained enough of my interest to download it, and I'm
generating a key right now - actually it didn't take very long and I have
already made another one so I can use the program with myself. I am a little
puzzled with the above level of trust - since I often hand my credit card over
to all kinds of strangers (for purchases), I personally consider credit card
info encryption to require very little confidence.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
--
From: "Dan Schwartz" <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Thu, 2 Dec 1999 20:36:03 -0500
Markus Peuhkuri wrote in message ...
> What I want is following property: given message M1 (length N
> bits) produces same encrypted message E1 (length N bits) every
> time run. Message M2 produces message E2, which is different
> from E1 iff message M2 is different from M1. However, I'm
> willing to accept some probability of collisions, less than
> 1/1000 (different messages M1 and M2 produce same result E1).
It sounds like you don't need to decrypt the messages, i.e. derive M1 from
E1. If that's the case, just pad each message to a standard block length
(e.g. 64 bits), use any encryption algorithm, and take N bits of the result.
Any good encryption algorithm should produce results that "look" random,
making the likelihood of a collision between any two messages roughly 1 in
2^N.
If you want a very simple algorithm, and don't require super strong
security, check out TEA.
Dan Schwartz
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 20:43:21 GMT
On Thu, 02 Dec 1999 11:36:08 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>There are so many cases of everybody being wrong when someone else is
>right. You honestly cannot reject a single detractor on sight. I assure
>you that I want to see evidence of his claims if possible, or define them
>at least worth more study.
If they have a claim and offer evidence to support this claim, then
we can define the claim as worth more study.
Making a claim and offering no proof other than the assertion "I'm
right, and you are wrong." is not worth further study. This is
because even if you prove that one claim wrong, they will just throw
out more claims. It is easier to make claims that to support or
disprove them, why should the community be tasked with debunking every
crackpot theory that anyone could ever come up with. If you want
people to consider your claims, you need evidence that your claim is
valid.
>The last thing I am going to do is reject
>claims if there is reason to believe that they might be true.
Really? I claim you are a murderer. Given that the other people on
this group don't personally know either of us (and have no idea if I
know you personally or not), there is a reason to believe that it
might be true. So now you should prove to the group that you are NOT
a murderer.
>Being open
>to such things may seem a burden, but it is a requirement nonetheless.
There is no requirement that we should accept spurious claims
without evidence. Logic suggests otherwise.
>Personaly, I have a few rather unpopular ideas myself, backed up by my
>experience; if they prove accurate according to additional data, mine or
>others, I surely will mention them again.
This is where you diverge from the topic of discussion. You are
willing to test your ideas according to existing data. Only when you
are sure t
Cryptography-Digest Digest #671
Cryptography-Digest Digest #671, Volume #10 Fri, 3 Dec 99 06:13:01 EST
Contents:
Re: NP-hard Problems (David A Molnar)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Encrypting short blocks (Markus Peuhkuri)
Re: Encrypting short blocks (Markus Peuhkuri)
how to combine hashes to build a 128-bit key? (Juergen Thumm)
Re: Noise Encryption ("Tim Wood")
Re: brute force versus scalable repeated hashing ("Tim Wood")
Re: brute force versus scalable repeated hashing ("Tim Wood")
Re: more about the random number generator (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: 3 Dec 1999 05:34:33 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (James Pate Williams,
>Jr.) writes:
>>What are some problems that are NP-hard but not NP-complete? I know
> Well, it is not known if there are any NP hard problems. But assuming
> that say factoring is NP hard, I believe it is not NP complete.
This does not match my understanding of NP hard problems at all. :-(
As in "head explodes at reading previous two posts" out of joint
with what I know. Let me write what I think and hopefully we can resolve
this.
>From what I understand :
When we say that a problem P is "NP-hard", we mean that
a) we have a decision problem P defined with respect to some language of
strings L. That is, we have an alphabet $\Sigma$ and a string
$s \in \Sigma^*$ -- a string $s$ consisting of some concatenation
of symbols in the alphabet and of unbounded length -- and we are
asking the question "Is the string s in the language L??"
b) an efficient reduction exists from this problem over L to every other
decision problem P' for an NP-language L'. Let's expand on what
that means :
a "reduction" is a process for rewriting problem questions
for one problem in terms of those for another problem.
In this case, we want something which will let me
take a query for a problem P'
(1) "Is this string s in L' ??"
and `reformat' it such that I can create a new string
and new query like so
(2) "Is this string f(s) in L ??"
(f being some rewriting process or function)
and knowing the answer to query (2) will give me
the answer to query (1).
Put another way - say I know how to solve (2). So I figure
out how to use it to solve (1). What I "do to figure it
out" can be identified with a "reduction."
efficient : means that the reduction takes a polynomial
number of steps in some useful parameter, like the
length of the input.
SO if a problem P is NP-hard, it has this really cool property :
if we can solve P, we can solve all problems in NP.
This is because for every problem in NP, there exists
a reduction which will let us take our method of
solving P and use it to solve anything we want.
Notice at this point that we haven't said anything about whether P is
deciding a language which is actually IN the class NP or not. That's
where NP-complete comes in :
We say a problem is "NP-complete" if it is
a) NP-hard (as above)
b) concerning a language in NP
The NP-complete problem everyone always points to is SATISFIABILITY
: given this logical expression, what values make it true? Karp
showed back in the 70's that you can simulate a universal Turing Machine
by building enough formulae. So SATISFIABILITY is NP-hard.
My confusion at the statement "it is not known if there are any
problems which are NP hard" is that since Karp, lots of ppl have
gone through and shown problems NP-complete and NP-hard in
something like the sense I'm outlining here.
The original question was
"Are there NP-hard problems which are not NP-complete?"
>From my understanding, this is equivalent to :
"Are there problems which would let us solve all other
problems in NP if we could do them easily, but are not
themselves in NP ?"
I think so. Now let me try something I'm not so sure of and try to
give an example.
Consider the problem of enumerating *all* bit-strings of length $k$.
There's $2^k$ of them, so it takes exponential time. Also exponential
space. Let's say you have a magic box which takes one step to
enumerate them all and also search them for whatever you happen to want.
Say you want to see if this string $s$ is in an NP-language L. You
just tell your box to write out EVERY string of length $2^|s|$, strike out
anything n
Cryptography-Digest Digest #672
Cryptography-Digest Digest #672, Volume #10 Fri, 3 Dec 99 11:13:01 EST
Contents:
Re: Encrypting short blocks (Johnny Bravo)
Re: Will ScramDisk recover ? >> After another round of tests ... YES, it will
recover ("Microsoft Mail Server")
Re: Will ScramDisk recover ? >> After another round of tests ... YES, it will
recover (Lincoln Yeoh)
Re: Any negative comments about Peekboo >> how to confirm designer claims ?
(Johnny Bravo)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Johnny Bravo)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Peekboo Ideas? (Lincoln Yeoh)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
How can you tell? (John)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (David A
Molnar)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Encrypting short blocks
Date: Fri, 03 Dec 1999 07:56:16 GMT
On 03 Dec 1999 09:54:04 +0200, Markus Peuhkuri
<[EMAIL PROTECTED]> wrote:
> I'm not sure, but aren't the stream ciphers basicly OTPs where
> the "OTP" is generated depending on the key?
A OTP is only a OTP if a random key is used, stream ciphers don't
use random keys. Pseudo-OTP is commonly used to describe them as the
pad is generated pseudo-randomly.
> And if I use same
> pad for different plaintexts, by guessing/knowing one or some
> of plaintexts, all encrypted data can be decrypted without
> knowing key?
Correct. If you have the plaintext you can just XOR it with the
ciphertext to recover the key. One of the security requirements of
the OTP is that pad data is not reused under any circumstances.
Best Wishes,
Johnny Bravo
--
From: "Microsoft Mail Server" <[EMAIL PROTECTED]>
Subject: Re: Will ScramDisk recover ? >> After another round of tests ... YES, it will
recover
Date: Fri, 3 Dec 1999 08:04:09 -0500
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
the fact that scramdisk retains the essence of boot,fat, data sector
structure is a prime reason it is so durable.
try making two identical container files of moderate size. load some text
files into the svl's for reference points, then swap the boot sector on
each. try swapping the fat structures. very interesting indeed!
--
best regards,
hapticz
>X(sign here)<
[EMAIL PROTECTED] wrote in message
<[EMAIL PROTECTED]>...
|I'm recommending ScramDisk to all the users who have a need to hide and
totally
|secure private computer data as the best product on the market.
|
|After another round of tests, this time with better hex editor, I did find
that
|ScramDisk is very difficult to corrupt [ when not at the beginning of
container
|file ]. My all attempts to porpousedly damage container by editing byte /
bits
|of data proved to be unsuccessful.
|
|In my past test, I did lean to much of my trust on 2 editors for the
changes
|made. The past use editors made changes to the container file in other
places
|than my intention.
|
|After both test made, I'm convinced that ScramDisk will recover [ will NOT
HAVE
|PROBLEM WITH MOUNT OPERATION ] after random bits / bytes are corrupted in
|container file. The above hold true as long as corruption is not in the
system
|part of container.
|
|I would like to apologies to all affected people by my past statements,
that "1
|byte corruption will render container of say 640 MB useless". The statement
is
|not valid to all location of corruption, not valid in generic term.
|
|When the remaining corruption possibility will be removed in the future
versions
|by say [ back up of container system data ], this product will be the best
and
|the safest of all [ file / disk encryption ] products on the market,
|undisputedly.
|--
|Thanks, Richard
|=
|
|Date: Sat, 27 Nov 1999 17:00:47 GMT
|On Thu, 25 Nov 1999 10:02:17 -0500, [EMAIL PROTECTED] wrote:
|>Alter 1 byte without increasing container file size.
|>After altering, I could not mount container [ provided pass / correct pass
/ has
|>not been accepted ].
|
|Dunno, I tried it out, changed a single byte (81 to FF) and I could mount
|it. I'm using 2.02c and blowfish.
|
|I had stored a file inside, and only 9 bytes were changed. Hmm 72 bits
|changed for 6 bits.
|
|What program are you using to change the byte?
|
|As long as you don't alter the first bunch of stuff you should be able to
|mount it.
|
|If you alter the part that happens to be the FAT or directory you may have
|to run scandisk as
Cryptography-Digest Digest #673
Cryptography-Digest Digest #673, Volume #10 Fri, 3 Dec 99 12:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: The $10,000.00 contesta (SCOTT19U.ZIP_GUY)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Safeboot is it really safe (Keith A Monahan)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Peekboo Ideas? (Tom St Denis)
Re: Noise Encryption (Mattias Wecksten)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
RSA ("Brice")
Date: Fri, 03 Dec 1999 10:44:16 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
r.e.s. wrote:
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
> : Mickey McInnis wrote:
> : > "r.e.s." <[EMAIL PROTECTED]> writes:
> [...]
> : > |> In practice, though, who would use a "pure OTP" without
> : > |> further strengthening? (Even if the OTP is theoretically
> : > |> "unbreakable", it seems appropriate to say that any
> : > |> OTP *implementation* can, in practice, be relatively
> : > |> strong or weak.)
> : > |>
> : > |> (I notice that
> : > |> http://www.io.com/~ritter/GLOSSARY.HTM#MessageKey
> : > |> explains how the use of message keys can thwart
> : > |> exactly the type of scenario envisioned above.)
> : > |>
> : > |> --
> : > |> r.e.s.
> : > |> [EMAIL PROTECTED]
> : > |>
> : >
> : > This is a well known and much discussed "weakness" of a one-time-pad.
> : >
> : > A properly used OTP "absolutely" prevents the enemy from determining
> : > the cleartext from the cyphertext by cryptographic means. It doesn't
> : > "absolutely" prevent him from sending a false message that looks
> : > real.
> : >
> : > It can also happen if the enemy can somehow "guess" the cleartext, even
> : > if it's only sent to one correspondent. If the enemy thinks he might
> : > know the text, he could try to substitute text this way and would
> : > send a "proper" message if he guessed right. If he gets it wrong,
> : > the correspondent would get garbage.
> : >
> : > There is another well-known cryptographic "weakness" in OTP and many
> : > other cryptosystems. Unless you pad the messages, the enemy knows the
> : > length of the message.
> : >
> : > I wonder if there's something analagous to an OTP that will provide
> : > the same degree of "absolute" protection from "spoofing" as OTP
> : > does from "breaking".
> :
> : A simple mechanism is to use a shared secret. Assume that in addition
> : to the (large) message key repository each pair of correspondents is
> : given a unique "signature" value. For purposes of illustration this
> : could be small; 64-256 bits. To send an authenic message one appeads
> : the "signature" to the message, encoding it with the keypad. On
> : receipt of a message the decoder unmasks the "signature" region and
> : compares the result with the secret value. Since the premise of the
> : "signature" is that only the sender and receiver known the valid
> : signature value, and because the signature ciphertext is not reused,
> : the message must have come from one of the two inposession of the
> : secret "signature" value. This approach does not prevent replay attacks.
>
> In addition to its other functions, doesn't a message key (as defined
> above) accomplish the same thing as the type of "signature" you describe?
> (It is, after all, a kind of "shared secret", being sent along with the
> enciphered message.)
>
> The message key is created by the sender to be random and unique to each
> transmission, is accessible only to possessors of the primary key, is
> necessary if the decipherment is not to produce garbage, and strengthens
> any stream cipher -- including an OTP -- by helping to ensure that keys
> are really used only once.
What's an "authetic" message key?
The purpose of authenticating a message cannot be addressed by the sender
synthesizing a value that the receiver cannot calculate. Thus a message key
generated by the sender and not already known to the receiver would not
authenticate a message because the receiver has no way to distinguish message
keys selected by the sender from message keys selected by an opponent.
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: The $10,000.00 contesta
Date: Fri, 03 Dec 1999 16:30:58 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On Thu, 02 Dec 1999 15:51:42 GMT, [EMAIL PROTECTED] (Bruce
>Schneier) wrote:
>
>>I think that almost all algorithm designers would be happy to see a
>>new
Cryptography-Digest Digest #674
Cryptography-Digest Digest #674, Volume #10 Fri, 3 Dec 99 14:13:02 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: The $10,000.00 contesta (wtshaw)
Re: Encrypting short blocks (wtshaw)
Re: Quantum Computers and PGP et al. (Medical Electronics Lab)
cookies (E-mail)
Re: Is there an analog of Shor's algorithm for elliptic functions? (Medical
Electronics Lab)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: cookies ("karl malbrain")
Re: What part of 'You need the key to know' don't you people get? ("karl malbrain")
Re: cookies (Steve K)
Re: Peekboo Ideas? >> Oops, problem ... ([EMAIL PROTECTED])
Re: cookies (E-mail)
Re: Peekboo Ideas? >> Oops, problem ... 2nd ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 03 Dec 1999 12:52:04 GMT
On Fri, 3 Dec 1999 15:17:47 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>What if the coins are all heads-biased (quite likely with real coins),
>and the dice are all 1-biased (quite possible if the spots are
>drilled indentations)?
One should assume this type of bias from such a mechanical process,
but it is simple to remove the bias from them. For example, you are
using a coin that comes up heads 90% of the time and tails the other
10%. Pair your tosses, throw out any pair that matches. This will
remove the bias from your results.
With the above biased coin:
TT will show up 1 in 100: Discarded
HH will show up 81 times in 100: Discarded
HT will show up 9 times in 100: Kept
TH will show up 9 times in 100: Kept
Giving you a 50/50 distribution of heads and tails. The less
extreme the bias, the closer you get to keeping 50% of your generated
bits. But even an extremely biased source can be used with this
method, if you are willing to accept the slowdowns involved in
distilling unbiased results from the data. This is where computers
come in, if you can use a computer to generate 1000 biased bits a
second and you only kept 1/10 of them it would not be that bad, you
could generate more than 8 million bits in a day.
>Your "complications" may dilute the biases - but don't remove them.
>
>I would treat any proposed one-time-pad which used dice or coins
>as the basis of its random number generator with some caution - if
>I wanted to leak as little information as possible.
It isn't that hard to generate unbiased coin tosses for example, the
trouble comes from generating them at a rate fast enough to be
practical. With coins you would have to make at least 16 tosses per
byte of data. Flipping enough coins to transfer a megabyte is going
to take a while.
Best Wishes,
Johnny Bravo
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 03 Dec 1999 12:03:25 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
Bravo) wrote:
..
>
> If they have a claim and offer evidence to support this claim, then
> we can define the claim as worth more study.
Surely so.
> Making a claim and offering no proof other than the assertion "I'm
> right, and you are wrong." is not worth further study. This is
> because even if you prove that one claim wrong, they will just throw
> out more claims.
Proof in a scientific sense, I suppose. I consider certain things David
Scott says are true by definition. Others, I'm not sure, but keep an open
mind for now.
> It is easier to make claims that to support or
> disprove them, why should the community be tasked with debunking every
> crackpot theory that anyone could ever come up with.
What if is an important strategy to test your position. Science requires
routine reevaluation of positions, not being prejudiced that any taken are
always to be correct; this works on old ideas as well as new.
> If you want
> people to consider your claims, you need evidence that your claim is
> valid.
Yes, but many in science hold a few hypotheses most dearly, but have no
positive or final proof that they are true; cryptography is full of such
things.
>
> >The last thing I am going to do is reject
> >claims if there is reason to believe that they might be true.
>
> Really? I claim you are a murderer. Given that the other people on
> this group don't personally know either of us (and have no idea if I
> know you personally or not), there is a reason to believe that it
> might be true. So now you should prove to the group that you are NOT
> a murderer.
I will treat you as an unimformed and ignorant youth who has not respect
for the words you speak, else, you can be prosecuted, and/or sued All
that I can do is yeild that blanket statements concerning your status by
David may be in fact correct. Your
Cryptography-Digest Digest #675
Cryptography-Digest Digest #675, Volume #10 Fri, 3 Dec 99 16:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: cookies ("karl malbrain")
Re: Peekboo Ideas? >> Oops, problem ... 3rd ([EMAIL PROTECTED])
Re: Quantum Computers and PGP et al. (Jim Dunnett)
Re: Elliptic Curve Public-Key Cryptography ("Michael Scott")
Question regarding using RSA BSAFE and BCERT (Sridhar Muppidi)
Re: What part of 'You need the key to know' don't you people get? (James Felling)
Re: Peekboo Ideas? >> Oops, problem ... 4rd ([EMAIL PROTECTED])
Re: dictionary (fungus)
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: Peekboo Ideas? >> Oops, problem ... 5rd ([EMAIL PROTECTED])
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: Why Aren't Virtual Dice Adequate? (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? ("Peter K.
Boucher")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 3 Dec 1999 11:07:27 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: r.e.s. wrote:
: > "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: > : A simple mechanism is to use a shared secret. Assume that in addition
: > : to the (large) message key repository each pair of correspondents is
: > : given a unique "signature" value. For purposes of illustration this
: > : could be small; 64-256 bits. To send an authenic message one appeads
: > : the "signature" to the message, encoding it with the keypad. On
: > : receipt of a message the decoder unmasks the "signature" region and
: > : compares the result with the secret value. Since the premise of the
: > : "signature" is that only the sender and receiver known the valid
: > : signature value, and because the signature ciphertext is not reused,
: > : the message must have come from one of the two inposession of the
: > : secret "signature" value. This approach does not prevent replay
attacks.
: >
: > In addition to its other functions, doesn't a message key (as defined
: > above) accomplish the same thing as the type of "signature" you
describe?
: > (It is, after all, a kind of "shared secret", being sent along with the
: > enciphered message.)
: >
: > The message key is created by the sender to be random and unique to each
: > transmission, is accessible only to possessors of the primary key, is
: > necessary if the decipherment is not to produce garbage, and strengthens
: > any stream cipher -- including an OTP -- by helping to ensure that keys
: > are really used only once.
:
: What's an "authetic" message key?
A thing is "authentic" if it is what it's claimed to be.
In our context, this means it hasn't been surreptitiously
altered in-transit.
In the scenarios under discussion, a message key is inserted
into the ciphertext in a way that makes it accessible only
to those who know the relevant part of the primary key --
"ciphertext within ciphertext" so to speak.
: The purpose of authenticating a message cannot be addressed by the sender
: synthesizing a value that the receiver cannot calculate.
The receiver *does* calculate it, because some bits of the
primary key -- unknown to the opponent -- serve to do just
that, viz, to extract it from the transmitted ciphertext.
: Thus a message key
: generated by the sender and not already known to the receiver would not
: authenticate a message because the receiver has no way to distinguish
message
: keys selected by the sender from message keys selected by an opponent.
In the scenarios under discussion, an opponent cannot
introduce a message key of his own making because he doesn't
have the key for inserting it into the ciphertext.
--
r.e.s.
[EMAIL PROTECTED]
--
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Fri, 3 Dec 1999 10:00:05 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
: [EMAIL PROTECTED] (r.e.s.) wrote:
:
: >In practice, though, who would use a "pure OTP" without
: >further strengthening? (Even if the OTP is theoretically
: >"unbreakable", it seems appropriate to say that any
: >OTP *implementation* can, in practice, be relatively
: >strong or weak.)
:
: Maybe it's my background as an engineer, but if I was actually
: implementing an OTP (instead of using PGP and just discussing
: OTP as a learning experience), I would go full overkill on the
: randomizer, XORing in everything from the number of microseconds
: between keystrokes to a the digitized output of my local AM
: station, the theory being that if any one of my "random" inputs
: is true random, the O
Cryptography-Digest Digest #676
Cryptography-Digest Digest #676, Volume #10 Fri, 3 Dec 99 17:13:02 EST
Contents:
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: How can you tell? ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Eric Lee Green)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Peekboo Ideas? >> Question ... ([EMAIL PROTECTED])
Re: cookies ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: cookies ("karl malbrain")
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 03 Dec 1999 14:02:07 -0700
"SCOTT19U.ZIP_GUY" wrote:
>
> In article <[EMAIL PROTECTED]>, "Brian Gladman"
><[EMAIL PROTECTED]> wrote:
> >
> >Jim Gillogly <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Keith A Monahan wrote:
> >> > My concern is that if they DID break one of the algorithms and
> >> > didn't tell us(or NIST) about it. I don't know how likely that
> >> > is, but it is certainly a possible case.
> >> >
> >> > It wouldn't be _as_ bad as if the NSA broke it, told us about it,
> >> > but didn't tell us how. That would still keep me wondering, but
> >> > at least we'd know the cipher isn't secure. Even without telling
> >> > us how they did it, we might be able to draw some conclusions about
> >> > ciphers of that same nature.
> >>
> >> If they say they broke it and demonstrate that they can break an
> >> arbitrary challenge, then I agree that's useful information. If
> >> they say they have an attack that reduces a 128-bit keyspace to
> >> a 70-bit keyspace, I'd want to see the attack before making a
> >> decision to eliminate the candidate. Sorry if this appears paranoid,
> >> but we must always remember that NSA has two responsibilities: to
> >> read traffic, and to protect US infrastructure (mainly military).
> >> If you're going to accept their help uncritically, you'd better
> >> know which side of the house is giving it to you. There's no
> >> question that they could provide valuable insight on the candidates;
> >> the only question is how they can convey it credibly.
> >
> >As others have said, those that distrust NSA are not going to be swayed by
> >their arguments but for those of us who believe that they are a force for
> >good in respect of the strength of cryptographic algorithms would consider
> >what they have to say very seriously. I also believe that they should say
> >something and I don't see much reason why they should not do so this time
> >round.
> >
> >In retrospect, all the ***covert*** actions that NSA took on DES improved
> >the algorithm and it is not obvious why they would behave differently now.
> >The US is the most advanced 'information economy' in the world and this
> >means that the US has more to loose than anyone if AES turns out to be weak.
> >And this also allows those of us outside the US to trust AES since we are in
> >a sort of 'Mutually Assured Destruction (MAD) situation' where any NSA
> >action to bring us down would bring the US down as well.
> >
> >NSA did reduce the key length of DES from 64 to 56 bits and many thought
> >that this was so that they could break it but I very much doubt this. Given
> >the technology available at the time, and their 'volume' cracking needs, I
> >cannot see that this conclusion stands up under retrospective scrutiny.
> This is one fact where your wrong the design of MECL logic boards
> was will known at that time. It would be foolish to think they did not build
> hardware to conviently break the 56 bit keys.
> >
> >Although I do not know the answer here, I suspect what it might be. My
> >guess is that NSA were breaking much poorer algorithms than DES at the time
> >and desperately needed a way of convincing their targets not to move to DES.
> >The key length reduction, leaving people to draw the (wrong) conclusions,
> >was a masterful bit of psychological warfare that did exactly this.
> You have got to be joking. Who would belive such nonsense.
> >
> >As a result of this brilliant deception I suspect that NSA targets went on
> >using broken algorithms for years even though a great algorithm - DES - was
> >right in front of their very eyes. And the fact that DES was strong and yet
> >seemed to outsiders to be weak provided a rare occasion in which the good
> >guys were able to 'have their cake and eat it' by being able to use DES for
> >true protection while ensuring that the bad guys were far too suspicious of
> >it to ever contemplate its use.
> You are not even close to reality.
> >
> >The sad fact is that computer sec
Cryptography-Digest Digest #677
Cryptography-Digest Digest #677, Volume #10 Fri, 3 Dec 99 19:13:01 EST
Contents:
Re: Peekboo Ideas? >> Question ... (Steve K)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tom McCune)
iaPCBC: confidentiality and integrity in one shot (James Muir)
Re: NSA should do a cryptoanalysis of AES (Shawn Willden)
Re: Why Aren't Virtual Dice Adequate? (Mickey McInnis)
Re: Peekboo Ideas? >> Question ... (Keith A Monahan)
Re: cookies (SCOTT19U.ZIP_GUY)
Re: Simpson's Paradox and Quantum Entanglement (John R Ramsden)
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: smartcard idea? (Shawn Willden)
Re: Use of two separate 40 bit encryption schemes (Shawn Willden)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
Re: Encrypting short blocks ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Peekboo Ideas? >> Question ...
Date: Fri, 03 Dec 1999 22:18:43 GMT
On Fri, 03 Dec 1999 16:26:17 -0500, [EMAIL PROTECTED] wrote:
>Question
>
>When you are creating password with 'Use Key' is this operation creating THE
>SAME password for the same public + private keys selected, time after time ?
Oboy, I know that one!
No. There was some discussion of PRNG implementation during shared
secret generation, in the PB e-list.
Hopefully Tom will have his system back up & online pretty soon; until
then, the only living Peekboo expert is incommunicado. Maybe folks
could consolidate their questions & hold off 'till Tom shows up on the
network again? Then you could get timely answers, I bet.
:o)
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
--
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Fri, 03 Dec 1999 22:29:19 GMT
In article <828lod$kv5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Keith A
Monahan) wrote:
>The fact of the matter is that your card can be comprised ANY PLACE, whether
>it be locally, over the wire, at the company, at the credit card verification,
>etc. If I would place orders online, I would be trying to LIMIT my
>susceptibility to attack, and by ensuring a decent encryption package is
>in use, I could do that.
>
>Is this more clear?
Thanks Keith,
You give the credit card level of security a higher rating than I do, so that
speaks better of your confidence in the software than if I had made that
statement.
-Tom
I use PGP for Privacy and Authenticity:
http://www.Tom.McCune.net/PGP.htm
--
From: James Muir <[EMAIL PROTECTED]>
Subject: iaPCBC: confidentiality and integrity in one shot
Date: Fri, 03 Dec 1999 22:16:09 GMT
iaPCBC stands for integrity aware plaintext ciphertext block chaining.
It's been proposed as a new mode of operation for block ciphers. It
claims to provide data confidentiality and integrity with one
cryptographic operation. See
http://www.research.att.com/~smb/papers/iapcbc.ps
http://www.research.att.com/~smb/papers/draft-bellovin-iapcbc-00.txt
for a complete description.
Has anyone analyzed iaPCBC yet? If so, can someone point me to the
analysis?
-James
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Date: Fri, 03 Dec 1999 15:31:34 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
"Douglas A. Gwyn" wrote:
> This points up a supremely important fact: Real computer security
> has to be built in from the ground up, with no loopholes anywhere.
> You could probably achieve it with a capability-based architecture
> and extremely good security review throughout system design, but
> even so, at some level some user will screw up and hand over the
> keys to an untrustworthy agent.
Could you explain what you mean by a "capability-based" architecture? I've puzzled
over the term a bit and I can't figure out what you mean by it. Whose capability
and for what? And how does it relate to architecture?
Thanks,
Shawn.
--
From: [EMAIL PROTECTED] (Mickey McInnis)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 3 Dec 1999 22:40:40 GMT
Reply-To: [EMAIL PROTECTED]
snews.austin.ibm.com> <[EMAIL PROTECTED]> <828rmr$[EMAIL PROTECTED]>
Organization:
Keywo
Cryptography-Digest Digest #678
Cryptography-Digest Digest #678, Volume #10 Fri, 3 Dec 99 22:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: ENIGMA verification ([EMAIL PROTECTED])
Re: How can you tell? (Milo Yanker)
Re: Any negative comments about Peekboo free win95/98 message encryptor (David A
Molnar)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tony L.
Svanstrom)
Re: Why Aren't Virtual Dice Adequate? (Scott Nelson)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Vernon Schryver)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: cookies (Yoni Kramel)
Re: NSA should do a cryptoanalysis of AES (John Savard)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us (albert)
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Dec 1999 23:41:26 GMT
In sci.crypt Johnny Bravo <[EMAIL PROTECTED]> wrote:
: On Fri, 3 Dec 1999 20:02:59 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
[snip removal of bias]
:>Other types of deviation from random behaviour are quite possible:
: As are other methods for eliminating various types of bias. You can
: get x unbiased bits from y flips if you distill them enough [...]
It does not look like we are going to reach agreement. I doubt that
you can ever get even one unbiased bit. It does not matter how many
bits you combine, or what techniques you use. Even if you were given a
large stream of bits with entropy 1.0, you would have no way of
verifying the fact.
I fear if the discussion continues in this vein, we will wander from the
relevance to cryptography.
What practical people are concerned with is whether or not it is possible
to build an OTP that's secure enough for the messages they're trying
to convey, against their real-world opponents.
While I don't think this is necessarily an easy target, I would generally
grant that it may be an attainable one, if enough energy is expended
on the problem.
Whether you can get "perfect randomness" in reality is a bit of a
philosophical issue.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Department of Redundancy Department.
--
From: [EMAIL PROTECTED]
Subject: Re: ENIGMA verification
Date: Fri, 03 Dec 1999 23:44:52 GMT
David Hamer <[EMAIL PROTECTED]> wrote:
> One well know example is to be found in the article: "The
> Turing Bombe: Was it Enough", Deavours, C.A. & Louis
> Kruh, Cryptologia XIV(4), pp 331-349, 1990.
Thanks!
I originally asked the question because I could not solve "The Code
Book"'s "Stage 8" cryptogram ... yet when I made up my own cryptograms,
I could solve them easily and quickly. So I was wondering if my
"engine" was doing the Right Thing.
However, it turns out that a few hours after I posted my original query,
I figured out the problem [my simulation was, in fact, correct], and
solved the cryptogram.
>[graphical simulators]
Yeah, I found alot of those on the web. Unfortunately, all of them
lacked a certain convenience for my application, even if they were fast
enough. The most useful information I found was, in fact, on your
web-page, filed under "Notes for people who want to make their own
simulators".
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Milo Yanker)
Subject: Re: How can you tell?
Date: Fri, 03 Dec 1999 23:52:33 GMT
John <[EMAIL PROTECTED]> wrote:
>Say you had an encrypter and no source. How would you go about
>verifying it?
I wouldn't bother. I would delete it and get one with open source.
--
"Milo Yanker" is actually [EMAIL PROTECTED] (0178 654239).
0123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
--
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: 3 Dec 1999 23:56:01 GMT
In sci.crypt Keith A Monahan <[EMAIL PROTECTED]> wrote:
> David,
> Thanks for the response.
No problem. Just wanted to point out that there are various axes of
"trust". and some of them are orthogonal. :-)
> problems. I always read companies' privacy/security policies online and
> they always talk about SSL encryption and blah blah. But you KNOW alot
> of these companies store your credit card info in plaintext on some
> networked NT server, or even worse, plaintext on a unix box.
Yeah. This is why SET still seems interesting to me; the idea of doing
credit card transactions (if you _must_ do credit cards) without
storing the card # anywhere is a Good Idea. Too
Cryptography-Digest Digest #679
Cryptography-Digest Digest #679, Volume #10 Sat, 4 Dec 99 01:13:00 EST
Contents:
Re: NP-hard Problems (Scott Fluhrer)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Dmitriy Morozov)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: cookies ("Trevor Jackson, III")
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
Re: Any negative comments about Peekboo free win95/98 message encryptor ("Trevor
Jackson, III")
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Steve K)
Re: NP-hard Problems (David A Molnar)
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Sat, 04 Dec 1999 03:40:48 GMT
In article <827kp9$7to$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
>
>The original question was
>
> "Are there NP-hard problems which are not NP-complete?"
>
>From my understanding, this is equivalent to :
>
> "Are there problems which would let us solve all other
> problems in NP if we could do them easily, but are not
> themselves in NP ?"
>
>
>I think so. Now let me try something I'm not so sure of and try to
>give an example.
Better example: the halting problem.
This is obviously NP-hard, because for any problem in NP, you can
obviously construct a problem that will halt iff the string is in
the language.
This is obviously not in NP, because all problems in NP are
computable, and the halting problem is not.
>Just as an aside -- factoring is not known to be NP-complete. Neither
>is discrete log. This means an efficient means of solving the factoring
>problem may not imply that any other problems (besides RSA and other
>useful cryptosystems) are easy. Ditto for discrete log.
>
>At the same time, it's the cryptosystems which are based on these
>peculiar "we don't know" problems which persist. While the systems
>based on NP-complete problems like knapsacks and lattice basis
>reduction haven't done nearly as well. Weird...
Well, AFAICT, the attacks on knapsacks and lattice basis reduction
systems were not done by attacking the general problem, but instead
finding the trapdoor that the private key used. So, they managed
to avoid confronting the "hard" problem directly.
--
poncho
--
From: [EMAIL PROTECTED] (Dmitriy Morozov)
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo >> How to verify that promised
algorithms are included
Date: Sat, 04 Dec 1999 03:49:41 GMT
[EMAIL PROTECTED] (Johnny Bravo) wrote:
>On Thu, 02 Dec 1999 21:46:15 -0500, [EMAIL PROTECTED] wrote:
>
>>How to verify that promised algorithms are included when no link
>>between source & executable can be establish ?
>
> Compile your own executable. This is true for all crypto software,
>even PGP.
Well, there is a little problem. I downloaded the source code offered on the
web site. First of all, the name was kind of strange (pb_backup.zip) but that's
Ok. The main question is why does readme file included in the archive say
Peekboo V1.3. The only explanation (logical explanation) would be that the
source is for version 1.3. But then that means that what you see is NOT what
you get. More of that according to the site the encrypted files produced by the
version 1.70 and earlier are not compatible with later versions; so even if you
are successful in compiling the code (which I wasn't - though I didn't try very
hard) what you get won't be the executable you can download, more of that even
the encrypted files won't be compatible with the ones produced by
the executable.
And that's where my problem with Peekboo arises. There does not seem to be a
concept behind it. No structure... The files that were produced by versions <=
1.70 are not compatible with the ones produced by those > 1.70. The question
arises how well are things "thought through", is it possible that in the future
another incompatibility will be introduced (to add something else). If Tom has
message format and any idea of what might be added and how compatibility will
be preserved in future versions (and I'm pretty sure he does, at least I would
expect it to be so), then in my opinion it would be logical to publish it (on
the web site), and if he doesn't then there is no point in hoping for a big
future for this program.
And that's where the main thing that I cannot understand comes. Ok, I see an
idea behind it: make your own cryptographic application, make it small so it
would be easy to use and transport - and that's fine and actually kinda
interesting, but the question is why can't one make it, for example, OpenPGP
compatible. Not the whole thing, some of the things required for peekboo are
not defined there (though there are plenty of numbers-identifiers reserved for
your own "algorithms"),
Cryptography-Digest Digest #680
Cryptography-Digest Digest #680, Volume #10 Sat, 4 Dec 99 10:13:01 EST
Contents:
Re: smartcard idea? ("Lyal Collins")
Re: Any negative comments about Peekboo free win95/98 message encryptor ("Lyal
Collins")
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Quantum Computers and Weather Forecasting (Rodney Blackall)
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: What part of 'You need the key to know' don't you people get? ("Rick Braddam")
Literature on secure systems engineering methodology--pointers needed (The Bug
Hunter)
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Sat, 4 Dec 1999 18:28:44 +1100
Batteries may not be a problem.
Some of the new polymer batteries (I think it's polymer) are used to form a
battery from the plastic carrier of the Smarctard.
Several audio smarctards are now on the market as a result - Elva, and
Telysys being 2.
Lyal
Shawn Willden wrote in message <[EMAIL PROTECTED]>...
>anonymous intentions wrote:
>
>> Unless of course you create a rechargeable device in the HID
proximity
>> card, but then you have the issue of spoofing via RF. Contactless isn't
such
>> a great idea even if it is only transmitting a session hash.
>
>I don't think there's anything inherently weak about contactless
>communications. Even with contact-based communications, we always assume
that
>an attacker can see and/or modify all of the messages. The problem with
>current-generation contactless cards is that they use weak crypto. The
reason
>they do is because the current induced by the RF field is too weak to power
a
>current-generation processor capable of performing DES operations in a
>sufficiently short time. With good cryptographic algorithms that are more
>efficient (AES) and more power-efficient processors contactless cards will
>become useful for applications that require relatively good security.
>
>> Contacts would
>> be better if they contained a pin on-board the card itself or on an
>> interpreter module on the card in which the PIN would never leave the
card
>> or IM itself. Even better than that is a biometric thumbstamp that would
>> activate PIN access on the card interpreter.
>
>Yes, a biometric device on the card itself is a very good idea, and there
are
>such card-embeddable devices available on the market. I don't know how
much
>they cost or what limitations they might have, but assuming there are no
>significant problems, I think a thumbprint reader on the card is ideal. It
>provides very easy to use, high-quality authentication without compromising
the
>user's privacy (by causing his or her fingerprint to be stored in a
database
>somewhere).
>
>Shawn.
>
--
From: "Lyal Collins" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Sat, 4 Dec 1999 18:30:17 +1100
Not only does SET suck, but your local machine does store the CC # in
recoverable format.
Lyal
Tony L. Svanstrom wrote in message
<[EMAIL PROTECTED]>...
>David A Molnar <[EMAIL PROTECTED]> wrote:
>
>> Yeah. This is why SET still seems interesting to me; the idea of doing
>> credit card transactions (if you _must_ do credit cards) without
>> storing the card # anywhere is a Good Idea. Too bad that a previous
>> thread here suggests that it's unworkable in practice...
>
>It really is useless, the idea is good, but SET sucks.
>
>
> /Tony
>--
> /\___/\ Who would you like to read your messages today? /\___/\
> \_@ @_/ Protect your privacy: \O/ \O/
--
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 04 Dec 1999 04:18:41 EST
In article <8294di$5a0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (r.e.s.) wrote:
>
>"Guy Macon" <[EMAIL PROTECTED]> wrote ...
>:
>: Maybe it's my background as an engineer, but if I was actually
>: implementing an OTP (instead of using PGP and just discussing
>: OTP as a learning experience), I would go full overkill on the
>: randomizer, XORing in everything from the number of microseconds
>: between keystrokes to a the digitized output of my local AM
>: station, the theory being that if any one of my "random" inputs
>: is true random, the OTP will be random. I would then pad my
>: plaintext to a standard length an
Cryptography-Digest Digest #681
Cryptography-Digest Digest #681, Volume #10 Sat, 4 Dec 99 16:13:01 EST
Contents:
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Literature on secure systems engineering methodology--pointers (CLSV)
Re: Literature on secure systems engineering methodology--pointers (The Bug Hunter)
NSA competitors (CLSV)
Re: Literature on secure systems engineering methodology--pointers (CLSV)
Re: NP-hard Problems (Bill Unruh)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Cryptological discovery, rediscovery, or fantasy? (Brian Chase)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Lame I.
Norky)
1 round Defeats Enigma attacks (UBCHI2)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: cookies (Brian Chase)
DNA based brute-force attacks? (Brian Chase)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 15:27:03 GMT
Rick Braddam <[EMAIL PROTECTED]> wrote:
: BTW, the thread so far seems to have concentrated on CBC and CFB.
: I've seen little mention of OFB. Does it have the same limited
: scope of affect (2 blocks) as the other two, in spite of its
: resemblance to a stream cipher?
Plaintext information is confined to individual blocks with OFB.
Errors are confined to the block in which they occur.
There's no diffusion of plaintext information between blocks at all.
:> An all or nothing method is more secure vs. these forms of attack.
:> However, the three letter methods do not weaken the underlying code,
:> they merely fail to strengthen it.
: If they fail to strengthen it, then they have failed to satisfy the
: objective for using them, haven't they?
They do strengthen it against some forms of attack. However they fail to
strengthen it against others, and it is those that are the subject here.
: If an all or nothing method is more secure, is the difference in degree
: of security a significant amount?
Unfortunately, the answer to this depends on all sorts of things.
You'd probably have to do a cost-benefit analysis of your circumstances
before being able to make a firm decision.
Security benefits are notoriously hard to quantify, so the value
of hinderance against a certain range of attacks may be hard to put a
figure on.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
May all your PUSHes be POPed.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 15:37:13 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
:> : You have just discovered true randomness.
:>
:> Alas, even *if* this is genuinely random - which you will never
:> demonstrate - nobody has developed a scheme for extracting this
:> information onto a macroscopic scale without introducing bais of
:> one type or another.
:>
:> Until such a scheme is demonstrated, "true atomic randomness" is
:> of the same utility to a cryptographer as a "perfectly straight line"
:> is to a student of geometry.
: I think you have taken a misguided position and are struggling too much to
: defend it.
Whereas your position appears to be based on faith in the existence of
genuine randomness in subatomic behaviour, and in our ability to
magnify this up to a macroscopic scale, without distorting it at all.
: I think that a very good true random demonstration would be to generate a
: single photon and direct it through a tiny hole. Where it strikes a screen
: on the other side of the hole will be unpredictable within the possible field
: in which it may strike.
I can't predict it /exactly/ - but I know that it will be more likely to
hit near the centre of the field near the edges, and that there will be
radial fringes of probability distribution relating to where it is likely
to hit.
How yo you propose using this source of information to generate a
genuinely random bitstream?
What equipment will you use, and how will it be set up?
Will you use polarised light? Light with random polarisation?
What frequency is your light source? Is it from a lazer?
Is it projecting through a perfect vacuum?
What shape is your "small hole"?
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
COBOL programs are an exercise in Artificial Inelegance.
---
Cryptography-Digest Digest #682
Cryptography-Digest Digest #682, Volume #10 Sat, 4 Dec 99 19:13:01 EST
Contents:
Archive (Arthur Dardia)
Re: NSA should do a cryptoanalysis of AES (Brian Chase)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: Any negative comments about Peekboo free win95/98 message encryptor ("Trevor
Jackson, III")
Re: DNA based brute-force attacks? (James Pate Williams, Jr.)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Elliptic Curve Public-Key Cryptography (Bodo Moeller)
Re: Archive (Scott Nelson)
Re: NSA competitors (John Savard)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Any negative comments about Peekboo free win95/98 message encryptor (Lame I.
Norky)
Re: Archive (Lame I. Norky)
Re: Archive (Lame I. Norky)
Re: NSA should do a cryptoanalysis of AES (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: NSA should do a cryptoanalysis of AES (John Savard)
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Archive
Date: Sat, 04 Dec 1999 16:04:04 -0500
I've searched deja.com, but I cannot find the thread that occured about
1 or 2 months ago on the programmer who needed our help to get his job
by writing a program that calculates the number of perfect shuffles
needed to return a deck of n cards to the original order. I want to
re-read this thread. Any ideas?
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Keyhttp://www.webspan.net/~ahdiii/ahdiii.asc
--
From: [EMAIL PROTECTED] (Brian Chase)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sat, 4 Dec 1999 21:47:07 GMT
In article <829ohn$lea$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>(My shock and horror at discovering that Lampson had gone over to the
>Dark Side was mitigated by observing that he seems to be physically more
>than 3000 miles away from Redmond. Also, maybe he'll do some good, such
>as teaching the people responsible for ActivX that authentication is not
>the same as authorizationno, never mind.)
Speaking on matters of paranoia, my particular paranoid tendencies seem to
note that Microsoft hires up quite a few of the computing history greats.
I don't really see that they're making use of this talent as is evidenced
by the really horrible quality products Microsoft puts out. The only
conclusion I've been able to reach is that Microsoft hires these people to
keep them off the market, doing otherwise productive work which might
compete with Microsoft interests.
The more I find out about the design weaknesses of Microsoft products, the
more convinced I am that Microsoft's presence in this world is adversely
effecting the progress of humanity. I really hate them.
-brian.
--
--- Brian Chase | [EMAIL PROTECTED] | http://world.std.com/~bdc/ -
For these reasons, and hundreds of others, I am forced to conclude that a
virtual frog is not as much fun as an actual frog. -- K.
--
Date: Sat, 04 Dec 1999 17:07:43 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
r.e.s. wrote:
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
> : r.e.s. wrote:
> [...]
> : > In the scenarios under discussion, an opponent cannot
> : > introduce a message key of his own making because he doesn't
> : > have the key for inserting it into the ciphertext.
> :
> : What does hiding a block cipher under an OTP buy you that the OTP alone
> does
> : not? In what sense is your message kay a key to the message if it is not
> a key
> : to a hidden cipher?
>
> The point under discusssion in the thread is that a "pure OTP" is
> not secure when used to send identical plaintext to two different
> recipients, because it may compromise the key of one of them. Any
> addition or change to the OTP, serving to remedy this, will result
> in something other than a "pure OTP". Adding a mesage key is just
> one possible attempted remedy.
As a matter of fact your premise is invalid. An OTP is secure when sending
indentical plaintext's to two different recipients. By secure I mean one
cannot recover the plaintext from the ciphertext. You seem to be enlarging the
term secure to include other kinds of attacks. Naturally, is is not secure in
any sense when the opponent can obtain a copy of the key. It is not secure in
the sense of authentication if the opponent can obtain a copy of the plaintext
by stealing it before it is sent or by stealing it after it is received.
An attack by theft of the plaintext is hardly an attack upon the cipher.
if such an attack were mounted against a fielded system, authentication is the
least of the attendant problems. Anyone who can obtain the plaintext of a OTP
message is not going to betray that capability by forging a messa
Cryptography-Digest Digest #683
Cryptography-Digest Digest #683, Volume #10 Sat, 4 Dec 99 23:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Dmitriy Morozov)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Random Noise Encryption Buffs (Look Here) (Brian Chase)
Re: Why Aren't Virtual Dice Adequate? (Scott Nelson)
Re: Simpson's Paradox and Quantum Entanglement (Brian Chase)
Re: Distribution of intelligence in the crypto field (David A Molnar)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: What part of 'You need the key to know' don't you people get? (Brian Chase)
Re: What part of 'You need the key to know' don't you people get? (Brian Chase)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Steve K)
Re: more about the random number generator (William Rowden)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Dec 1999 00:14:48 GMT
In sci.crypt Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
: if such an attack were mounted against a fielded system, authentication is
: the least of the attendant problems. Anyone who can obtain the plaintext
: of a OTP message is not going to betray that capability by forging a
: message to an alternate recipient. [...]
They /might/ do, if they know that they obtained the message they have by
a one-off set of circumstances, or if they think it is the last message,
or they believe that the forgery will not be detected, or if the risk of
discovery is worth the benefits the altered message it may bring.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Never call a man a fool. Instead, borrow from him.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Sun, 5 Dec 1999 00:31:38 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:> Iron bars are also expensive. If iron bars were free, and no more hassle
:> to lock and unlock than an ordinary door, I'm sure more people would use
:> them, even if the attack they are protecting against (a lockpicking
:> attack) are not known to be common.
: Iron bars are cheap, and ugly.
OK. I guess the problems are that they can't be unlocked from the
outside, they refuse to work as a latch, and are more effort than
necessary to lock, and aren't terribly child-friendly.
Consequently, as a minimum, you likely need a secure keyed lock as well.
Goodness knows where this leaves the analogy ;-)
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Microsoft announces EDLIN for windows.
--
From: [EMAIL PROTECTED] (Dmitriy Morozov)
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo >> How to verify that promised
algorithms are included
Date: Sun, 05 Dec 1999 00:44:07 GMT
Thanks for the response, Steve. I appreciate the link.
--
Dmitriy Morozov
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Steve K) wrote:
>I think many of these questions are answered by the observation that
>Peekboo is under active development; Tom has solicited help in both
>software development and cryptanalysis, on the Peekboo e-list.
>
>For loads o' info on Peekboo's development to date, log in at
>
>http://www.egroups.com/register?url=/vote%3flistname%3dpeekboo%26m%3d1
>
>
>While it is certainly intended to work securely as is, Peekboo is
>still under development. Tom has indicated a willingness to add
>developers to the Peekboo project, to make the source code easier to
>port across OS platforms, and to aid and abet cryptanalysis efforts.
>
>Of course this is just what I have read, and I can't speak for Tom.
--
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sat, 4 Dec 1999 17:02:13 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
: [EMAIL PROTECTED] (r.e.s.) wrote:
: >The point under discusssion in the thread is that a "pure OTP" is
: >*not* secure when used to send identical plaintext to two different
NOTE^^^
: >recipients, because it may compromise the key of one of them. Any
: >addition or change to the OTP, serving to remedy this, will result
: >in something other than a "pure OTP".
:
: I must be missing something here (probably a lack on my part).
: Let's say that A uses pure OTP to send identical pl
Cryptography-Digest Digest #684
Cryptography-Digest Digest #684, Volume #10 Sun, 5 Dec 99 02:13:01 EST
Contents:
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: Why Aren't Virtual Dice Adequate? ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Why Aren't Virtual Dice Adequate? (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Distribution of intelligence in the crypto field ("Douglas A. Gwyn")
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Why Aren't Virtual Dice Adequate? (Scott Nelson)
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: more about the random number generator ("Douglas A. Gwyn")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
Re: 1 round Defeats Enigma attacks (Mike Field)
Re: Encrypting short blocks (Volker Hetzer)
Help ([EMAIL PROTECTED])
Re: more about the random number generator (Brian Chase)
Re: 1 round Defeats Enigma attacks (JTong1995)
Re: more about the random number generator (Brian Chase)
From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Sat, 04 Dec 1999 23:15:37 -0500
Another correction
Joseph Bartlo wrote :
> I doubt as a meteorologist (quality of which I won't likewise minimize
Should be
I doubt as a meteorologist (quality of which I wont likewise
minimize
Geez this game of trying to confuse other people can be tough
Joseph
httpwwwvoicenetcom
jbartlo
[EMAIL PROTECTED]
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sun, 05 Dec 1999 05:19:18 GMT
Scott Nelson wrote:
> He can't read the message, but he knows it's his
> deposit transaction so he modifies the byte
> corresponing to the most significant digit
> of his deposit, and passes the modified message on to
> the main office. Then he goes to the main office
> and withdraws all the money he just "deposited."
That's why such transactions should include a secure hash
(message digest) or other means of authentication.
It again points out a vulnerability of Key Generator systems,
which I've mentioned before. You really ought not to use a
cryptosystem that allows recovery of the key via known PT.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sun, 05 Dec 1999 05:25:01 GMT
"Douglas A. Gwyn" wrote:
> ... Similarly for one-on-one compression, which at
> best foils brute-force key searching, which should not be
> feasible for any good system anyway.
I should point out that this was specifically addressing the
"one-on-one" aspect; precompression in general does foil more
sophisticated cryptanalytic attacks by reducing the statistical
clues that might otherwise "shine through" the encryption.
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sun, 05 Dec 1999 00:28:00 GMT
On Sun, 05 Dec 1999 02:22:39 GMT, [EMAIL PROTECTED] (Scott Nelson)
wrote:
>Mallet opens an account at Second National Bank,
>which sends branch transactions encrypted with OTP.
>He deposits a tiny amount of cash in a branch office,
>and intercepts the next message sent to the main office.
>He can't read the message, but he knows it's his
>deposit transaction so he modifies the byte
>corresponing to the most significant digit
>of his deposit, and passes the modified message on to
>the main office. Then he goes to the main office
>and withdraws all the money he just "deposited."
The main office reads the message digest at the end of the message,
notices that the message has an error and sends a message back to the
branch office to retransmit the message.
Mr Mallet goes to the main office and withdraws all his money, the
exact same amount he started with. They apologize that they aren't
meeting his banking needs and wish him a nice day.
Just because a OTP allows a bit flipping attack doesn't mean you
can't protect against it via other means without reducing the security
of the OTP.
Best Wishes,
Johnny Bravo
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES, What Pi has taught us
Date: Sun, 05 Dec 1999 05:38:33 GMT
albert wrote:
> ... As soon as you think of an idea that is revolutionary,
Cryptography-Digest Digest #685
Cryptography-Digest Digest #685, Volume #10 Sun, 5 Dec 99 12:13:02 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
NEMA missing a plugboard? (UBCHI2)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: 1 round Defeats Enigma attacks (David Wagner)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: 1 round Defeats Enigma attacks (UBCHI2)
Re: 1 round Defeats Enigma attacks (John Savard)
Re: Why Aren't Virtual Dice Adequate? (LVRWCT)
Re: NEMA missing a plugboard? (John Savard)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Distribution of intelligence in the crypto field (CLSV)
Re: NSA should do a cryptoanalysis of AES (Sander Vesik)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: Use of two separate 40 bit encryption schemes ([EMAIL PROTECTED])
Re: DNA based brute-force attacks? (Boaz Lopez)
The leading university of cryptography ([EMAIL PROTECTED])
Re: Elliptic Curve Public-Key Cryptography (Bodo Moeller)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us (Bruce Schneier)
Re: Distribution of intelligence in the crypto field (CLSV)
Re: The leading university of cryptography (David A Molnar)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us (CLSV)
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: Sat, 4 Dec 1999 23:23:32 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
[...]
: The sender is using up his pad as he enciphers the message to
: each recipient. To authenticate each message he appends a signature
: to each plaintext. The signature can be any shared secret. The S
: (signature size) bits of pad following the portion just consumed will
: suffice. The sender enciphers the signature as part of the plaintext.
: On receipt of the message the receiver deciphers the plaintext normally,
: and compares the last S bits of the message to the next S bits of pad.
: If they match the message is authentic.
:
: Pad usage is identical at both ends: P bits for the plaintext and 2*S
: bits for the signature.
Under discussion is a scenario in which *identical* plaintext is sent
to two different recipients (perhaps through trickery by an agent).
What you describe adds a unique signature to the plaintext, so it is
not of this kind.
Also, incorporating additional ingredients such as a "shared secret",
is a nice example of what I was calling the "strengtheneing" of a
"pure OTP alone".
--
r.e.s.
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (UBCHI2)
Subject: NEMA missing a plugboard?
Date: 05 Dec 1999 07:31:29 GMT
Why did the designers of the NEMA rotor machine leave out the plugboard found
on the enigma. Wouldn't the plugboard dramatically increase the difficulty of
cryptanalysis of a rotor machine message?
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sun, 05 Dec 1999 02:23:52 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Chase) wrote:
>
> Speaking on matters of paranoia, my particular paranoid tendencies seem to
> note that Microsoft hires up quite a few of the computing history greats.
> I don't really see that they're making use of this talent as is evidenced
> by the really horrible quality products Microsoft puts out. The only
> conclusion I've been able to reach is that Microsoft hires these people to
> keep them off the market, doing otherwise productive work which might
> compete with Microsoft interests.
Microsoft did not originate that tactic but copied it, like most other
things it does
>
> The more I find out about the design weaknesses of Microsoft products, the
> more convinced I am that Microsoft's presence in this world is adversely
> effecting the progress of humanity. I really hate them.
>
Note that Microsoft has lots of folks leave them in disgust.
--
Love is blind, or at least figure that it has astigmatism.
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: 1 round Defeats Enigma attacks
Date: 5 Dec 1999 00:07:59 -0800
In article <[EMAIL PROTECTED]>,
UBCHI2 <[EMAIL PROTECTED]> wrote:
[...]
> use 1 round of transposition to superencipher an enigma encryption
[...]
Interesting idea, but this does still leave some weaknesses.
A crucial property of the Enigma is that it never enciphers
a letter to itself.
Consequently, the ciphertext will still be biased even after
the transposition, which is often an indication that traces of
the plaintext may be leaking through.
It's worth working out the details to see why this is true.
Imagine that the letter 'E' occurs in the plaintext with
frequen
Cryptography-Digest Digest #686
Cryptography-Digest Digest #686, Volume #10 Sun, 5 Dec 99 16:13:02 EST
Contents:
MMPC - A multi-message encryption algorithm (Jim Shapiro)
Re: NSA should do a cryptoanalysis of AES (Vernon Schryver)
Re: Any negative comments about Peekboo >> How to verify that promised algorithms
are included (Tom St Denis)
Re: Peekboo Ideas? >> Oops, problem ... (Tom St Denis)
Re: 1 round Defeats Enigma attacks ("Douglas A. Gwyn")
Re: 1 round Defeats Enigma attacks ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
peekboo (Tom St Denis)
Re: NP-hard Problems ([EMAIL PROTECTED])
Johnson Device ("Kurt Fleißig")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Wanted: One-way hash sourcecode or algorithm (Mattias Wecksten)
DES ECB vs CBC (Terry Powell)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: cookies (Eric Murray)
Re: Why Aren't Virtual Dice Adequate? ([EMAIL PROTECTED])
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
From: [EMAIL PROTECTED] (Jim Shapiro)
Subject: MMPC - A multi-message encryption algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sun, 05 Dec 1999 17:13:19 GMT
We have published an unusual encryption algorithm, MMPC, in the
December issue of Doctor Dobb's Journal. MMPC stands for
multi-message package chaffing. This encryption scheme combines the
all-or-nothing transform with Ron Rivest's winnowing-chaffing scheme.
MMPC features,
1. a level of security that can be chosen by the user, as it only
requires any keyed message authentication code (HMAC), and
2, a package tranform which guarantees that the receiver cannot read
_any_ of the message unless she can read _all_ of it, and
3. most importantly, the ability to intertwine any number of unrelated
messages in such a way that a recipient can only read the sub-message
for which she has a key.
By insertion of pseudo-random bytes, no one save for the sender knows
how many sub-messages are contained in a transmission.
If you are interested in code you can download it from the Dobbs site,
www.ddj.com, or from mine, www.jimshapiro.com . You will need the gcc
compiler to build the encryption/decryption programs. Included is a
makefile and a perl script to test the code.
To contact me directly remove CRYPT from my e-mail address.
--
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 5 Dec 1999 09:27:47 -0700
In article <[EMAIL PROTECTED]>, Brian Chase <[EMAIL PROTECTED]> wrote:
>Speaking on matters of paranoia, my particular paranoid tendencies seem to
>note that Microsoft hires up quite a few of the computing history greats.
>I don't really see that they're making use of this talent as is evidenced
>by the really horrible quality products Microsoft puts out. The only
>conclusion I've been able to reach is that Microsoft hires these people to
>keep them off the market, doing otherwise productive work which might
>compete with Microsoft interests.
> ...
I very much doubt Microsoft has any such intentions. I'm sure they hire
big names for the same reasons anyone else would hire them. One trouble
is that big names have generally been in the business for a bunch of years,
and have long since stopped writing any code or doing more than talking
(including sometimes teaching). Big names, like everyone else, tend to
retire on the job, or at least get promoted into management, consulting,
or figure-heading. Anyone who's been in the business for a while has met
plenty of people famous for good work but who have have done nothing but
make wind for 10 years and show no current signs of being able to do
anything but make more wind.
Even if you haven't retired on the job or received the management lobotomy,
you cannot change a corporate culture by merely talking. Even writing
code and leading by example can only affect your immediate colleagues.
Bill Gates has been quoted as saying that Microsoft managers are so smart
that they are as expert on everything that their underlings are doing as
the underlings. That's a complete explanation for Microsoft's schedule
problems, consistently bad designs, its bloated, garbage code, and
incredible provincialism. If everyone you hire is no smarter than you
are, and your organization has N layers, then the people in the trenches
will be about 2**-N as smart as you. Thus, if Gates has an I.Q. of 250
and Microsoft has only 5 layers of management, the people actually doing
the work have single-digit effective I.Q's. Even if they would be smart
elsewhere, they'll function like oysters or barnacles there. Planting a
few big name geniuses in the oyster beds won't change the nature of the
organization, but it can ruin the geniuses, by making
Cryptography-Digest Digest #687
Cryptography-Digest Digest #687, Volume #10 Sun, 5 Dec 99 21:13:01 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: cookies (E. N. Kilomary)
Re: Distribution of intelligence in the crypto field (David A Molnar)
Re: Distribution of intelligence in the crypto field (David A Molnar)
VIC cipher's PRNG ("r.e.s.")
Re: --- sci.crypt charter: read before you post (weekly notice) (E. N. Kilomary)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Safeboot is it really safe (Matt)
Re: Safeboot is it really safe (Matt)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: VIC cipher's PRNG (David Wagner)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Date: Sun, 05 Dec 1999 16:15:04 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Tim Tyler wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> Whereas your position appears to be based on faith in the existence of
> :> genuine randomness in subatomic behaviour, and in our ability to
> :> magnify this up to a macroscopic scale, without distorting it at all.
>
> : Do you know about SQUIDs? Photomultipliers? Etc.?
> : Why are you wasting bandwidth arguing about quantum effects
> : when you don't understand the subject? Go learn it first!
>
> It seems to be necessary - since some people seem to have the idea that
> a one-time pad is a realisable system.
>
> Without a source of genuinely random numbers a one-time pad falls short of
> theoretical perfection - and unfortunately, no source of demonstrably
> genuinely random numbers is - or IMO is ever likely to be - known to
> mankind.
>
> Even if you believe that SQUIDs or photomultipliers are capable of
> magnifying quantum events to a macroscopic scale without possibly
> introducing any interference from other sources, I would love to
> hear an explanation of how they could conceivably do this.
There is no need for esoteric equipment. The dark-adapted human eye detects
single quanta.
>
>
> Alternatively, should you have a demonstration that quantum events are
> themselves genuinely random, I would be delighted to hear that as well.
> --
> __
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> *If* /you/ copy this "tagline virus" *please* mutate it!
--
From: [EMAIL PROTECTED] (E. N. Kilomary)
Subject: Re: cookies
Date: Sun, 05 Dec 1999 21:37:33 GMT
[EMAIL PROTECTED] (Eric Murray) wrote:
>The server placing the cookie can set restrictions on which
>servers can access the cookie.
I don't believe that's true. A cookie can only be retrieved by the server
that planted it there.
--
"E. N. Kilomary" is actually [EMAIL PROTECTED] (6320 179458).
0 1 23456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: 5 Dec 1999 21:57:22 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Yeah, but he really ought not to be listing his clearances on a
> public forum. For one thing, it makes him a target for anyone
> who might want to exploit his access to nuclear and other
> sensitive material, terrorists for example.
Oh, good point.
Except I doubt he'll be such a target now. :-(
-David
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: 5 Dec 1999 22:02:59 GMT
CLSV <[EMAIL PROTECTED]> wrote:
>> You would expect the NSA to ask the "father of combinatorics" to
>> work on their problems, wouldn't you ?
> Yes, I didn't expect it being advertized 'though.
Fair enough. I can't find my copy of _Indiscrete Thoughts_, but I
think it has a reference to working at Los Alamos in the chapter
discussing Stan Ulam...but that is very different than actually listing
a Q clearance on your resume.
> (& smart combinatorists :-) are working for intelligence
> agencies.
The crypto sixth column, as it were.
-David
--
From: "r.e.s." <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: VIC cipher's PRNG
Date: Sun, 5 Dec 1999 15:04:06 -0800
I was looking at the very simple PRNG used in the VIC
cipher, which operated with decimal digits. In pseudo-
code, and generalizing to base-b digits, registers
R(i)(i=1..b) are initialized to R(i)=key(i)(i=1..b),
and a stream is output by iterating the following:
==
R(b+1) = R(1) + R(2) (mod b)
R(i) = R(i+1) for i=1..b
output R(b+1)
==
What I'm wondering about is, for b>2, how to get an
Cryptography-Digest Digest #688
Cryptography-Digest Digest #688, Volume #10 Mon, 6 Dec 99 01:13:00 EST
Contents:
Re: The leading university of cryptography (Yukta Mookhey)
Re: Elliptic Curve Public-Key Cryptography (Scott Contini)
Re: NSA should do a cryptoanalysis of AES (Sundial Services)
"The message is still the same." (Was Re: NSA should do ...) (Sundial Services)
Re: VIC cipher's PRNG ("r.e.s.")
Re: iaPCBC: confidentiality and integrity in one shot (long) (David Hopwood)
From: [EMAIL PROTECTED] (Yukta Mookhey)
Subject: Re: The leading university of cryptography
Date: 06 Dec 1999 00:44:14 GMT
¡° ¤Þz¡[EMAIL PROTECTED] (David A Molnar)¡n¤§»Ê¨¥¡G
[del]
> You might try looking at a list of cryptographers (David Wagner has one
> on his site, so does Kevin McCurley) and picking out those whose work you
> admire. Then see where they are located. That will probably tell you more
> than I can about which universities are strongest in the kind of crypto
> you like.
[del]
Here are they:
David's: http://www.cs.berkeley.edu/~daw/people/crypto.html
Kevin's: http://www.swcp.com/~mccurley/cryptographers/cryptographers.html
Enjoy them. :)
--
[1;32m¡° Origin: [37m [m
[1;31m¡» From: [36mterry.dorm8.nctu.edu.tw[m
--
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 6 Dec 1999 02:38:10 GMT
In article <827g7l$6a5$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>Michael Scott <[EMAIL PROTECTED]> wrote:
>>
>>DJohn37050 <[EMAIL PROTECTED]> wrote in message
>>> I said I had seen a performance sheet at least a year ago where ECC
>>>163-bit was more like the performance of 17 bit exponent RSA 1024 bit
>>>key. (ballpark). I know this info was presented at a PKS conference a
>>>few years back.
>>
>>This rather surprising claim is made in
>>
>>http://www.certicom.com/ecc/wecc4.htm
>
>Thanks. I looked at that page and it says BSAFE 3.0 took 12.7 msec to
>do a 1024 bit RSA verification, and that Certicom's two ECC methods in
>Security Builder 1.2 took 9.9 and 10.7 msec respectively, both on a
>167 MHz Ultrasparc.
>
>I don't have a 167 mhz Ultrasparc available but have been doing some
>timings on a 300 mhz unit (Sparc Ultra 5) so have some scaled figures.
>It makes me think the BSAFE 3.0 numbers are way slower than what can
>be done on that Ultrasparc. I've been told that BSAFE 3.0 is a
>portable C implemetation without any assembler speedups. I believe
>RSA has something better by now.
Yes, I am quite sure that RSA's BSAFE 3.0 had only a C implementation
of RSA on the Ultrasparc. An assembly implementation would give
a very strong speedup (approx. a factor of 4) since a 64-bit product
can be obtained from 32-bit multiplies (I do not know how much
the floating point unit can be used to speed up arithmetic, but RSA
is against using floating point arithmetic in their code because of
portability reasons). I'm quite sure RSA has a more efficient
implementation for the Ultrasparc in BSAFE 4.0. It would be nice
if somebody out there could post some timings for BSAFE 4.0.
>
>Meanwhile, the web page says the ECC implementation uses "performance
>enhancing techniques" which I'm guessing means using precomputed
>powers of the generator (as is commonly done for El-Gamal) burning a
>lot more storage space.
That is likely to be true, and it is fair to do such precomputations,
but the poster (Certicom) of the benchmarks should give some details on the
memory usage for their benchmarks to be meaningful. Certicom's
timing comparisons are bogus because they omit the details of HOW
such timings were obtained - such precomputations are not going to
be possible on many small devices. Anyway, to my knowledge, these
precomputations can speed up an ECDSA verify by at most a factor of
2 (since you can only precompute for the base point), so this (alone)
should not have a huge impact on the timing comparisons.
>
>With the OpenSSL library as distributed (www.openssl.org), on the Ultra 5,
>I get 411 verifications/sec with the built-in benchmark
>("openssl speed rsa1024"). Scaling by a factor of 2 for the 166 mhz
>processor that would be about 5 msec/verification, better than twice as
>fast as either BSAFE 3.0 or the Security Builder ECC implementation.
>
>It doesn't stop there. Although it's written in assembler, OpenSSL's
>RSA implementation on the Ultrasparc isn't very good either. The
>reason is that the Ultrasparc has a slow integer multiply instruction
>(similar to the original Pentium), and OpenSSL's implementation
>depends on it. OpenSSL on the 300 Mhz Ultrasparc is almost twice as
>slow as OpenSSL on a 300 mhz Pentium II (which has fast integer
>multiplication). The fastest way to do RSA on the Ultrasparc is to
>use floating point arithmetic, similar to how MIRACL does it on the
>Pentium. I've heard that this produces about a 3x speedup compared to
>what OpenSSL comes with
Cryptography-Digest Digest #689
Cryptography-Digest Digest #689, Volume #10 Mon, 6 Dec 99 02:13:01 EST
Contents:
Re: DES ECB vs CBC (David Hopwood)
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: Random Noise Encryption Buffs (Look Here) (David Wagner)
Re: DES ECB vs CBC (Scott Fluhrer)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: cookies (Mike Field)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: VIC cipher's PRNG ("Trevor Jackson, III")
Re: "The message is still the same." (Was Re: NSA should do ...) (wtshaw)
Re: compact encryption in javascript (David A Molnar)
Re: "The message is still the same." (Was Re: NSA should do ...) (Scott Nelson)
Date: Mon, 06 Dec 1999 04:45:11 +
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES ECB vs CBC
=BEGIN PGP SIGNED MESSAGE=
Terry Powell wrote:
>
> I was wondering if anyone could help me with this problem.
>
> I've working on adding DES encryption to a wireless system.
Why DES? It's slow and vulnerable to brute-force. Use something like
Blowfish or CAST-128 instead. Also think about whether you need an
authentication mechanism; don't assume that is automatically provided
by encryption.
> Messages transmitted on this system are generally short, 1 to 256
> blocks. A lot of the messages are state-of-heath messages from the
> system thus there will be a lot of repetition in the plaintext data.
> My approach has been to use DES in CBC mode and transmit a 64 bit
> IV ahead of the encrypted message.
Sounds reasonable to me, as far as it goes.
> There has been some debate over using CBC mode in this system. The
> main objection is the addition of the IV.
Is the objection on grounds of bandwidth/message size? If so, you could
consider using an implicit IV generated from the message sequence number
(e.g. IV = Encrypt[K'](sequence #), where K' is a second key independent
of the encryption key). That assumes that the transmitter and receiver
will always be able to keep their sequence numbers synchronised, of
course.
> The alternative design presented to me is DES using EBC mode
I assume you mean ECB.
> and placing
> a varying sequence number in the plaintext. The proponents of this mode
> state that it is just as secure as CBC with a plaintext IV (some claim
> it to be "equivelent").
It isn't (equivalent, or as secure). It will not have the desired effect
of disguising patterns in the plaintext, other than in the specific block
where the number is added.
> I'm having trouble buying their argument. I can understand that adding
> the sequence to the plaintext in [ECB] mode enhances that mode's security,
> but it seems to me that every block in a message would need to treated
> in this manner to keep it secure.
Yes, you're right.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=BEGIN PGP SIGNATURE=
Version: 2.6.3i
Charset: noconv
iQEVAwUBOEs/FjkCAxeYt5gVAQGC7Af/XjDp9i0yNflMVKdZsFpB05/pCgM7qR0J
nbzThty/XXM6k5Kn+8f2ELMSA82z+KLJ/i9/rndGyBuB/ozWsQizl7QtWVO+lGKs
UTOgatyAfvzdDImboEO72GSP+ek3ONRvC7J40NRI6jDe7KmrVglSiUcG9YEUn1ca
iqcMcEp1JrPL7LyFtArL0rOADkhSrA+Ns+HIyJT6JBEFTgVIs0wzev7GqXA1ukuk
A6kUtUyTpO1/HrtXiSxuenqjgfD4OMZ/2poXEw5qjAAP7aOzcLtgED+c0H5lXzRB
QzIVjoTG4MzsQySWQp2dc0DVQ16RUbNyPK3iXdEGpuEOwrq5Tuk8aQ==
=r5gB
=END PGP SIGNATURE=
--
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 21:25:15 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
[...]
: Consider. if you will,
: MOM (Macon's Overkill Method or Massive Overkill Method)
: of generating "random" numbers:
:
: Consider a "random" sequence of 1's and 0's
: (RBS, or Random Binary Sequence).
[...]
: An Exclusive OR (XOR) of a RBS with any sequence not derived
: from the same RBS is still a RBS. XORing any sequence will
: not and can not reduce the randomness.
Alas, this is not true if the elements of the sequence are
required to be mutually independent, or at least uncorrelated.
Let x1,x2,... be mutually independent binary random variables
with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
variables independent of the xi, but mutually correlated *among
themselves*, with nonzero covariance cov(y(i),y(i+1)).
Now zi = (xi XOR yi) = xi + yi - xi*yi, so we can easily calculate
the covariance between z(i) and z(i+1), which I find
Cryptography-Digest Digest #690
Cryptography-Digest Digest #690, Volume #10 Mon, 6 Dec 99 10:13:01 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: NEMA missing a plugboard? (Frode Weierud)
Re: MMPC - A multi-message encryption algorithm (zapzing)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: High Speed (1GBit/s) 3DES Processor (Volker Hetzer)
about the interpolation attack on block ciphers ("GyungHwa Jun")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Volker Hetzer)
Re: Noise Encryption ("Tim Wood")
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Enigma, Scott19, Lord Caligo, & Factoring (JPeschel)
Re: Wanted: One-way hash sourcecode or algorithm (Keith A Monahan)
Re: Noise Encryption (Mattias Wecksten)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Cryptix and blind signature (Szalai Zsolt)
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 23:22:11 -0800
"David Wagner" <[EMAIL PROTECTED]> wrote ...
: r.e.s. <[EMAIL PROTECTED]> wrote:
: > Let x1,x2,... be mutually independent binary random variables
: > with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
: > variables independent of the xi, but mutually correlated *among
: > themselves*, with nonzero covariance cov(y(i),y(i+1)).
: >
: > Now zi = (xi XOR yi) = xi + yi - xi*yi,
^^^
Oy! I mis-remembered this -- it should of course be
zi = (xi XOR yi) = xi + yi - 2*xi*yi
: > so we can easily calculate
: > the covariance between z(i) and z(i+1), which I find to be
: > cov(z(i),z(i+1)) = cov(y(i),y(i+1))/4 (nonzero).
: >
: > So if {yi} is a pairwise correlated sequence, then the same will
: > be true of {xi XOR yi}, even though {xi} was an iid sequence.
:
: I think you'd better double-check your math.
Right. The above calculation does indeed return cov(y(i),y(i+1))=0
when done using zi = (xi XOR yi) = xi + yi - 2*xi*yi.
: Suppose x1,x2 are independent coin flips.
: Suppose y1 is a single coin flip (independent of the x's), and y2=y1.
: This is the most extreme case of correlation possible for the y's.
:
: Let zj=xj XOR yj.
: Then it is readily confirmed that z1 is independent of z2.
: For instance, Pr[z1=0,z2=0] = Pr[x1=y1,x2=y2] = Pr[x1=x2=y1] = 1/4.
: And Pr[z1=0,z2=1] = Pr[x1=y1,x2=y2 XOR 1] = Pr[x1=x2 XOR 1=y1] = 1/4.
: And so on.
:
: Maybe you made a mistake in your calculations?
Yup -- my apologies to Guy Macon for wrongly impuning his MOM ;-) ;-)
--
r.e.s.
[EMAIL PROTECTED]
--
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Sun, 5 Dec 1999 23:56:12 -0800
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote ...
: r.e.s. wrote:
: > "Guy Macon" <[EMAIL PROTECTED]> wrote ...
: > [...]
: > : An Exclusive OR (XOR) of a RBS with any sequence not derived
: > : from the same RBS is still a RBS. XORing any sequence will
: > : not and can not reduce the randomness.
: >
: > Alas, this is not true if the elements of the sequence are
: > required to be mutually independent, or at least uncorrelated.
Alas, the mistake is mine indeed -- sorry Guy.
: > Let x1,x2,... be mutually independent binary random variables
: > with pr(xi=1)=pr(xi=0)=1/2, and let y1,y2,... be binary random
: > variables independent of the xi, but mutually correlated *among
: > themselves*, with nonzero covariance cov(y(i),y(i+1)).
: >
: > Now zi = (xi XOR yi) = xi + yi - xi*yi,
^^^
[...]
: > It was a neat idea, but I believe the flaw is fatal.
: No. Your mathematical model is flawed.
Mea culpa...
I mis-remembered the above formula, which should have been
zi = (xi XOR yi) = xi + yi - 2*xi*yi. That caused the covariance
calculation to give nonzero, when indeed it gives zero when done
correctly.
--
r.e.s.
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: NEMA missing a plugboard?
Date: 6 Dec 1999 08:06:28 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (UBCHI2) writes:
>Why did the designers of the NEMA rotor machine leave out the plugboard found
>on the enigma. Wouldn't the plugboard dramatically increase the difficulty of
>cryptanalysis of a rotor machine message?
It is perhaps better to ask why they did not reinvent the plugboard.
As far as I know the designers of the NEMA were unaware of the Enigma
plugboard. They based their design on the commercial Enigma machine,
model K, which did not have a plugboard.
The knowledge of the design of the Wehrmacht Enigma would probably have
been known to them before the NEMA was put into service in 1947 but at
that stage it was probably too late to change the design.
I asked one o
Cryptography-Digest Digest #691
Cryptography-Digest Digest #691, Volume #10 Mon, 6 Dec 99 12:13:02 EST
Contents:
Re: NP-hard Problems (Safuat Hamdy)
Re: The leading university of cryptography (Anton Stiglic)
Re: smartcard idea? ([EMAIL PROTECTED])
Re: cookies (Anton Stiglic)
Re: NP-hard Problems (Anton Stiglic)
Re: NP-hard Problems (Anton Stiglic)
Re: Noise Encryption (Guy Macon)
Re: NP-hard Problems (Anton Stiglic)
Re: Encrypting short blocks (Anton Stiglic)
Re: Encrypting short blocks (Anton Stiglic)
Re: High Speed (1GBit/s) 3DES Processor (David Kessner)
Data Encryption in Applet? ([EMAIL PROTECTED])
Re: Noise Encryption ("Tim Wood")
Re: Noise Encryption ("Tim Wood")
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES (Kenneth Almquist)
Re: The leading university of cryptography (Keith A Monahan)
Re: "The message is still the same." (Was Re: NSA should do ...) (John Savard)
Re: NP-hard Problems ("Dr. Yongge Wang")
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: 06 Dec 1999 16:09:57 +0100
[EMAIL PROTECTED] (Bill Unruh) writes:
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (James Pate Williams,
>Jr.) writes:
>
> >What are some problems that are NP-hard but not NP-complete? I know
>
> Well, it is not known if there are any NP hard problems. But assuming
> that say factoring is NP hard, I believe it is not NP complete.
Sorry, but this is *gross* nonsense. Really.
Any NP-complete problem is NP-hard by definition, and yes, the former
exists. SAT (satisfiability of ordinary boolean expressions) is
NP-complete, and so is the travelling salesman problem, the knapsack
problem, ... a whole lot of interesting problems were proven to be
NP-complete, see Garey/Johnson for a more complete listing. And yes, there
are NP-hard problems which are not NP-complete. Assuming that NP != PSPACE,
take QBF (satisfiability of boolean expressions with an unlimited number of
universal and existential quantors) for instance. QBF is PSPACE-complete,
and obviously any NP-problem can be reduced to it. But it is widely
believed that there is no NP-problem to which QBF can be reduced to.
--
S. Hamdy| All primes are odd except 2,
[EMAIL PROTECTED]| which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: The leading university of cryptography
Date: Mon, 06 Dec 1999 10:32:49 -0500
[EMAIL PROTECTED] wrote:
> Which university, in the US or elsewhere, is by your opinion the best
> when it comes to cryptography. I know Alfred Menezes and Doug Stinson
> both works for the University of Waterloo, Ontario, Canada. Is The
> Massachusetts Institute of Technology (MIT) any good when it comes to
> cryptography - In Europe MIT is often mentioned as one of the best
> engineering universities.
Waterloo and MIT are both great.
To that, I would probably add the Catholic University of Louvain (UCL)
and
in my own city :) Universite de Montreal/McGill University.
For more applied, data security stuff, there would be Princeton and
Berkeley.
There are certainly others that are also great... It depends what you
like
to work on.
Anton
--
From: [EMAIL PROTECTED]
Subject: Re: smartcard idea?
Date: Mon, 06 Dec 1999 15:38:02 GMT
Hello all,
ELVA has developed and patented a new concept of smartcard named
VocaliD. This smartcard , compliant with ISO7816 standards, also has an
embedded acoustic interface that allows the use of a telephone or a
microphone as a reader for access to online services. An identification
sequence made up of an identification number and a cryptogram is
readable either via the ISO contacts or the acoustic interface. This
cryptogram is a function of the one previously emitted, forming a
linking protocol. This method is much less expensive than OTP.
For more information, please visit our web site : http://www.elva.fr
Jean-Pierre Fortune
ELVA
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: cookies
Date: Mon, 06 Dec 1999 10:56:32 -0500
==132C5A166902866BEB5E05F6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
A cookie is a file that is placed on your computer machine when
you go to some web sites. The cookie file contains information
that the web site could read if you ever go back to it. Some web
servers get together and share the information they get from the
cookies they place, this is a way for them to track you on the
Internet. The information these web servers can get from you
is amazing, and worth allot of money. To get an idea, imagine you
going to a mall, as soon as
Cryptography-Digest Digest #692
Cryptography-Digest Digest #692, Volume #10 Mon, 6 Dec 99 15:13:01 EST
Contents:
Re: Will ScramDisk recover ? >> After another round of tests ... YES, it (Paul
Koning)
Re: Johnson Device ("Martin Peach")
Re: Johnson Device ("Martin Peach")
Re: Data Encryption in Applet? ("Tim Wood")
Re: Noise Encryption ("Trevor Jackson, III")
Re: Quantum Computers and Weather Forecasting (Richard Herring)
Re: DES ECB vs CBC (Paul Koning)
Re: Wanted: One-way hash sourcecode or algorithm (Paul Koning)
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Johnson Device (Jim Dunnett)
Re: how to combine hashes to build a 128-bit key? (Stefek Zaba)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Encrypting numbers? (Michael Groh)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
USENIX Security Symposium 2000 - A Call for Papers (Moun Chau)
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: Re: Will ScramDisk recover ? >> After another round of tests ... YES, it
Date: Mon, 06 Dec 1999 12:02:10 -0500
Lincoln Yeoh wrote:
>
> On Fri, 3 Dec 1999 08:04:09 -0500, "Microsoft Mail Server"
> <[EMAIL PROTECTED]> wrote:
>
> >the fact that scramdisk retains the essence of boot,fat, data sector
> >structure is a prime reason it is so durable.
> >
> >try making two identical container files of moderate size. load some text
> >files into the svl's for reference points, then swap the boot sector on
> >each. try swapping the fat structures. very interesting indeed!
>
> What happens?
>
> I'm too lazy to swap boot sectors - I don't have a utility which can copy
> sectors to another file easily.
Boot up linux and use dd. (That's how I repair broken DOS
filesystems...)
paul
--
From: "Martin Peach" <[EMAIL PROTECTED]>
Subject: Re: Johnson Device
Date: Mon, 6 Dec 1999 11:18:33 -0500
Kurt Fleißig wrote in message <82eau6$do$[EMAIL PROTECTED]>...
>does anybody use an hadrware device to obtain from the thermodynamic
>Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
>one-time-pad encryption?
The soundblaster itself is a hardware device...perhaps if you set the input
gain to maximum on the microphone channel, you will have a few bits of
noise, otherwise you could make a plug with a one-megohm resistor between
signal in and ground and try to read the noise directly from the resistor.
You might need a preamplifier though, in which case you will start
amplifying electrical hum and so forth as well, so you need to start being
concerned about shielding the circuit.
\/\/\/*= Martin
--
From: "Martin Peach" <[EMAIL PROTECTED]>
Subject: Re: Johnson Device
Date: Mon, 6 Dec 1999 11:18:33 -0500
Kurt Fleißig wrote in message <82eau6$do$[EMAIL PROTECTED]>...
>does anybody use an hadrware device to obtain from the thermodynamic
>Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
>one-time-pad encryption?
The soundblaster itself is a hardware device...perhaps if you set the input
gain to maximum on the microphone channel, you will have a few bits of
noise, otherwise you could make a plug with a one-megohm resistor between
signal in and ground and try to read the noise directly from the resistor.
You might need a preamplifier though, in which case you will start
amplifying electrical hum and so forth as well, so you need to start being
concerned about shielding the circuit.
\/\/\/*= Martin
--
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.security,microsoft.public.java.security,comp.lang.java.programmer
Subject: Re: Data Encryption in Applet?
Date: Mon, 6 Dec 1999 17:28:49 -
wrote in message <[EMAIL PROTECTED]>...
>Hi
>
>I am looking for a way to encrypt data through an applet using symmetric
>(or asymmetric) encryption. I thought of sending an applet containing a
>symmetric key to a client.
How? If the symmetric key is not encrypted when you send it, it could be
intercepted and used to read the, client side encrypted, data.
> This is key is to perform encryption on some
>data on the client side. Anybody has any idea how to do this in Java or
>has any source codes in Java?
>
>Thanks in advance
>
>Greg
>
>
>
tim
--
>From my one-bit brain with a parity error.
--
Date: Mon, 06 Dec 1999 12:58:26 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Guy Macon wrote:
> In article <82g2km$dck$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Wood)
>wrote:
>
> >>The real problem with
> >>OTP is to transport the key by a secure media.
> >
> >This is not
Cryptography-Digest Digest #693
Cryptography-Digest Digest #693, Volume #10 Mon, 6 Dec 99 16:13:01 EST
Contents:
Re: NP-hard Problems (Anton Stiglic)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: High Speed (1GBit/s) 3DES Processor (Helger Lipmaa)
Re: Johnson Device (Scott Nelson)
Re: NSA competitors (JCA)
NSA future role? (SCOTT19U.ZIP_GUY)
Re: Data Encryption in Applet? (Tim Tyler)
Re: Data Encryption in Applet? (Luciano da Silva Coelho)
Re: NSA future role? (Steve K)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Mon, 06 Dec 1999 15:02:21 -0500
==212B898CB9E4A1CA76605E5A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
Your remarks are valid. I was just trying to give a simple intuitive
explanation,
while not completly defining the term. It's simpler to think of problems
that
are not decisional, but complexe, than to think of decisional problems that
are
more complexe than NP-complete.
As for what you are talking about, you could, in the same way, build up a
hierarchy
of different levels of *non-resolvable* classes of problems. But I beleive
that to
understand this one would need some advanced classes in computer complexity.
For what sci.crypt is concerned, I beleive a most intuitive example is what
is
needed.
Anton
> No, there is a much more fundamental difference than that. NP-hard
> problems are not restricted to the class NP, so while most people will
> allow non-decision problems to be called NP-hard, NP-hard problems can
> in fact be *much* harder decision problems than those in the class NP.
>
> For example, take a decision problem A that is complete NTIME(2^n).
> We know by the various time hierarchy results that such an A exists
> and is not in the class NP, so is strictly harder than the problems in
> NP. Furthermore, since NP is a subset of NTIME(2^n), you know that
> everything in NP is reducible to A. Therefore A is NP-hard, but
> cannot possibly be NP-complete, even though it is a decision problem.
>
> So we know that there are (decision) problems that are NP-hard and not
> NP-complete, so there exist provably intractible NP-hard problems.
> However, we don't know if there are any NP-complete problems that
> aren't in P, so there *aren't* any provably intractible NP-complete
> problems (well... there may be "provably" intractible NP-complete
> problems, but we don't know of any such proofs at this time!). So
> there is a *huge* difference between NP-hard and NP-complete, and it's
> definitely not restricted to "the fact that NP-hard problems are not
> limited to decisional problems".
>
> --
> Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
> Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
> University of North Texas| or better,' so I installed Linux."
> Denton, TX 76201|
--
___
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___
==212B898CB9E4A1CA76605E5A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Your remarks are valid. I was just trying to give a simple
intuitive explanation,
while not completly defining the term. It's simpler to think
of problems that
are not decisional, but complexe, than to think of decisional problems
that are
more complexe than NP-complete.
As for what you are talking about, you could, in the same way, build
up a hierarchy
of different levels of *non-resolvable* classes of problems.
But I beleive that to
understand this one would need some advanced classes in computer complexity.
For what sci.crypt is concerned, I beleive a most intuitive example
is what is
needed.
Anton
No, there is a much more fundamental difference than
that. NP-hard
problems are not restricted to the class NP, so while most people will
allow non-decision problems to be called NP-hard, NP-hard problems
can
in fact be *much* harder decision problems than those in the class
NP.
For example, take a decision problem A that is complete NTIME(2^n).
We know by the various time hierarchy results that such an A exists
and is not in the class NP, so is strictly harder than the problems
in
NP. Furthermore, since NP is a subset of NTIME(2^n), you know
that
everything in NP is reducible to A. Therefore A is NP-hard, but
cannot possibly be NP-complete, even though it is a decision problem.
So we know that there are (decision) problems that are NP-hard and not
NP-complete, so there exist provably intractible NP-hard problems.
However, we don't know if there are any NP-complete problems that
aren't in P, so there *aren't* any provably intractible NP-complete
problems (well...
Cryptography-Digest Digest #694
Cryptography-Digest Digest #694, Volume #10 Mon, 6 Dec 99 18:13:01 EST
Contents:
Re: Noise Encryption (Volker Hetzer)
Re: cookies ("karl malbrain")
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: Encrypting numbers? (David Wadsworth)
Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe
([EMAIL PROTECTED])
Re: smartcard idea? (Shawn Willden)
Re: Some feedback from the USA --- my story is real .. (Shawn Willden)
If you're in Australia, the government has the ability to modify your
([EMAIL PROTECTED])
Re: Distribution of intelligence in the crypto field ([EMAIL PROTECTED])
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Date: Mon, 06 Dec 1999 15:21:33 +
Mattias Wecksten wrote:
> I think this is the center of all disagreements. What if you use a non
> algorithmic random generator. There is still not true randomness, but still
> there is no way of "guessing" the data.
What is a non-algorithmic rng that is no true rng?
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
--
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: cookies
Date: Mon, 6 Dec 1999 13:22:51 -0800
Brian Chase <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
(...)
> I think your points are valid about us not entirely knowing what
> weaknesses may within a browser or in the supporting OS files. But you
> have to draw the line somewhere as to how paranoid you want to be. I'm
> fairly comfortable with just disabling the obvious bits which allow remote
> sites to execute code on my systems. Yeah, this doesn't preclude someone
> from exploiting some bug which may or may not exist inherent to the OS...
> well hell actually it'd almost have to be a backdoor deliberately put in
> place and not a bug.
PARANOIA is an AMATEUR's response to someone else's security problem. It's
a REACTION. What is it that you think that remote sites are going to obtain
from you, anyway??? Maybe you're afraid that your BROWSER wrote your credit
card and name onto the hard drive somewhere, making it available as
`evidence' for the newest generation of NO-KNOCK search and seizure
protocols being installed by the FBI. The UNIFORM COMMERCIAL CODE already
protects you from being held accountable for items or services that you
don't receive. Again, your sense of SECURITY is entirely misplaced.
> Even if you're worried about this, it still possible to put in a filtering
> host between yourself and the rest of the world. If you're worried about
> someone exploiting a backdoor, just block all unexpected traffic to and
> from your host. And then monitor the allowed traffic for anomalies.
No, the point is that the WINDOWS platform, with its free-wheeling software
generation and installation, is by nature not secure. It's not a BACK door,
but a wide open FRONT door. I must have dozens of `shareware' or `freeware'
packages installed on my NT 4.0 machine. I know next to nothing about any
of it.
> If you're really so paranoid about security that even those precautions
> aren't enough, then you probably shouldn't be using the Internet :-)
And that's the point of OFFENSIVE SECURITY. I only utilize NUMBERS that are
INDEMNIFIED. Karl M
--
From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Mon, 06 Dec 1999 16:23:23 -0500
Richard Herring wrote:
> There appeared to be some implicit bragging about your punctuation :-)
> But I think you meant at, not @.
Actually I meant @, similarly I quasi-comically imitated John's use of
for @ in his e-mail address.
Here is how I use @ & at (not stating this is grammatically correct, only
logical for me) :
A shower occurred @ 4 PM at Tannersville.
"at" referring to a specific *place*, @ referring to another type of
reference, such as a time; which you cannot be "at". Thus :
I won't interfere with your attempt @ minimizing your accomplishments...
Perhaps "attempt of minimizing" is best ?
Joseph
--
From: David Wadsworth <[EMAIL PROTECTED]>
Subject: Re: Encrypting numbers?
Date: Mon, 6 Dec 1999 21:25:46 +
In article <[EMAIL PROTECTED]>, Michael Groh
<[EMAIL PROTECTED]> writes
>I have a question that may seem rather obvious to some people, but I
>haven't found a simple answer yet. While reading Singh's book ("The Code
>Book") I noticed that none of the simpler encryption techniques
>specifically address encrypting numeric values. Consider something as
>simple as "$14.37". How can that value be encrypted using a Vigenere or
>substitution cipher? Even the Enigma machine doesn't include a numeric
>row on its keyboard. How did the German military transmit
Cryptography-Digest Digest #695
Cryptography-Digest Digest #695, Volume #10 Tue, 7 Dec 99 00:13:01 EST
Contents:
Re: How can you tell? (Pelle Evensen)
Re: NEMA missing a plugboard? ([EMAIL PROTECTED])
Re: Distribution of intelligence in the crypto field (CLSV)
Re: The leading university of cryptography (David A Molnar)
Problems with Ciphile (was quantum computing..) (albert)
Re: Encrypting numbers? (Johnny Bravo)
Perfect Shuffles [src code] (Arthur Dardia)
Re: NSA future role? (albert)
Re: compact encryption in javascript (Darren New)
Revolutionary War Cryptography and Espionage (CryptoBook)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe (Keith
A Monahan)
Re: Problems with Ciphile (was quantum computing..) (Kal I. Normey)
Re: Data Encryption in Applet? ([EMAIL PROTECTED])
Re: Quantum Computers and Weather Forecasting (Gerold Lee Gorman)
Re: NSA should do a cryptoanalysis of AES ("Trevor Jackson, III")
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
From: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: How can you tell?
Date: Tue, 07 Dec 1999 00:12:40 +0100
John ([EMAIL PROTECTED]) wrote:
> Say you had an encrypter and no source. How would you go about
> verifying it? I usually do extensive tests on the cryptext. Is
> getting chi-square statistics on it good? If so, how many times and at
> what intervals would give best results?
Marsaglia has written some great papers about tests for "random" sequences.
The website hasn't been updated in quite a while but the stuff on the CD
is nice.
http://stat.fsu.edu/~geo/diehard.html
http://stat.fsu.edu/pub/diehard/cdrom
To write a "stream cipher" that will pass all known tests for randomness;
1. Take a statistically good PRNG, KISS, or a MWC generator or whatever you
like that passes all statistical tests known to you. Call it r, r[n]
is the nth number from the generator. Seed r with a small seed based
on k (the key), just make sure that the initial seed is big enough to be
hard to deduce (or make collide) from testing many k's but still small
enough to trivially brute force.
2. Take c[n] = r[n] + e(k, p[n]). Even if the "encryption function" e(k, x) is
something like e(k, p[n]) = k ^ p[n], that is simply the plaintext xored
with the key, the output will look "random".
(c[n] = nth ciphertext block, e(k, x) = the encryption of x under key k,
p[n] = nth plaintext block.)
Moral: You can't get any information whatsoever about a cryptosystems security
from statistically measuring the output data. This also works the other way
round, you could of course add redundant data to a secure algorithm's output
to make the data fail any such tests. Not that I know why anyone would do
that but it illustrates "no information whatsoever". :-)
Cheers,
Pell
--
Pelle Evensen, [EMAIL PROTECTED] Telenordia AB/Algonet
http://www.evensen.org/pgp.html for public key.
PGP fingerprint 22 DC 52 0D 7E 00 F7 9C 8B EB F0 55 1E 8C 71 5E
--
From: [EMAIL PROTECTED]
Subject: Re: NEMA missing a plugboard?
Date: Mon, 06 Dec 1999 23:53:00 GMT
[EMAIL PROTECTED] (UBCHI2) wrote:
> Why did the designers of the NEMA rotor machine leave out the
> plugboard found on the enigma. Wouldn't the plugboard dramatically
> increase the difficulty of cryptanalysis of a rotor machine message?
No.
The ENIGMA plugboard is nothing more than a rotor that doesn't rotate.
It is largely a nuisance than a real cryptanalytic countermeasure. The
ENIGMA ring settings are similar in this regard.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: Tue, 07 Dec 1999 00:02:26 +
[EMAIL PROTECTED] wrote:
> albert <[EMAIL PROTECTED]> wrote:
> > [...]I see Bruce's arguement, we know what we know, they know what we know
> > AND what they know. They also have resources up the wazoo. But
> > intelligence isn't something money can buy, if it was, windows would be
> > the best OS... correct?
Huh? Windows is the best selling OS. That is what counts for the
employees
of Microsoft, that is what counts for the shareholders of Microsoft. Why
would Microsoft make the *best* OS? What's the use?
> I'd disagree, at least for symmetric key ciphers. I think we're seeing
> the same names in commercial cryptography because there are only a
> handful of people who can spend their lifetime working on it. It's more
Where did you get that idea? Look at the contributors of the Crypto 'YY
and EuroCrypt 'YY conferences those are more than a handful.
The researchers page of Counterpane labs lists ~300 people. Admitted,
security agencies have probably a better focus. But for how long?
The field is exploding with new technologies: quantum crypto, exotic
protocols, new public key syste
Cryptography-Digest Digest #696
Cryptography-Digest Digest #696, Volume #10 Tue, 7 Dec 99 06:13:01 EST
Contents:
Re: Encrypting numbers? (wtshaw)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
Re: Noise Encryption (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Paradise shills?? (Daniel Hutchings)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting numbers?
Date: Mon, 06 Dec 1999 23:45:37 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Michael Groh) wrote:
> I have a question that may seem rather obvious to some people, but I
> haven't found a simple answer yet. While reading Singh's book ("The Code
> Book") I noticed that none of the simpler encryption techniques
> specifically address encrypting numeric values. Consider something as
> simple as "$14.37". How can that value be encrypted using a Vigenere or
> substitution cipher? Even the Enigma machine doesn't include a numeric
> row on its keyboard. How did the German military transmit numeric values
> (persumably including + and - signs, decimal points, etc.) using the
> Enigma machine?
>
> TIA for an enlightenment!
>
> - Mike
Other than spelling them out, use an alphabetic *code* for replacement,
even as simple as a=1, b=2, decimal point=x, z as $. Make up your own list
and be generations late. You could use the keyboard as offset q=1, w=2,
etc.
--
Adequate security means causing an attacker to give up and spend his time attacking
someone else.
--
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Mon, 06 Dec 1999 23:40:12 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Orwellian Nightmare Down Under? by Stewart Taggart
>
> 3:00 a.m. 4.Dec.1999 PST
> SYDNEY, Australia -- Any data seem different on your computer today?
>
Such tactics are too much to be tried at present in the USA. When some
bright and devious fellow wants to field test a tactic, pick a country as
a guniea pig, one not too important, Australia, New Zealand,
Englandthose that are already trained to be kicked around, and not
afraid to treat their citizens as dummies.
If it can be made to work there, surely it can be used here, even if it
has to done in the dark of secret courts, secret orders, holding those who
do not go along without charges calling it national security.
Now if the Constitution can be *handled* through *emergency* measures, and
even politicians are coerced into not talking, we can have a dandy
dictatorship.
--
Adequate security means causing an attacker to give up and spend his time attacking
someone else.
--
From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Tue, 07 Dec 1999 01:21:33 -0500
Trevor Jackson, III wrote:
> Try Alfred Bester's "The Demolished Man" for usage of this technique.
Please explain - I don't know what you are referring to, though I do know
how to demolish things quite well.
Joseph
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 07:04:35 GMT
karl malbrain wrote:
> That's exactly the SAME point. Why don't they use COTS
> specifications from the airlines?
I didn't know the airlines were using B-1Bs.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 07:19:18 GMT
"SCOTT19U.ZIP_GUY" wrote:
>No this is based on the fact that if one looks at a binary file.
> One can quickly determine if it is one that could have resulted
> from the compression in use. Most compression schemes
> are such that Decompress(Compress(X))=X for all X
> But so far only the ones I've written (in open lititature) have
> the addtional property that Compress(Decompress(X))=X
> for any X. This is something the average user can check on his
> own. Takes files are random and try to decompress them and
> then compress them back. The problem is far more than just
> the headers. It is so bad that for many encrypted messages
> you may be guaranteeing the fact that the only Key that can
> lead to a valid solution is the one the user used. Which means
> the attacker may have enough info to break your message on a
> cipher only type of attack.
What I'm still trying to figure out is how the l
Cryptography-Digest Digest #697
Cryptography-Digest Digest #697, Volume #10 Tue, 7 Dec 99 08:13:01 EST
Contents:
Re: dictionary (Klaus Pommerening)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Lyal Collins")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Lyal Collins")
Re: smartcard idea? ("Lyal Collins")
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
From: [EMAIL PROTECTED] (Klaus Pommerening)
Subject: Re: dictionary
Date: 7 Dec 1999 11:28:15 GMT
In <825npb$app$[EMAIL PROTECTED]> "Olaf Dokter" wrote:
> i am searching dictionaries to download,
>
http://www.uni-mainz.de/~pommeren/Kryptologie/Klassisch/1_Monoalph/Muste
rsuche.html
But beware: Dictionaries are good for pattern search, not for
frequency statistics.
--
Klaus Pommerening [http://www.Uni-Mainz.DE/~pommeren/]
Institut fuer Medizinische Statistik und Dokumentation
der Johannes-Gutenberg-Universitaet, D-55101 Mainz, Germany
PGP fingerprint: F5 03 CE E7 70 C2 8C 74 BA ED EC 60 83 3B 7C 89
--
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Tue, 07 Dec 1999 03:57:37 -0800
Reply-To: [EMAIL PROTECTED]
"Trevor Jackson, III" wrote:
> Tim Tyler wrote:
>
> > Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > : Tim Tyler wrote:
> >
> > :> Whereas your position appears to be based on faith in the existence of
> > :> genuine randomness in subatomic behaviour, and in our ability to
> > :> magnify this up to a macroscopic scale, without distorting it at all.
> >
> > : Do you know about SQUIDs? Photomultipliers? Etc.?
> > : Why are you wasting bandwidth arguing about quantum effects
> > : when you don't understand the subject? Go learn it first!
> >
> > It seems to be necessary - since some people seem to have the idea that
> > a one-time pad is a realisable system.
> >
> > Without a source of genuinely random numbers a one-time pad falls short of
> > theoretical perfection - and unfortunately, no source of demonstrably
> > genuinely random numbers is - or IMO is ever likely to be - known to
> > mankind.
> >
> > Even if you believe that SQUIDs or photomultipliers are capable of
> > magnifying quantum events to a macroscopic scale without possibly
> > introducing any interference from other sources, I would love to
> > hear an explanation of how they could conceivably do this.
>
> There is no need for esoteric equipment. The dark-adapted human eye detects
> single quanta.
>
> >
> >
> > Alternatively, should you have a demonstration that quantum events are
> > themselves genuinely random, I would be delighted to hear that as well.
>
> > --
> > __
> > |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
> >
> > *If* /you/ copy this "tagline virus" *please* mutate it!
I believe that CCDs (charged coupled devices) are quite capable of
detecting a single photon. Consider those used by astrophysicists,
for example.
--
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Tue, 07 Dec 1999 04:02:14 -0800
Reply-To: [EMAIL PROTECTED]
Tim Tyler wrote:
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> :> : You have just discovered true randomness.
> :>
> :> Alas, even *if* this is genuinely random - which you will never
> :> demonstrate - nobody has developed a scheme for extracting this
> :> information onto a macroscopic scale without introducing bais of
> :> one type or another.
> :>
> :> Until such a scheme is demonstrated, "true atomic randomness" is
> :> of the same utility to a cryptographer as a "perfectly straight line"
> :> is to a student of geometry.
>
> : I think you have taken a misguided position and are struggling too much to
> : defend it.
>
> Whereas your position appears to be based on faith in the existence of
> genuine randomness in subatomic behaviour, and in our ability to
> magnify this up to a macroscopic scale, without distorting it at all.
>
> : I think that a very good true random demonstration would be to generate a
> : single photon and direct it through a tiny hole. Where it strikes a screen
> : on the other side of the hole will be unpredictable within the possible field
> : in which it may strike.
>
> I can't predict it /exactly/ - but I know that it will be more likely to
> hit near the
Cryptography-Digest Digest #698
Cryptography-Digest Digest #698, Volume #10 Tue, 7 Dec 99 12:13:01 EST
Contents:
Re: Paradise shills?? ("Trevor Jackson, III")
Re: Encrypting numbers? (Thanks all!) (Michael Groh)
Re: Quantum Computers and Weather Forecasting (Richard Herring)
Re: Encrypting numbers? (Thanks all!) (John Savard)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: Encrypting numbers? (Frank Gifford)
Re: NSA future role? (Frank Gifford)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Encrypting numbers? (Thanks all!) ("Tim Wood")
Re: about the interpolation attack on block ciphers ("Daryl Rauhala")
Re: Quantum Computers and Weather Forecasting ("Joel Olson")
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (None)
Re: NSA future role? (CLSV)
Re: NSA should do a cryptoanalysis of AES (Sander Vesik)
Re: NSA should do a cryptoanalysis of AES (Scott Fluhrer)
Re: The Code Book - Part 4 ("Paul Gover")
Date: Tue, 07 Dec 1999 08:20:14 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Daniel Hutchings wrote:
> What I don't understand is, why use a pseudo-random number generator
> at all? You can buy physical devices that use quantum effects to
> generate random numbers, and baby it just doesn't get any more random
> than that. Comments?
Sometimes you want the sequence to be repeatable. In simulations one
onts to be able to re-run the simulations to obtain the same or similar
results. This is why most programming languages allow the writer to seed
the PRNG. The results is guaranteed to be reproducible.
In crupto, the receiver(s) needs to be able to reproduce the same
sequence that the sender used during encryption. Because the sender and
receiver(s) need to generate the same sequence they use a deterministic
generator.
--
From: [EMAIL PROTECTED] (Michael Groh)
Subject: Re: Encrypting numbers? (Thanks all!)
Date: Tue, 7 Dec 1999 09:01:43 -0500
Thank you all very much for your responses. I'd guessed that the Enigma
operators had to spell out the numeric values, but thought that doing so
would increase the message a great deal. Instead of just 6 characters to
transmit ($14.37) they'd have a bunch. Even if we spell it out:
"DollarSignOneFourPointThreeSeven" it's a much longer message. I hadn't
considered that this makes the crypanalysis job much harder as well!
Thanks again for your replies!
- Mike
--
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: 7 Dec 1999 13:57:15 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Joseph Bartlo ([EMAIL PROTECTED])
wrote:
> Richard Herring wrote:
> > There appeared to be some implicit bragging about your punctuation :-)
> > But I think you meant at, not @.
> Actually I meant @, similarly I quasi-comically imitated John's use of
> for @ in his e-mail address.
Aha. Understood.
> Here is how I use @ & at (not stating this is grammatically correct, only
> logical for me) :
Fair enough.
> A shower occurred @ 4 PM at Tannersville.
> "at" referring to a specific *place*, @ referring to another type of
> reference, such as a time; which you cannot be "at". Thus :
In conservative English usage @ is called the "commercial at" symbol,
suggesting that it should only be used for prices and the like:
3 gadgets @ $5 each: $15
> I won't interfere with your attempt @ minimizing your accomplishments...
Wow, a gerund. Not many people know how to use those any more.
> Perhaps "attempt of minimizing" is best ?
Definitely not.
But "attempt to ", "attempt at ", "attempt on "
would all be legitimate in appropriate contexts.
--
Richard Herring | <[EMAIL PROTECTED]>
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Encrypting numbers? (Thanks all!)
Date: Tue, 07 Dec 1999 14:34:04 GMT
On Tue, 7 Dec 1999 09:01:43 -0500, [EMAIL PROTECTED] (Michael
Groh) wrote:
>Even if we spell it out:
>"DollarSignOneFourPointThreeSeven" it's a much longer message. I hadn't
>considered that this makes the crypanalysis job much harder as well!
Of course, you mean much _easier_.
--
From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Tue, 07 Dec 1999 09:59:00 -0500
Richard Herring wrote:
> Joseph Bartlo ([EMAIL PROTECTED]) wrote:
>> Perhaps "attempt of minimizing" is best ?
>
> Definitely not.
>
> But "attempt to ", "attempt at "
Cryptography-Digest Digest #699
Cryptography-Digest Digest #699, Volume #10 Tue, 7 Dec 99 15:13:02 EST
Contents:
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (CoyoteRed)
Re: NSA future role? (CoyoteRed)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Scott Nelson)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
How do you get past the password screen to the crypto? ([EMAIL PROTECTED])
Re: How do you get past the password screen to the crypto? (Mike Andrews)
Re: NSA should do a cryptoanalysis of AES (Frank Gifford)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: NSA future role? (Medical Electronics Lab)
Re: How do you get past the password screen to the crypto? ("anonymous intentions")
Re: NEMA missing a plugboard? (Jim Gillogly)
Re: NSA future role? (albert)
Just how secure is RC4? (albert)
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: NP-hard Problems ([EMAIL PROTECTED])
Ellison/Schneier article on Risks of PKI (Bill Lynch)
Re: Why Aren't Virtual Dice Adequate? ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES ("Tony T. Warnock")
From: CoyoteRed <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Tue, 07 Dec 1999 12:08:51 -0500
Reply-To: this news group unless otherwise instructed!
[EMAIL PROTECTED] said...
>Orwellian Nightmare Down Under? by Stewart Taggart
>
>3:00 a.m. 4.Dec.1999 PST
>SYDNEY, Australia -- Any data seem different on your computer today?
So, I guess for the truly paranoid, someone should develop a disk
controller and encryption card that also has a smartcard reader.
On-board strong encryption with part of the key on a smartcard and the
other in bio-memory. Have the controller card never off-load the key,
but use it directly off the card and not allow /any/ outside access to
it. The controller also continuosly securely hashes the contents of
the drive and stores it both on the card and on the encrypted drive
for comparison upon next boot.
The only thing that I see as a security concern is the user input of
his passphrase. A hacker could conceivably change out the BIOS to log
the passphrase key strokes. (A secure hash of the BIOS as well?)
If done right, the user would never be in the dark about any tampering
in his system.
--
CoyoteRed
CoyoteRed bigfoot com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
--
From: CoyoteRed <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Tue, 07 Dec 1999 12:08:52 -0500
Reply-To: this news group unless otherwise instructed!
albert said...
> If you walk into the library of the University of Michigan, you can actually find
> all you need to know as far as how to make a nuclear bomb. So what, should the
> NSA "ban" the university library? If you have a PPP account, you more than likely
> can find enough information to build something we supposedly have locked down as
> "National Secrets". Naval design of a Rail Gun is top secret, yet it's in my
> physics book. So it's stupid.
There's a massive difference between concepts and refinements.
I doubt very seriously that a top secret design is in your textbook.
Just because you have a book that describes a rail gun doesn't mean
that it has the end-all design.
The design in your text book is probably the "flintlock" of rail guns,
while the Navy's may be more like a modern "sniper" rifle.
Actual capabilities are almost always secret. A submariner buddy of
mine always jokes about his sub's capabilities. When asked, "How deep
can you go?" His response, "DEEP!" "How fast can you go?" "FAST!"
So, in my opinion, the failure to secure our nuclear secrets are
paramount to treason and they should be held accountable. (and I'm
not talking about a promotion either, which sounds like the norm for
the Clinton administration.)
--
CoyoteRed
CoyoteRed bigfoot com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
--
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Reply-To: [EMAIL PROTECTED]
Date: Tue, 07 Dec 1999 17:27:33 GMT
On Tue, 07 Dec 1999 16:11:53 GMT, [EMAIL PROTECTED] (None) wrote:
>On Tue, 7 Dec 1999 23:53:12 +1100, "Lyal Collins"
><[EMAIL PROTECTED]> gagged and spewed out this stuff:
>
>>This solution is a bit pointless if the warrant covers your off-line
>>machine.
>>Lyal
>>
>
> You must know a very advanced technique to hack into
> an "offline" computer?
>
Actually, it's an ancient technique -
bre
Cryptography-Digest Digest #700
Cryptography-Digest Digest #700, Volume #10 Tue, 7 Dec 99 15:13:02 EST
Contents:
Re: Perfect Shuffles [src code] (Arthur Dardia)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Encrypting numbers? (Jim Dunnett)
Re: NSA future role? (Jim Dunnett)
Re: NSA future role? (Jim Dunnett)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein a
paper ... (Jim Dunnett)
Re: If you're in Australia, the government has the ability to modify yourfiles.
>> 4.Dec.1999 (Jim Dunnett)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Jim Dunnett)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Jim Dunnett)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Jim Dunnett)
Re: Encrypting numbers? (Thanks all!) (Jim Dunnett)
Re: Encrypting numbers? (Thanks all!) (Jim Dunnett)
Re: How do you get past the password screen to the crypto? (Arthur Dardia)
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Perfect Shuffles [src code]
Date: Tue, 07 Dec 1999 14:54:52 -0500
>From an email I received today from an ignorant, obtuse asshole:
"BTW: if all you are interested in is how many perfect shuffles it will
take to put the deck into the original order, there's a much faster
approach -- it should take you less than 0.001sec. But, because you
posted this to such an inappropriate group, I won't tell you what it
is."
Why do you insist on flaming? Is it to overcompensate for a small penis?
Does such a physical state create a mental problem that tells you that
you're not as big as a man as a person who you've never seen before? To
make up for this, do you flame people before even reading their post in
order to boost your ego? Go play with yourself some more.
Anyways...for the more informed, I'm studying using a deck of cards and a
machine shuffler for random data (which applies to OTPs and many facets of
crytography). I'm studying all of the facets of a deck of cards for an AP
Statistics project that I volunteered for.
And, to pour some more salt in my open wound, the responder says he won't
tell me b/c he thinks that I don't know. Anyways, I said it had to take
less than .001 sec, because that's the lowest that my timer class can
measure. In order to figure out the time per each shuffle, I ran it on a
deck of 832 cards. This measured an average per shuffle; however, I then
measured it on a deck of 416 cards, and it was less. A deck of 208 cards
regarded even less. I plan to run these tests again multiple times, plot
them on my TI-83, and obtain a regression curve in order to estimate the
average time per shuffle on a deck of 52 cards.
Anyways, a while ago, a person asked how to solve a problem a prospective
employer had given him. Someone said the answer was 97,XXX shuffles on a
deck of 1001 cards. I ran this in my program with in- and out- shuffles,
and my program skipped over the 98,000 shuffle count both ways. Any ideas?
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Keyhttp://www.webspan.net/~ahdiii/ahdiii.asc
Arthur Dardia wrote:
> I've written a program to perform in- or out- shuffles until the deck is
> returned to the original order. I've tested it on a deck of size 52
> cards. It returns the proper in- and out- shuffles; however, I've
> benchmarked it using a SysTimer class with a .001s granularity. My
> tests fail to return a time for the deck of 52 cards. Is this a rather
> fast algorithm? Here's some pseudo-code followed by my implementation:
>
> perfectShuffle(array of card values, in- or out- shuffle switch)
> split the deck into two halves: tDeck (representing position 0 to
> the (deck size/2)-1) and bDeck, (representing the lower half)
> shuffle the deck by placing the bottom card of the top half and then
> the bottom card of the bottom half onto the bottom of the real deck (the
> order is switched for in- or out- shuffles)
>
> compare the arrays
>
> I was wondering what the big-O notation of this is and if there are any
> faster algorithms. I remember someone posting once about his
> prospective company requesting such a program; however, he said he left
> his running for 8 hours and came up blank. Then someone quickly
> repsonded with a number near 97,000 shuffles. Therefore, I have to
> assume that if my program can perform 8 shuffles in AT MOST .001
> seconds, it could then perform the 97,000 and change shuffles in about
> 97 seconds. Is this calculation right? Why did the other guy's program
> take a RIDICULOUSLY larger amount of time?
>
> --- snip ---
> #include
> #include
> #include "apvector.h"
>
> void perfectShuffle(apvector &deck,int io) {
> apvector tDeck((deck.length()/2),0);
> for (int i=0;i tDeck[i]=deck[i];
> }
>
>
Cryptography-Digest Digest #701
Cryptography-Digest Digest #701, Volume #10 Tue, 7 Dec 99 21:13:01 EST
Contents:
PCI Cryto Card (Arthur Dardia)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Breaking NCipher smartcard system ([EMAIL PROTECTED])
M-Box PRNGs (Sander Vesik)
Re: Breaking NCipher smartcard system (Paul Rubin)
Re: Paradise shills?? (zapzing)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (zapzing)
old Microsoft Mail 3.0b encryption? (Keith A Monahan)
Re: NSA should do a cryptoanalysis of AES (fungus)
Frequency results of twofish and serpent. (albert)
Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein a
paper ... (Bruce Schneier)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein a
paper ... (David A Molnar)
Re: How can you tell? (John)
Re: NSA future role? ("Jeff Moser")
Re: Frequency results of twofish and serpent. (Boaz Lopez)
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: PCI Cryto Card
Date: Tue, 07 Dec 1999 15:03:28 -0500
Great new product out for webmasters that need to improve SSL
performance for their e-stores, check it out:
http://isg.rainbow.com/products/cs_1.html
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Keyhttp://www.webspan.net/~ahdiii/ahdiii.asc
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Tue, 7 Dec 1999 20:04:30 GMT
Johnny Bravo <[EMAIL PROTECTED]> wrote:
: On Tue, 7 Dec 1999 15:44:05 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
:>: Tim Tyler wrote:
:>:> You don't think 56-bits is a slightly small figure? Even for its day?
:>
:>: It obviously wasn't. DES far outlived its design life.
:>
:>Really? For all either of us know DES may have been quietly being broken
:>in secret for very many years, behind closed doors.
: Since we are playing the "what-if" game. What if the NSA recovered
: a quantum computer from a UFO crash at Roswell New Mexico and has
: broken every code ever put into use since then?
...then possibly lots more codes will be broken than most people realise.
Your "if" hypothesises the existence of space-faring alien intelligences.
My "if" hypothesises the existence of a break in a fielded cypher that has
a relatively small keyspace, and has been in common use for many years.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
If at first you do succeed, try not to look astonished.
--
From: [EMAIL PROTECTED]
Subject: Breaking NCipher smartcard system
Date: Tue, 07 Dec 1999 20:22:53 GMT
nCipher have a smart card system which generates random keys and can
store them on a smart card.
Does anyone have any information/links onto any related weaknesses with
this particular system?
David Walker
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: M-Box PRNGs
Date: 7 Dec 1999 20:54:43 GMT
First things first:
* I have read the charter, but there are no newsgroups dedicated
to (possibly strong) prngs
* It may very well be the wheel re-invented
* It probably *IS* snake-oil
* It relies extensively on a not so widely analysed shiffer mode
* There is no proof that it works, and I am not claiming so
Take it "just as thoughts". But here it comes:
***
Below are some thoughts on a PRNG (family of PRNGs) that should have the
following propeties:
1) It requires relatively small amount of inital unknown true
random state
2) Requires modest amount of retained stae
3) Knowing a single value from anywhere in the keystream should
give absolutely the most minimal information about preceding
and succeeding values
4) Is secure enough for use in key-generating black boxes
The following assumes:
a) cracking a block shiffer in CFNLF mode is *hard*.
b) CFNLF mode is not overly easy to crack with a known plaintext
attack, especially if only a part of the shiffertext is known
(otherwise the required inital random state expands a lot)
c) The work/benefit ration makes sense. For some chiffers, the
effort required for key schedule is extensive.
===
M-Box Pseudo-Random Nunmber Generators
===
M-Box is a construct consisting of:
a) matrix A, consisting of n x n bits
b) m-bit quantity K1
c) m-bit quantity K2
d) function f(d,K)
In the follow
Cryptography-Digest Digest #702
Cryptography-Digest Digest #702, Volume #10 Wed, 8 Dec 99 00:13:01 EST
Contents:
Re: NSA future role? (CLSV)
Re: Encrypting numbers? (Thanks all!) (Michael Groh)
Re: NSA future role? (CLSV)
Re: Frequency results of twofish and serpent. (Johnny Bravo)
Re: NSA should do a cryptoanalysis of AES (Kenneth Almquist)
"Ciphertext-only Cryptanalysis of Enigma" (JPeschel)
New Courses in Information Security at RMIT (Serdar Boztas)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Paradise shills?? ("Douglas A. Gwyn")
Re: Encrypting numbers? (Thanks all!) ("Douglas A. Gwyn")
Re: Frequency results of twofish and serpent. ("Douglas A. Gwyn")
From: CLSV <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Wed, 08 Dec 1999 02:09:57 +
Medical Electronics Lab wrote:
> CLSV wrote:
> > albert wrote:
> > > If you walk into the library of the University of Michigan, you can actually find
> > > all you need to know as far as how to make a nuclear bomb.
> > One of those myths started by popular science magazines.
> [...] The hard part isn't the knowledge. The hard part is the
> material. You need specific isotopes in large enough quantities
> to create a nuclear weapon. The knowledge of how to separate
> those isotopes is also in the library.
There are enought countries that have the raw material that
would have build nuclear weapons if it were so easy. There is a
huge gap between reading theoretical principles in a (library) book
and building a nuclear weapon. The devil is in the details.
> Iraq's Hussien has built quite a few plants that separate out
> U235, and he's built at least one small reactor to create Pu.
And strangely enough Iraq had to depend on the *really* old documents of
the Manhattan project instead of using the much easier obtainable
library books.
Regards,
Coen Visser
--
From: [EMAIL PROTECTED] (Michael Groh)
Subject: Re: Encrypting numbers? (Thanks all!)
Date: Tue, 7 Dec 1999 21:20:19 -0500
Gotcha! Particularly if the numeric portion (such as a date, or time)
occurred in the same part of a standard message, it'd lend itself to a
crib, especially since the cryptanalyst would know the date and time the
message was sent, or at least, the date and time the message was
intercepted.
Thanks for the correction!
- Mike
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> On Tue, 7 Dec 1999 09:01:43 -0500, [EMAIL PROTECTED] (Michael
> Groh) wrote:
>
> >Even if we spell it out:
> >"DollarSignOneFourPointThreeSeven" it's a much longer message. I hadn't
> >considered that this makes the crypanalysis job much harder as well!
>
> Of course, you mean much _easier_.
>
--
From: CLSV <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Wed, 08 Dec 1999 02:23:32 +
albert wrote:
> > One of those myths started by popular science magazines.
> Nope, not a myth, it's true. I will concede to the post above, stating that
> measurements, and details are hidden, which is the impeding stumbling block to making
> one, but if you want concepts etc,, it's all there.
Ok, I can agree with that.
> > And why wouldn't private sector companies make any mistakes?
> Accountability. Profit. NASA has lost about $2Billion thus far on Mars stuff. Any
>of
> them fired? No. If it was the private sector, performance and reward are linked,
>not
> so in the public sector.
Hmm, my opinion is that especially in big corporations large
amounts of money are wasted on useless pet projects, ego-mania,
stupidity, fraud et cetera. The problem is that a corporation
isn't publicly accountable for such losses. They rather hide
them in their incredibly complex annual reports to keep the
faith of their customers, creditor, share holders. At rare times we
get to see some of the mistakes if they are big enough
(e.g. Barings bank). I think that the problems that NASA has are more
related to the size and structure of the organization than on the
difference between private and public sector.
Regards,
Coen Visser
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Frequency results of twofish and serpent.
Date: Tue, 07 Dec 1999 21:37:29 GMT
On Tue, 07 Dec 1999 22:58:38 GMT, albert <[EMAIL PROTECTED]> wrote:
>I took an encryption of some text with twofish and serpent (straight
>ECB). I then did a frequency count of the results. I'm shocked (well,
>not really) on how evenly distributed the values a
Cryptography-Digest Digest #703
Cryptography-Digest Digest #703, Volume #10 Wed, 8 Dec 99 06:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Trevor Jackson, III")
Solitaire analysis? ("r.e.s.")
Re: NSA competitors (Bruce Schneier)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("fuck echelon")
AES Randomness Testing ("Ernst G. Giessmann")
Re: MMPC - A multi-message encryption algorithm ([EMAIL PROTECTED])
Re: NP-hard Problems (Safuat Hamdy)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: NSA should do a cryptoanalysis of AES (Volker Hetzer)
Re: Just how secure is RC4? ([EMAIL PROTECTED])
Re: Ellison/Schneier article on Risks of PKI ([EMAIL PROTECTED])
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: NSA competitors (Volker Hetzer)
Is this software a hoax? ([EMAIL PROTECTED])
Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)
Re: Is this software a hoax? (Eric Hambuch)
Date: Wed, 08 Dec 1999 00:19:53 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
CoyoteRed wrote:
> [EMAIL PROTECTED] said...
>
> >Orwellian Nightmare Down Under? by Stewart Taggart
> >
> >3:00 a.m. 4.Dec.1999 PST
> >SYDNEY, Australia -- Any data seem different on your computer today?
>
> So, I guess for the truly paranoid, someone should develop a disk
> controller and encryption card that also has a smartcard reader.
> On-board strong encryption with part of the key on a smartcard and the
> other in bio-memory. Have the controller card never off-load the key,
> but use it directly off the card and not allow /any/ outside access to
> it. The controller also continuosly securely hashes the contents of
> the drive and stores it both on the card and on the encrypted drive
> for comparison upon next boot.
>
> The only thing that I see as a security concern is the user input of
> his passphrase. A hacker could conceivably change out the BIOS to log
> the passphrase key strokes. (A secure hash of the BIOS as well?)
>
> If done right, the user would never be in the dark about any tampering
> in his system.
Similar concepts were discussed here a few months ago in the context of a
non-seizable computer. One wants to reserve the information, but make it
impossible (literally) of recovery without the requisite key. The base
concept was a RAM disk containing an OTP key the same size as the
protected disk volume. On power loss the key disappears, but the data is
recoverable if the key is reloaded from off-site backup.
--
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Solitaire analysis?
Date: Tue, 7 Dec 1999 21:28:10 -0800
Anyone know if there have been published analyses of
Bruce Schneier's "Solitaire" algorithm?
The few postings I've seen claim a detectable bias in
letter frequencies, but I don't know how reliable those
are. (Especially since they say the algorithm isn't
reversible -- whereas it sure looks reversible to me.)
So I wonder if I'm misunderstanding something, or if
the algorithm now on Counterpanes's website might be a
significantly different revision.
--
r.e.s.
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA competitors
Date: Wed, 08 Dec 1999 05:33:33 GMT
On Sat, 04 Dec 1999 22:47:49 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>On Sat, 04 Dec 1999 18:13:27 +, CLSV <[EMAIL PROTECTED]> wrote:
>
>>I'm wondering if there is any knowledge about non-US
>>government institutes that are specialized in cryptography and
>>cryptanalysis? I'm thinking about countries that invest a lot
>>in mathematical education like China, Russia, India.
>
>The Russian one, under the acronym FAPSI, now even has a web site too.
>
>On the other hand, the Chinese agency - known as the "technical
>department" - is very secretive.
I know of the Chinese organization as the Ministry of National
Security.
There's also MI5 and MI6 in the UK, SDECE in France, and the BND in
Germany. Israel has Mossad.
Bruce
**
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
--
From: "fuck echelon" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Wed, 8 Dec 1999 01:02:47 -0500
A bug isn't needed, a tempest attack or a boot would work for most purposes.
Scott Nelson <[EMAIL PROTECTED]> wrote in m
Cryptography-Digest Digest #704
Cryptography-Digest Digest #704, Volume #10 Wed, 8 Dec 99 13:13:02 EST
Contents:
Re: Is this software a hoax? ("Tim Wood")
Re: Frequency results of twofish and serpent. (Paul Crowley)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (Steve K)
Re: Frequency results of twofish and serpent. (Tom St Denis)
Re: Ellison/Schneier article on Risks of PKI ("Tim Wood")
Re: NSA competitors (CLSV)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Tim Wood")
Re: NP-hard Problems (Anton Stiglic)
AES and perl (encryption) ("Shaun Wilde")
Re: How can you tell? (John)
Re: How can you tell? (Mike Andrews)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Scott Nelson)
Re: Ellison/Schneier article on Risks of PKI (Eric Lee Green)
Re: AES and perl (encryption) (Volker Hetzer)
Re: How can you tell? (Volker Hetzer)
Re: NP-hard Problems (Anton Stiglic)
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Is this software a hoax?
Date: Wed, 8 Dec 1999 11:51:10 -
*Quote*
it is a powerful WIN95/98 program that provides you with the tools necessary
to locate and use the resources available on the internet right from the
program!
If while reading through the numerous listings found within Cyber-Detective
you find a site that you wish to visit
immediately, simply click on the button "GO" and you
will be taken directly to the site.
A link directory is an HTML document that you can load into your browser.
Once loaded, it provides you with clickable links that you can use to
navigate the internet.
Quick Search - Search multiple sources for an address, email or phone
information.
The CD Toolkit has an option that you can use to create a Cyber-Track & Spy
diskette. Armed with this diskette you can track anyone's internet activity.
Simply install the secret tracking files from this diskette onto a computer
and all URLs visited will be secretly tracked and recorded.
Disk Snoop is a simple but useful utility that will allow you to quickly
search any computer for internet file types. Those who do not carefully
delete the files generated during their internet activity will be at the
mercy of this software.
*/Quote*
I think it is simply a utility which combines a net search tool, links to
information databases on the web, and some advice on where to obtain
information about yourself/others
And the odd utility to do relatively simplistic things like search a
computer for non-deleted files(!)
It may be useful but probably cannot do anything you can't do without it.
It's collection of links are probably the most useful bit.
It also advertises a book containing
"How To Make $1,000's of Dollars With Other People's Products
Automatically - Proven Strategies!
How I Average $50 For Every Direct E-Mail Letter I Send Out - And Who I Send
Them To! (spammers are missing the real power of e-mail entirely)"
A get-quick-rich scam if ever I saw one.
Tim
wrote in message <82lba6$sne$[EMAIL PROTECTED]>...
>I stubbled across this on the net:
>
>http://www.web-warrior.net/cyberdetective/index.htm
>
>It sounds unbelievabley impressive. But it can't be true, can it?
>
>Has anyone ever used it?
>
>David
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--
>From my one-bit brain with a parity error.
--
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Frequency results of twofish and serpent.
Date: 8 Dec 1999 08:10:01 -
[EMAIL PROTECTED] (Johnny Bravo) writes:
> This is to be expected, if it were otherwise something would be
> seriously messed up. The biggest such analysis I know of is the one
> that showed the bias in RC4, each character has a (1/256)+(1/2^256)
> chance of being a duplicate of the previous character. This is the
> result of billions of bytes of ciphertext being analysed. It was just
> interesting to note, but not of any practical use.
56 trillion bytes of ciphertext were analysed: the duplicate
probability seems to be (1/256) + (1/2^24).
Further details on http://www.hedonism.demon.co.uk/paul/rc4/
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
--
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Wed, 08 Dec 1999 14:24:01 GMT
On Wed, 08 Dec 1999 00:19:53 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>CoyoteRed wrote:
>
>> [EMAIL PROTECTED] said...
>>
>> >Orwellian Nightmare Down Under? by Stewart Taggart
>> >
>> >3:00 a.m. 4.Dec.1999 PST
>> >SYDNEY, Australia -- Any data seem different on your computer today?
>>
>> So, I guess for the truly paranoid, someone should develop a disk
>> controller and
Cryptography-Digest Digest #705
Cryptography-Digest Digest #705, Volume #10 Wed, 8 Dec 99 16:13:01 EST
Contents:
Synchronised random number generation for one-time pads ("Charles Meigh")
Re: NSA competitors (Pablo Arrighi)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Synchronised random number generation for one-time pads (Scott Nelson)
Re: Solitaire analysis? (Paul Crowley)
Re: AES and perl (encryption) (Eric Lee Green)
Re: Synchronised random number generation for one-time pads (Eric Lee Green)
Re: NSA future role? (Jim Dunnett)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein a
paper ... (Jim Dunnett)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Jim Dunnett)
Re: Synchronised random number generation for one-time pads (Jim Dunnett)
Re: NSA competitors (Jim Dunnett)
Re: NSA competitors (Jim Dunnett)
Re: Ellison/Schneier article on Risks of PKI (Bruce Schneier)
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
From: "Charles Meigh" <[EMAIL PROTECTED]>
Subject: Synchronised random number generation for one-time pads
Date: Tue, 7 Dec 1999 22:22:02 -
First off, I confess my newbie status as far as crypto goes. I'm reading
"Applied Cryptography" at the bookshop, but I can't afford to buy it yet :-)
With regard to one-time pads, which I keep reading as being the most secure
form of encipherment, it appears that a major problem is the distribution of
the completely random keys. This is exacerbated by the need for more keys
for more messages, and larger keyspaces for larger messages (I think).
Would it be practicable to set up a system that creates the random numbers
for the key from some globally consistent, 'natural' source like, say,
cosmic radiation readings; the sender and receiver obviously having had
exchanged brief, secure messages agreeing on exactly when to take these
key-generating readings? You could then (if i'm thinking right) create as
many completely secure one-time pads as you like, without the overhead of
distributing vast amounts of data first, just your synchronising messages.
--
Charles Meigh
--
From: Pablo Arrighi <[EMAIL PROTECTED]>
Subject: Re: NSA competitors
Date: Wed, 08 Dec 1999 18:36:37 +
>
> > There's also MI5 and MI6 in the UK, SDECE in France, and the BND in
> > Germany. Israel has Mossad.
>
> Ok. Thank you.
> I'm gonna look if there is some information on their crypto research.
Mmmm... Keep us informed, but I doubt you will anything.
BTW:
UK's is GCHQ rather, former CESG. GCHQ does a lot odf advertising, they may
have something.
France's is DGSE former SDECE, with a recent specialised group called BRGE.
Pablo.
--
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 8 Dec 1999 10:39:10 -0800
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> karl malbrain wrote:
> > The point, you idiot, is that both B-1B's and airlines use TOILET
SEATS!!!
> > Why not the same ones? Karl M
>
> Passenger planes allocate more space. Look inside a bomber some time.
Again, that's the exact same SUBJECTIVE point. It's just a round-about way
of OBJECTIVELY DEMANDING more money go to bomber manufacturers. The first
`bombers' in WORLD WAR I were just STANDARD bi-planes. Karl M
--
Date: Wed, 08 Dec 1999 14:16:41 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Steve K wrote:
> On Wed, 08 Dec 1999 00:19:53 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >CoyoteRed wrote:
> >
> >> [EMAIL PROTECTED] said...
> >>
> >> >Orwellian Nightmare Down Under? by Stewart Taggart
> >> >
> >> >3:00 a.m. 4.Dec.1999 PST
> >> >SYDNEY, Australia -- Any data seem different on your computer today?
> >>
> >> So, I guess for the truly paranoid, someone should develop a disk
> >> controller and encryption card that also has a smartcard reader.
> >> On-board strong encryption with part of the key on a smartcard and the
> >> other in bio-memory. Have the controller card never off-load the key,
> >> but use it directly off the card and not allow /any/ outside access to
> >> it. The controller also continuosly securely hashes the contents of
> >> the drive and stores it both on the card and on the encrypted drive
> >> for comparison upon next boot.
> >>
> >> The only thing that I see as a security concern is the user input of
> >> his passphrase. A hacker could conceivabl
Cryptography-Digest Digest #706
Cryptography-Digest Digest #706, Volume #10 Wed, 8 Dec 99 20:13:02 EST
Contents:
Re: Ellison/Schneier article on Risks of PKI ("Lyal Collins")
low exponent in Diffie-hellman? (jerome)
Re: Synchronised random number generation for one-time pads (Doug Stell)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir (Paul Koning)
Re: PCI Cryto Card (Paul Koning)
Re: Johnson Device ("Kasper Pedersen")
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Crypt FAQ Comments (section 9.5) (Erik Kraft)
Re: NSA future role? (JCA)
Re: Frequency results of twofish and serpent. (Johnny Bravo)
Re: Frequency results of twofish and serpent. (Johnny Bravo)
Re: NSA future role? (albert)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Solitaire analysis? ("r.e.s.")
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Curious PhenomenaRe: High Speed (1GBit/s) 3DES Processor ("Casey")
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (Steve K)
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Ellison/Schneier article on Risks of PKI
Date: Thu, 9 Dec 1999 08:16:29 +1100
>Note that I'm not shooting down the whole notion of a PKI. For the most
part,
>I believe that a PKI infrastructure is a Good Thing, because it's a lot
easier
>to keep track of one root certificate and to keep secure one PKI server
than
>it is to secure entire networks full of certificates and servers. But PKI
is
>not the panacea that has been claimed, it is just one tool in the toolkit
for
>keeping a network secure.
I thought that was one point of the article. PKI is not
secure/reliable/trustable (choose the term of your preference) unless the
entire network of machines and certificates are equally secure.
This complexity and effort is roughly equivalent to that required in a
symmetric key system.
>Eric Lee Green [EMAIL PROTECTED]
>Software Engineer Visit our Web page:
>Enhanced Software Technologies, Inc. http://www.estinc.com/
>(602) 470-1115 voice (602) 470-1116 fax
--
From: [EMAIL PROTECTED] (jerome)
Subject: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 08 Dec 1999 21:17:41 GMT
i perform a calculation g^x mod p. g=2 and p a prime of 768bits.
The algorithm i used is based on the 'square and multiply'
exponantiation so the smaller x is, the faster is the computation.
as far as i know the only constraint for x is to be 0 > x > p-2.
can i reduce x to 128bits (enougth to prevent a brute force) ?
or there is a special attack for the low exponent ? (some RSA
implementations got issues about that but i don't have the papers
so i can't say if it can be used against Diffie-hellman)
--
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Synchronised random number generation for one-time pads
Date: Wed, 08 Dec 1999 21:03:43 GMT
On Tue, 7 Dec 1999 22:22:02 -, "Charles Meigh"
<[EMAIL PROTECTED]> wrote:
>With regard to one-time pads, which I keep reading as being the most secure
>form of encipherment, it appears that a major problem is the distribution of
>the completely random keys. This is exacerbated by the need for more keys
>for more messages, and larger keyspaces for larger messages (I think).
Correct.
>Would it be practicable to set up a system that creates the random numbers
>for the key from some globally consistent, 'natural' source like, say,
>cosmic radiation readings; the sender and receiver obviously having had
>exchanged brief, secure messages agreeing on exactly when to take these
>key-generating readings? You could then (if i'm thinking right) create as
>many completely secure one-time pads as you like, without the overhead of
>distributing vast amounts of data first, just your synchronising messages.
In the practical world, we frequently run pseudo-random number
generators (PRNG), which are "seeded" by some suitably large secret.
Obviously, this is only as secure as the seed and PRNG
implementation., but this is still very secure.
If seeds are exchanged securely and shared by both parties, then their
respective PRNGs can generate a large amount of identical key stream.
Of course, the two ends need to maintain synchronization and your
protocols have to be designed to facilitate resynchronization without
loss of security.
What you are really asking is whether or not the two parties can
independently create their seeds from some secret procedure and common
data. This simply abstracts the problem of exchanging the secret seed
to one of exchanging a smaller secret procedure. We would have to
assume that an adversary has access to the body of data that the
proce
Cryptography-Digest Digest #707
Cryptography-Digest Digest #707, Volume #10 Thu, 9 Dec 99 00:13:02 EST Contents: Re: NSA should do a cryptoanalysis of AES (Tim Tyler) Re: Synchronised random number generation for one-time pads (Tim Tyler) Re: Synchronised random number generation for one-time pads (Tim Tyler) Re: NSA future role? (CLSV) Re: AES Randomness Testing (Tim Tyler) Re: MMPC - A multi-message encryption algorithm (Jim Shapiro) Re: If you're in Australia, the government has the ability to modify your files. >> 4.Dec.1999 (Greg) weak algorithm, too hard for me (Gaccm) Re: NSA future role? (SCOTT19U.ZIP_GUY) Re: NSA future role? (Steve K) SRP - a secure alternative for authentication >> Nice reading ... ([EMAIL PROTECTED]) From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: NSA should do a cryptoanalysis of AES Reply-To: [EMAIL PROTECTED] Date: Thu, 9 Dec 1999 00:28:29 GMT Douglas A. Gwyn <[EMAIL PROTECTED]> wrote: : Tim Tyler wrote: [DES] :> Really? : Yes. I feel you need some quotation treatment ;-) In discussing the strength of DES, Bruce Schneier wrote in "Applied Cryptography": ``A brute force DES-cracking machine that can find a key in an average of 3.5 hours cost only $1 Million in 1993. DES is so widespread that it is naive to pretend that the NSA and its counterparts haven't built such a machine.'' ...and... ``Winn Schwartau writes that the NSA had built a massively parallel DES-cracking machine as early as the mid-1980s. At least one such machine was built [...] Supposedly there are a series of algorithms that can reduce the complexity of a DES brute-force search by several orders of magnitude. Contextual algorithms, based on the inner workings of DES, can scrap sets of possible keys based on partial solutions. Statistical algorithms reduce this effective key size still further. And other algorithms choose likely keys - words, printable ASCII, and so on [...] - to test. The rumour is that the NSA can crack DES in 3 to 15 minutes, depending on how much preprocessing they can do. And these machines cost only $50,000 each, in quantity.'' As for expected lifespan: DES was adopted as a federal standatd in 1976. It became an ANSI standard in 1981. The terms of the DES standard stipulate it be reviewed every five years. It was renewed in the 1983 review. It was renewed again in 1987 - and *again* in 1992. DES did not outlive its expected life - from the perspective of the 1992 review, anyway. It was almost certainly cracked, probably easily and en-masse while it was still in service as an officially endorsed US government standard. -- __ |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED] It's been lovely, but I have to scream now. -- From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: Synchronised random number generation for one-time pads Reply-To: [EMAIL PROTECTED] Date: Thu, 9 Dec 1999 00:37:53 GMT amadeus wrote: : OTP is totally secure given it is properly used. The problems are key : distribution and key cancellation/deletion. [...] Then there's the issue that a known-plaintext attack reveals the key - and possibly allows inauthentic messages to be passed off as the real one. Authenticity is a problem for OTPs. With your typical block cypher, knowing the plaintext does *not* instantly reveal the message key, and allow forged message(s) to be sent. -- __ |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED] Love is chemistry; sex is physics. -- From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: Synchronised random number generation for one-time pads Reply-To: [EMAIL PROTECTED] Date: Thu, 9 Dec 1999 00:42:30 GMT Scott Nelson <[EMAIL PROTECTED]> wrote: : It's quite conceivable that OTP technology : of the near future could be used to send _video_ messages. No doubt it *could* be done today. However - for most applications - I'm sure that there must be better ways of doing things than this. OTPs face the key-distribution problem more strongly than any other type of cypher. -- __ |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED] It's not enough to succeed - others must fail. -- From: CLSV <[EMAIL PROTECTED]> Subject: Re: NSA future role? Date: Thu, 09 Dec 1999 01:19:45 + albert wrote: >>> If you walk into the library of the University of Michigan, you can actually find >>> all you need to know as far as how to make a nuclear bomb. CLSV wrote: >> One of those myths started by popular science magazines. JCA wrote: > Actually, it is true. However, you are right in that popular science magazines > have been responsible for misleading one into thinking that just about anyone could >in > fact build a nuclear bomb. To yank this thread more towards the charter of sci.crypt
Cryptography-Digest Digest #708
Cryptography-Digest Digest #708, Volume #10 Thu, 9 Dec 99 04:13:01 EST
Contents:
Shamir announces 1 sec break of GSM A5/1 (JTong1995)
Re: NSA should do a cryptoanalysis of AES (Johnny Bravo)
Re: Synchronised random number generation for one-time pads (John Savard)
Re: NSA future role? (Jerry Coffin)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("fuck echelon")
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? (David Wagner)
Re: Shamir announces 1 sec break of GSM A5/1 (Gurripato)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (Gurripato)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein
a paper ... (Gurripato)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("H.J. Gould")
Digitally signing an article in a paper journal (KloroX)
From: [EMAIL PROTECTED] (JTong1995)
Subject: Shamir announces 1 sec break of GSM A5/1
Date: 09 Dec 1999 05:37:45 GMT
Cell Phone Crypto Penetrated
by Declan McCullagh
10:55 a.m. 6.Dec.1999 PST
Israeli researchers have discovered design flaws that allow the
descrambling of supposedly private conversations carried by hundreds of
millions of wireless phones.
Alex Biryukov and Adi Shamir describe in a paper to be published this week
how a PC with 128 MB RAM and large hard drives can penetrate the security
of a phone call or data transmission in less than one second.
More Infostructure in Wired News
Read more about Gadgets and Gizmos
Check back with Wired News for continuing coverage
Read more Politics -- from Wired News
Read more Technology -- from Wired News
The flawed algorithm appears in digital GSM phones made by companies such
as Motorola, Ericsson, and Siemens, and used by well over 100 million
customers in Europe and the United States. Recent estimates say there are
over 230 million users worldwide who account for 65 percent of the digital
wireless market.
Although the paper describes how the GSM scrambling algorithm can be
deciphered if a call is intercepted, plucking a transmission from the air
is not yet practical for individuals to do.
James Moran, the fraud and security director of the GSM Association in
Dublin, says that "nowhere in the world has it been demonstrated --an
ability to intercept a call on the GSM network. That's a fact To our
knowledge there's no hardware capable of intercepting."
The GSM Association, an industry group,
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 09 Dec 1999 01:02:37 GMT
On Wed, 08 Dec 1999 23:14:58 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Since we are being hypathetical. lets assume our Jewish
>friends have captured 3 Moslem terroists. And that Isreally
>intellagnce knows that 3 three have encrypted the message
>Such that the first one encrypted the message.
This is where the entire scenario falls apart. They just torture
the plaintext out of this guy, bypassing the encryption entirely.
Johnny Bravo
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 09 Dec 1999 06:02:00 GMT
On Tue, 7 Dec 1999 22:22:02 -, "Charles Meigh"
<[EMAIL PROTECTED]> wrote:
>Would it be practicable to set up a system that creates the random numbers
>for the key from some globally consistent, 'natural' source like, say,
>cosmic radiation readings; the sender and receiver obviously having had
>exchanged brief, secure messages agreeing on exactly when to take these
>key-generating readings? You could then (if i'm thinking right) create as
>many completely secure one-time pads as you like, without the overhead of
>distributing vast amounts of data first, just your synchronising messages.
The pads wouldn't be "completely secure", since the natural source
could be recorded by an attacker, your brief, secure messages could be
decrypted...so it isn't the absolutely perfect case of a one-time-pad.
It's generally believed this principle is more trouble than it is
worth, though, and doesn't really gain anything; the algorithm of
"when to take these key-generating readings" is the key to security,
and an equivalently complicated algorithm could just be used for plain
encryption.
--
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: NSA future role?
Date: Wed, 8 Dec 1999 23:23:29 -0700
In article
Cryptography-Digest Digest #709
Cryptography-Digest Digest #709, Volume #10 Thu, 9 Dec 99 10:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Rick Braddam")
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
Re: Digitally signing an article in a paper journal (Paul Rubin)
Re: Digitally signing an article in a paper journal (KloroX)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Tim Wood")
Re: Digitally signing an article in a paper journal ("Phil Bartley")
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (SCOTT19U.ZIP_GUY)
Re: weak algorithm, too hard for me (JPeschel)
Re: Curious PhenomenaRe: High Speed (1GBit/s) 3DES Processor (Richard Herring)
QBITS ("Yuri Federovich")
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
Re: NSA future role? (SCOTT19U.ZIP_GUY)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 (Steve K)
Re: low exponent in Diffie-hellman? (DJohn37050)
Re: NSA future role? (CLSV)
Re: low exponent in Diffie-hellman? (Bob Silverman)
Re: Shamir announces 1 sec break of GSM A5/1 (SCOTT19U.ZIP_GUY)
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Thu, 9 Dec 1999 03:05:14 -0600
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
|> Steve K wrote:
|> > Unless he is carrying a badge. Or a gavel. Then,
attempting real
|> > resistance will get you summarily shot, and properly so.
Something
|> > about national sovreignty, if I remember my political
science
|> > defnintions.
|>
|> It has nothing to do with national sovereignty!
|> The government is authorized, or at least able with impunity,
|> to use force to achieve its ends. That's why it is important
|> for the citizenry to keep a tight rein over the government.
|> Apparently in the UK and Australia the citizens have
surrendered;
|> other evidence for that is that they let the agents of the
|> government disarm them (with a consequent, predictable leap
|> in the violent crime rate, especially home invasions). Sheep.
I think you can look at the UK and Australia to see where we are
headed, full speed ahead and (apparently) no brakes.
--
Rick
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 9 Dec 1999 02:59:22 -0600
Volker Hetzer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Rick Braddam wrote:
> > Sounds like the difference between using PGP for email and
SSL for purchases.
> Well, yes. Basically you can reason about the security of the
protocol
> without
> bearing the final application in mind. The good thing is that
after that
> you can use
> ssl for almost anything. The bad thing is that you cannot make
any
> assumtions about
> the applications that use SSL.
Another good thing is that SSL requires nothing of the user -- it
is transparent to the user, too. It seems to me that could also
be a bad thing... since it doesn't allow much in the way of user
options. IIRC, SSL also sends identifiers for the crypto
primitives used. That's great for interoperability, but tells an
attacker exactly what s/he must attack. And the crypto primitives
are a small subset of all available algorithms. Also, there is no
mechanism for using a pre-agreed-upon set of primitives without
sending/exchanging the identifier information. I would think that
an attacker's problems would be compounded if correspondents
chose the primitives in advance from a large set of primitives
(like Wei Dai's Crypto++ library, or Eric Young's 'original'
SSLeay library) and no information identifying which were used
were transmitted with messages.
-snip agreement-
> > I didn't
> > think about sending each item of info immediately as soon as
it was developed.
> Then, of course there are all those nice images where you can
watch the
> buildup when they gain resolution.
Yes, I like those images, too. Is the image information actually
transmitted in the page, or is it transmitted as a different
'message' interleaved with the http page? At any rate, Scott's
all-or-nothing encryption wouldn't work (in my opinion) in those
cases where information must be displayed or used before the
whole message is received, like in those interleaved images.
-snip agreement-
>
> > Does anyone have, or can anyone make a good estimate of, the
percentage of Internet traffic which is short-message based...
-snip-
> I don't but I *think* that large
Cryptography-Digest Digest #710
Cryptography-Digest Digest #710, Volume #10 Thu, 9 Dec 99 13:13:02 EST
Contents:
Re: Synchronised random number generation for one-time pads ("Tony T. Warnock")
Re:NASA measurements, was: NSA future role? ("Tony T. Warnock")
Re: low exponent in Diffie-hellman? (jerome)
Re: Curious PhenomenaRe: High Speed (1GBit/s) 3DES Processor (MegaZone)
Re: low exponent in Diffie-hellman? (jerome)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: High Speed (1GBit/s) 3DES Processor (Helger Lipmaa)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: weak algorithm, too hard for me (Guy Macon)
Seeking Free Internet CA ("Erich Trowbridge")
Re: NSA future role? (CLSV)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Random Noise Encryption Buffs (Look Here) (John Myre)
Re: How can you tell? ("Tim Wood")
Re: weak algorithm, too hard for me (JPeschel)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Compiling TwoFish with DJGPP (Roger Carbol)
Re: Curious PhenomenaRe: High Speed (1GBit/s) 3DES Processor (Paul Koning)
Re: AES and perl (encryption) ("Shaun Wilde")
Re: low exponent in Diffie-hellman? (Ian Goldberg)
Re: Shamir announces 1 sec break of GSM A5/1 (Ian Goldberg)
Re: Synchronised random number generation for one-time pads (doc)
Re: Synchronised random number generation for one-time pads ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: Shamir announces 1 sec break of GSM A5/1 (Paul Koning)
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Thu, 09 Dec 1999 08:09:21 -0700
Reply-To: [EMAIL PROTECTED]
Tim Tyler wrote:
> amadeus wrote:
>
> : OTP is totally secure given it is properly used. The problems are key
> : distribution and key cancellation/deletion. [...]
>
> Then there's the issue that a known-plaintext attack reveals the key - and
> possibly allows inauthentic messages to be passed off as the real one.
>
> Authenticity is a problem for OTPs.
>
> With your typical block cypher, knowing the plaintext does *not*
> instantly reveal the message key, and allow forged message(s) to be sent.
> --
This cannot be a problem in correct use of a OTP. The O means "one" no reuse
allowed. No segment of the OTP can be reused. Else it's not a OTP, perhaps a
1.05TP. See the Venona site.
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re:NASA measurements, was: NSA future role?
Date: Thu, 09 Dec 1999 08:19:11 -0700
Reply-To: [EMAIL PROTECTED]
NASA people told me that the problem was a bit more subtle. Reporting of
measurements in US units was changed to reporting in metric units for
some items. This was done quietly. People deal with measurements in
differing systems all the time. It's harder when things are changed
quietly. No one with enough experience to see the difference in the
numbers was working on the project.
As usual, it takes several failures for something not to work.
--
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Dec 1999 15:18:30 GMT
thanks for the answer
On Thu, 09 Dec 1999 14:28:19 GMT, Bob Silverman wrote:
>>(some RSA implementations got issues about that
>
>Citations please?
>This is another "urban legend".
probably my formulation of the problem is wrong but i don't think
it is a urban legend. There is an article of weiner about it.
i found a post on coderpunks of somebody quoting you.
http://www.privacy.nb.ca/cryptography/archives/coderpunks/new/1998-05/0127.html
--
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: Curious PhenomenaRe: High Speed (1GBit/s) 3DES Processor
From: [EMAIL PROTECTED] (MegaZone)
Date: 09 Dec 1999 15:39:44 GMT
[EMAIL PROTECTED] shaped the electrons to say:
>Because his headers contain the following:
>> Content-Type: text/plain; charset=iso-2022-jp
Weird. I guess something is changing that before my server gets it, as I
checked his headers and found:
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
-MZ, CISSP #3762, RHCE #806199299900541
--
mailto:[EMAIL PROTECTED]> Gweep, Discordian, Author, Engineer, me..
Join ISP/C Internet Service Providers' Consortium http://www.ispc.org/>
"A little nonsense now and then, is relished by the wisest men" 781-788-0130
http://www.megazone.org/> http://www.gweep.net/> Hail Discordia!
--
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Dec 1999 15:37:41 GMT
On Thu, 09 Dec 1999 14:28:19 GMT, Bob Silverman wrote:
>> can i reduce x to 128bits (enougth to prevent a brute
Cryptography-Digest Digest #711
Cryptography-Digest Digest #711, Volume #10 Thu, 9 Dec 99 16:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify (Vernon
Schryver)
Re: NP-hard Problems (Anton Stiglic)
symmetric encryption based on integer factoring (Tom St Denis)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (zapzing)
Re: Synchronised random number generation for one-time pads ("Tony T. Warnock")
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: Shamir announces 1 sec break of GSM A5/1 (Tim Tyler)
Re: Shamir announces 1 sec break of GSM A5/1 (Tom St Denis)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Digitally signing an article in a paper journal (wtshaw)
Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamirdescribe
in a paper ... (Jim Dunnett)
Re: NSA future role? (Jim Dunnett)
Re: NSA future role? (Jim Dunnett)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: Shamir announces 1 sec break of GSM A5/1 (Troed)
Re: NSA future role? (JCA)
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify
Date: 9 Dec 1999 10:38:50 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Greg wrote:
>> If you have Microsoft Windows and Internet Explorer, your
>> government has the ability to modify your files. ...
>It would be nice if you could get your facts straight.
>Presumably you're talking about the so-called "NSAkey".
>If so, you've completely mischaracterized it.
Yes, the NSAKey nonsense was silly, but what about an ActiveX applet signed
in the normal way by a nominally legitimate outfit using its official key?
How many people go to the trouble of trying to make Internet Explorer
ignore ActiveX, especially given the obscurity of those buttons, the
warnings from IE after you fiddle with them, and the hassles should you
want to "update" your version of Windows or IE or just check to see what
updates Microsoft is suggesting today?
What about an Outlook Express email attachment?
A paranoid cynic might view the idiotic hysteria about nonsense
such as the NSAkey, the PIII ID, and IPv6 addresses as calculated
efforts make the suckers think--er--feel there are no real problems.
Vernon Schryver[EMAIL PROTECTED]
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Thu, 09 Dec 1999 13:26:15 -0500
I guess it would depend on the definition of the reduction
used. There is more than one definition of reduction in
complexity theory. The one in Intro to Algorithms, from
Cormen, Leiserson and Rivest define reductions as beeing
done in polynomial time of languages (decisional based).
Anton
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: symmetric encryption based on integer factoring
Date: Thu, 09 Dec 1999 19:02:02 GMT
I was plumbing around with the idea of a cryptosystem based around
factoring such as
C = (P * g^x) mod p
P = (C * g^-x) mod p
Where given the ciphertext you have to factor it to determine what the
plaintext could be [as long as p is prime, and g is a generator, and
that the mult. inverse of g is a gen as well]. Each message would
have their own 'x' derived somehow [RNG?]
I then proceded to brutally assalt it. I made an attack using one
known plaintext if you re-use 'x' or use 'x' values close together [by
exploiting the base].
So then I ask what would be a good method of choosing new 'x' values
per message? I was thinking of making x odd, then X=x, x' = x + X, so
the gap between successive X values is not known. Could the same
attack exploit it?
Just an idea :)
I would love feedback.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 09 Dec 1999 12:15:23 -0700
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> "Trevor Jackson, III" wrote:
> > Guy Macon wrote:
> > > [EMAIL PROTECTED] (Tony T. Warnock) wrote:
> > > >The most probable waiting time between decays is zero.
> > > No it isn't.
> > How do you fogiure otherwise? Given an exponential decay expectation
> > the maxima will be at zero.
>
> And the probability that the interval is precisely 0
> is precisely 0. You ought to talk about the density instead.
> Although this all seems irrelevant to the original topic.
I was talking about density.
The main point is that in designing a radioactiv
Cryptography-Digest Digest #713
Cryptography-Digest Digest #713, Volume #10 Thu, 9 Dec 99 22:13:01 EST
Contents:
Re: SRP - a secure alternative for authentication >> Nice reading ... ("anonymous")
Re: High Speed (1GBit/s) 3DES Processor (Christof Paar)
Re: NSA future role? (CLSV)
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
From: "anonymous" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: Thu, 9 Dec 1999 19:37:31 -0700
=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Nice reading ...
> --
> Thanks, Richard
As the author of this I would please ask people to not post my work
without at least asking. Additionaly if you do feel the need to post
stuff please include the URL so people can find updated copies/etc. I
wrote this while sick with the flu and it's quite messed up (read
wrong). I will post an updated version to
http://www.securityportal.com/closet/ sometime this week.
- -Kurt Seifried, MCSE
https://www.seifried.org/
http://securityportal.com/lasg/
http://securityportal.com/closet/
My public keys are available at:
https://www.seifried.org/keys/
http://www.pgpi.org/ - recommended for Windows
http://www.gnupg.org/ - recommended for UNIX
http://www.pgp.com/ - recommended for commercial use
and start using PGP/GnuPG to sign and encrypt your email.
> ===
> SRP - a secure alternative for authentication by Kurt Seifried
>
> December 8, 1999 - If users want to log into
> servers we usually make them authenticate first. This has consisted
> mostly of a username and password pair passed to the server, in
> cleartext, which is fine if you have a 100% physically secure
> network using switches and no interlopers between you and the
> server. Of course there are very few networks like this, so people
> have invented schemes to encrypt and otherwise protect the
> authentication data when it is sent across the network. This has
> been aided by the growth of cryptography, where you have the same
> basic issues (prove to me who you are, in a secure manner, across
> an unsecured channel).
>
> EKE verses AKE
>
> No this is not a wrestling match between a pair of Swedish brothers
> (sorry, I couldn't resist). One of the most fundamental problems to
> encryption is the key exchange. Finding an algorithm or method to
> securely mangle the data so that only the other party can make
> sense of it is easy (there were 50+ algorithms in the initial AES
> candidate selection, now narrowed down to 5). Securely exchanging
> keys with a party that you probably have not communicated with
> before, especially across an insecure channel is difficult at best.
> There are two primary methods currently in use, EKE (Encrypted Key
> Exchange protocol) and AKE (Asymmetrical Key Exchange protocol),
> and there are several others (such as IKE, Internet Key Exchange
> protocol). EKE uses a variety of methods such as RSA, DSA or
> Diffie-Helman, and is susceptible to a number of attacks, one of
> the more important ones being a man in the middle attack. To combat
> this most authentication systems use some form of pre shared
> secret, or use digital signature technology (where trusted third
> parties verify the identity of one or both parties, and is used as
> the pre-shared secret).
>
> EKE based transactions fill a wide variety of needs, and are the de
> facto standard for SSL based transactions (which includes the vast
> majority of online commerce). SSL typically employs certificates,
> which consists of a public and private portion, the public portion
> not only contains a key, but information about the owner (such as
> name, expiry date of the certificate, and so on). This public
> certificate is signed by a trusted third party, such as Verisign or
> Thawte, who have typically convinced large www browser companies
> (like Netscape and Microsoft) to include their certificates with
> the browser software (so by default most users blindly accept it).
> This is the "pre-shared" secret typically used, and it works quite
> well (although it isn't perfect). This systems become much less
> practical however when you want to prove the identity of the client
> (or large numbers of entities). The costs involved of getting a
> third party to verify your identity and issue a certificate are
> quite high (Verisign used to sell them at $20 US but stopped). The
> costs involved in making that certificate portable are even higher
> (a hundred dollars US for a smart card and smart card reader is
> well within the average price range). In addition to this the
> amount of information provide
Cryptography-Digest Digest #712
Cryptography-Digest Digest #712, Volume #10 Thu, 9 Dec 99 22:13:01 EST
Contents:
Re: Shamir announces 1 sec break of GSM A5/1 (Quisquater)
Re: Shamir announces 1 sec break of GSM A5/1 (Lauri Pesonen)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Steve K)
Re: Synchronised random number generation for one-time pads
([EMAIL PROTECTED])
Re: Digitally signing an article in a paper journal ("Roger Schlafly")
Re: Synchronised random number generation for one-time pads ("Charles Meigh")
Re: low exponent in Diffie-hellman? (Scott Fluhrer)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: weak algorithm, too hard for me (Gaccm)
Re: weak algorithm, too hard for me (Olan I. Merky)
Absent source code now available (Avi Rubin)
Re: NSA future role? (Tim Tyler)
Re: Shamir announces 1 sec break of GSM A5/1 (Tim Tyler)
Re: weak algorithm, too hard for me (JPeschel)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: Shamir announces 1 sec break of GSM A5/1 ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: NSA future role? ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Thu, 09 Dec 1999 22:22:42 +0100
See
http://cryptome.org/a51-paper.htm
--
From: Lauri Pesonen <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: 09 Dec 1999 23:25:48 +0200
[EMAIL PROTECTED] (Troed) writes:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >Ok first off GSM is a european standard is it not? So what does this
> >have todo with america?
>
> What do you have to do with this? GSM is used in the US too, yes, and
> this newsgroup isn't for americans only, no.
>
> >Second I seriously doubt the size of their HD affects the attack speed.
>
> Of course the amount of data you can play with affects the attack
> speed.
There is a known time-memory trade-off attack against A5/1 in which
case the HD space is very usefull and speeds the attack up.
See
http://jya.com/a5-hack.htm
> >Third the majority of the data from the cell phones is unencrypted
> >anyways. I seriously doubt the majority of privacy violations are
> >based on broken crypto.
>
> No, GSM voice communication is always encrypted.
Actually that is not quite true. The A5 algorithm is always used, but
the used A5 algorithm does not have to implement any crypto. There are
different A5 implementations for different countries. The 'strong' A5
(called A5/1) is used mainly in European countries. The time
complexity of A5/1 used to be around 2^45 (I did not read the Shamir
article). A weaker A5/2 algo is used in other countries e.g. the
U.S. The time complexity of A5/2 is assumed to be around 2^16. There
is also a A5/0 algo, which means no encryption at all. A5/1 is the
interesting algo from a academic point of view.
--
! Lauri
--
From: [EMAIL PROTECTED] (Steve K)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Thu, 09 Dec 1999 22:17:38 GMT
On Thu, 09 Dec 1999 19:05:34 GMT, zapzing <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> "fuck echelon" <[EMAIL PROTECTED]> wrote:
>
>Love the name. You had celebrity parents too,huh?
>
>But seriously, I agree that the main problem would be
>that somebody (probably _not_ the police, actually)
>would break in and covertly install a bug or alter the
>software in the computer.
>
>I think the best that can be done is to make it
>impossible for them to do it _covertly_.
>And there may be ways to do this in software,
>or at least I suspect that there are,
>but apparently anyone who knows anything
>is not talking.
>At least not in this group.
Oh!
:o)
Steps in the right direction:
1) PGP sign your registry (ole.reg in /windows/system/). Test it
regularly. Test it before, and update it after, installing or
removing any software. This should guard against most hidden trojans.
2) PGP sign the .exe files of every network application you use, and
your anti-virus .exe files. These are the most likely programs to be
patched to add "special" functions. Add any crypto and file wiping
utilities you may have, to the signature list.
3) Get and use a firewall, and yes, PGP sign its .exe file(s).
You will be more likely to keep up the practice of testing these sigs,
if you put shortcuts to all of them in a handy folder on your desktop.
I haven't tried putting shortcuts to signatures in the start-up file,
but it sounds like a fun experiment.
What about the operating system itself? Okay, reinstall from a known
good copy, and go and
Cryptography-Digest Digest #714
Cryptography-Digest Digest #714, Volume #10 Fri, 10 Dec 99 02:13:01 EST
Contents:
Re: Any comments on "Day of Deceit" by Robert Stinnett? ("Douglas A. Gwyn")
Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
Re: Shamir announces 1 sec break of GSM A5/1 (Tom St Denis)
Re: weak algorithm, too hard for me (Gaccm)
Re: symmetric encryption based on integer factoring (Scott Fluhrer)
Re: Shamir announces 1 sec break of GSM A5/1 (Ian Goldberg)
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Trevor Jackson, III")
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Trevor Jackson, III")
Re: If you're in Australia, the government has the ability to modify ("Trevor
Jackson, III")
Re: NSA future role? ("Trevor Jackson, III")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describein
a paper ... ("Trevor Jackson, III")
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Any comments on "Day of Deceit" by Robert Stinnett?
Date: Fri, 10 Dec 1999 03:18:29 GMT
Gondolin Remailer wrote:
> FOIA requests) to bolster the revisionist case. The main allegation
> by the critics (a couple of whom claim to be Navy crypto experts) made
> in reply seems to be that Stinnett was sloppy in how he characterized
> American cryptanalysis capabilities in 1940/1941. The question is, is
> this just irrelevant nit-picking by the critics, or did Stinnett
> really miss something important?
Stephen P Budiansky's review is right on the mark.
I have no love of FDR, but it is certain that the US did not
know specifically that Pearl Harbor would be attacked at about
that date. One thing the Japanese cleverly did was to leave
their radio operators behind, transmitting in their recognizable
"fists", to convince us that their ships were still in home
waters when in actuality they were sailing under radio silence.
--
From: Dave Knapp <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 03:48:27 GMT
On Fri, 10 Dec 1999 02:32:46 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Guy Macon wrote:
>> I was under the impression that the exponential decay came
>> from the fact that there are a finite number of atoms in
>> the sample and that each atom decays only once. I don't
>> think (correct me if I am wrong) that individual radium
>> atoms have an exponential decay expectation.
>
>Okay: you're wrong. Even an individual nucleus in an excited
>state has a well-defined decay "half-life" and thus an
>exponential function of time for its decay probability.
Actually, for a change, _you're_ wrong! It's the first time I've ever
seen.
An individual nucleus (or any other kind of quantum system) has a
constant decay probability per unit of time. As a result, the
integral probability that it has decayed by a certain time is
exponential, but the probability of decay is constant.
-- Dave
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Fri, 10 Dec 1999 03:54:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> What do you have to do with this? GSM is used in the US too, yes, and
> this newsgroup isn't for americans only, no.
But why I thought GSM was seriously flawed [on the crypto side].
> >Second I seriously doubt the size of their HD affects the attack
speed.
>
> Of course the amount of data you can play with affects the attack
> speed.
Generally though you don't consider it because disk speeds are much too
slow. A million reads from a hd is much slower then from mem.
> No, GSM voice communication is always encrypted.
... Over the air ... [or am I just plain wrong here?]
> >Fourth Why not just point to the url of the article?
>
> Because it's easier to read it right away when posted? It wasn't very
> long.
Maybe.
> >That's my 2 cents.
>
> They're not worth much ...
Well they are canadian cents so with the exchange rate it's about one
billionth of a penny or so.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Gaccm <[EMAIL PROTECTED]>
Subject: Re: weak algorithm, too hard for me
Date: Thu, 09 Dec 1999 21:10:22 -0800
Reply-To: [EMAIL PROTECTED]
so how were you able to solve it?
--
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: symmetric encryption based on integer factoring
Date: Fri, 10 Dec 1999 05:45:51 GMT
In article <82oub7$dg2$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>I was plumbing around with the idea of a cryptosystem based around
>factoring such as
>
>C = (P * g^x) mod p
>P = (C * g^-x) mod p
>
>Where given the ciphertext you have to factor it to determine what the
>plaintext could be [as long as p is
Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #10 Fri, 10 Dec 99 02:13:01 EST
Contents:
Random Numbers??? (John)
Re: Digitally signing an article in a paper journal ("Trevor Jackson, III")
Re: Synchronised random number generation for one-time pads ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
From: John <[EMAIL PROTECTED]>
Subject: Random Numbers???
Date: Thu, 09 Dec 1999 22:27:17 -0800
I have been kicking around random # generators. I have 3 sets of 1000
random #s. Are they? How can you tell? Integers range from 0 through
255 inclusive.
Set1---Set2---Set3
113126114
227 80140
165240210
24211242
122139 44
225125146
104 77197
152194194
195246 35
124 23212
225121120
105 34169
112194 41
222100 92
203118 65
97158188
22188241
13185140
51231 58
40254203
210165205
215 31109
102110 83
169239172
205229191
253253105
134252 27
21 5178
100 16 58
130 4 97
250132104
181 78159
117 88242
179 4 27
158 65222
184 37108
97 71 93
218253 36
20 63222
254 94 74
12198 62
177239 36
169237219
30 89 95
230202252
213 11250
147 68109
128252230
68 86 55
139115253
90160104
66221 29
2111 56
65 16236
89155 37
130 4 43
204 15 47
241 13100
197 60 52
194174182
77 9225
3229 91
86 85251
133159142
64188 57
159 92 12
203177 18
233152213
26170115
132195110
200175123
108126225
52144 31
28228198
87 63245
187127 18
235138125
113137107
144222155
10 69115
31210233
99255184
209122158
99 36 55
155 41111
167206179
171217146
176158 40
116 2 71
182 74237
89238 12
98 95 65
219137 96
184233101
187159100
234109 63
234 64 24
35 61 64
86 17159
177 17 86
89 21 87
121 1136
44244137
97143 90
0110241
23192137
214110 41
46 82 30
224 27 19
25134223
133 33 95
119111221
189232117
25231128
91 56 82
82234251
64108 83
182193 36
210192229
69 30 7
0 32110
180 7186
183 57241
11232225
133125251
217172166
141111 78
58165214
161 75242
52181 74
182147155
245 79152
85169194
190 2254
61102141
217107120
254 83207
175 38159
239186136
104 99101
13239112
102137 96
78 99120
34194151
205245207
115141173
109147197
230226 84
33177202
193 17 30
33230168
177254129
149186174
102184 50
129170 58
113 67192
35165 36
139101220
191164184
85127177
249198 72
241135198
62142121
95211 26
37142227
144160233
167161238
85153218
114 32 62
132 88120
194179 9
94 23 34
157 0239
55184 16
40191112
123 70 64
95 90 55
233107229
60244164
209 73 86
156232139
62107 45
81 72164
81109 85
69201223
201 19183
44183 41
162 8 86
9144143
60 9 18
44126251
11 93169
137 24119
101 65110
248243 90
50119 38
103 0255
185175220
107173194
7 68162
194 75212
140239121
151 48 43
198187228
147209102
196 49231
161 9138
162162 86
115 97131
101 24176
153 70 79
Cryptography-Digest Digest #716
Cryptography-Digest Digest #716, Volume #10 Fri, 10 Dec 99 08:13:01 EST
Contents:
Re: Synchronised random number generation for one-time pads (Johnny Bravo)
Linear Structures (Raphael Phan Chung Wei)
Re: Random Numbers??? (Johnny Bravo)
Re: NASA measurements, was: NSA future role? (Gurripato)
Re: Shamir announces 1 sec break of GSM A5/1 (Gurripato)
Re: Shamir announces 1 sec break of GSM A5/1 (Gurripato)
Re: Digitally signing an article in a paper journal (KloroX)
Re: Digitally signing an article in a paper journal (KloroX)
Re: Shamir announces 1 sec break of GSM A5/1 (Oyvind Eilertsen)
Re: Random Noise Encryption Buffs (Look Here) ("Douglas A. Gwyn")
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: Linear Structures ("Douglas A. Gwyn")
Re: weak algorithm, too hard for me (JPeschel)
Re: old Microsoft Mail 3.0b encryption? (JPeschel)
Attacks on a PKI ([EMAIL PROTECTED])
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Synchronised random number generation for one-time pads
Date: Fri, 10 Dec 1999 03:17:39 GMT
On Thu, 9 Dec 1999 23:17:10 -, "Charles Meigh"
<[EMAIL PROTECTED]> wrote:
>Thanks everyone, I hadn't come across the problem of interception and
>forgery yet. I think I'll add a decent physics textbook to my shopping
>list as well as cryptology. I'm still thinking that there might be some
>vastly wide choice of 'celestial' events that could produce truly random
>numbers that will still be sufficiently similar observed from any two (or
>more) points on the globe, which would make OTP use more economical.
Your problem is that what your two people can see, the attacker can
see too. Even if they both start at the same microsecond when
recording information, the attacker has less microseconds to start
checking then the keyspace in a properly designed cipher.
The attacker just starts recording the data and when a message comes
in, he just checks it against every microsecond starting point and
eventually decrypts the message in short order.
Best Wishes,
Johnny Bravo
--
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Linear Structures
Date: Fri, 10 Dec 1999 16:18:51 +0800
We often hear that at least some part of the block ciphers should be
non-linear otherwise it would be easy to obtain the unknown key bits.
What is the justification for that? By saying non-linear, does that
mean with respect to the XOR operation?
--
Regards,
Raphael Phan
--
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Random Numbers???
Date: Fri, 10 Dec 1999 03:30:18 GMT
On Thu, 09 Dec 1999 22:27:17 -0800, John
<[EMAIL PROTECTED]> wrote:
>I have been kicking around random # generators. I have 3 sets of 1000
>random #s. Are they? How can you tell? Integers range from 0 through
>255 inclusive.
This is far too small a sample to do anything meaningful with.
Generate about 20 million values, write them to a file as bytes, and
run the statistical tests on them. You will never be able to prove
randomness, but you can get a good probability check on the randomness
of the values.
Best Wishes,
Johnny Bravo
PS: And no, we don't want you to post the 20 million values here. :)
--
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: NASA measurements, was: NSA future role?
Date: Fri, 10 Dec 1999 08:11:01 GMT
On Thu, 09 Dec 1999 08:19:11 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>NASA people told me that the problem was a bit more subtle. Reporting of
>measurements in US units was changed to reporting in metric units for
>some items. This was done quietly. People deal with measurements in
>differing systems all the time. It's harder when things are changed
>quietly. No one with enough experience to see the difference in the
>numbers was working on the project.
>
It remind me of a Star-wars experiment back in the 80´s. A
ground laser was to send up a beam to a mirror aboard a space shuttle.
Unfortunately, the software was told that the mountain the laser was
in was X miles instead of X feet (the beam probably blasted down to
the floor, I imagine). Error corrected, successsful hit. Even in US
units.
--
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: Shamir announces 1 sec break of GSM A5/1
Date: Fri, 10 Dec 1999 08:14:39 GMT
On Thu, 09 Dec 1999 15:29:44 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]=NOSPAM
>(Gurripato) wrote:
>>Another proof is that, in many countries, that demonstration
>>would break the law, so researchers are forbidden fro
Cryptography-Digest Digest #717
Cryptography-Digest Digest #717, Volume #10 Fri, 10 Dec 99 10:13:01 EST
Contents:
Re: symmetric encryption based on integer factoring (Tom St Denis)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: symmetric encryption based on integer factoring ([EMAIL PROTECTED])
Re: weak algorithm, too hard for me (Guy Macon)
Re: If you're in Australia, the government has the ability to modify ("Trevor
Jackson, III")
Re: Digitally signing an article in a paper journal ("Trevor Jackson, III")
Re: Synchronised random number generation for one-time pads ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: symmetric encryption based on integer factoring
Date: Fri, 10 Dec 1999 13:00:06 GMT
In article <82q3tn$s27$[EMAIL PROTECTED]>,
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> This problem appears to have nothing to do with "factoring". It's
> strength, if any, looks like it be closer to the discrete log problem.
> Also, the multiplicative inverse of a generator is always a generator,
> so there's no need to specify it directly.
Oh ok.
> Well, lets make a preliminary analysis of it. I assume that g and p
are
> publicly known parameters. Since you do not describe how x is
generated,
> let us assume that all possible values of 0 <= x < p-1 are equally
probable.
> Then, we immediately note that all values of g^x from 1 <= g^x < p are
> equally probable, since because g is a generator, there is a one-to-
one
> mapping between the two. So, your system could be simplified to:
>
> C = (P * y) mod p
> P = (C * y^-1) mod p
>
> Where all values 1 <= y < p are possible. Next, we note that, for any
> possible pair P, C, there is a unique y s.t.
>
> C = (P * y) mod p.
>
> In other words, for any C, for each possible plaintext P, there is a
> key that will decrypt it to that plaintext. This implies that this
> system is essentially an OTP, except it's a lot harder to evaluate.
>
> And so, *all* the strength of the system is in how you generate x.
Yes and no. There is a reason why I chose g^x mod p, instead of just x.
> Essentially. Assume the attacker has the plaintext/ciphertext for the
> first message. Then, he can compute:
>
> g**X = C * P**-1 mod p
>
> Then, given the nth ciphertext Cn, he can compute
>
> Pn = Cn * (g**X)**-n
>= Cn * (g**-nX)
>
> I believe any linear method of assigning x's will have the same
problem.
That's what I thought. Originally I said why not just increment x mod
p-1. But I then proceded to break it ... :)
> >Just an idea :)
>
> BTW: why do you think that this is even slightly practical? You
require
> a full modular exponentiation for every single message. You can run
> RSA just as fast.
It's not, but I am toying with number theory. They don't teach it in
school so I have to work it out myself, and ask here once in a while.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 10 Dec 1999 08:17:09 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>OTPs are generally quite secure against eavsdroppers who don't know the
>message they contain. They're useless against simple complete
>known-plaintext attacks.
It depends on what you mean by "useless". I would say that being able
to send other plaintexts without the attacker being able to decode
them is quite usefull, wouldn't you? The known-plaintext attack
described does allow interception and substitution, which is another
way of saying that an OTP has limited value as a digital signature.
The known-plaintext attack never allows the attacker to do anything
with a message other than his known-plaintext message. That's useful.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 10 Dec 1999 08:25:41 EST
In article <82pet6$cob$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Charles Meigh) wrote:
>
>Thanks everyone, I hadn't come across the problem of interception and
>forgery yet. I think I'll add a decent physics textbook to my shopping
>list as well as cryptology. I'm still thinking that there might be some
>vastly wide choice of 'celestial' events that could produce truly random
>numbers that will still be sufficiently similar observed from any two (or
>more) points on the globe, which would make OTP use more economical.
You have that already. Just generate your random numbers using whatever
method you prefer and post them in a newsgroup. Or you can put them on
a CD and sell the CD on a web site. Or bro
Cryptography-Digest Digest #718
Cryptography-Digest Digest #718, Volume #10 Fri, 10 Dec 99 14:13:02 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir (Douglas Hinton)
Re: low exponent in Diffie-hellman? (jerome)
Re: Attacks on a PKI (JCA)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: NSA future role? (Tim Tyler)
Re: Random Numbers??? (John)
Re: Digitally signing an article in a paper journal (Frank Gifford)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
The Love Song of Softbytelabs.com (JPeschel)
Re: low exponent in Diffie-hellman? (Scott Fluhrer)
Re: symmetric encryption based on integer factoring (Tom St Denis)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: Paradise shills?? (Tim Tyler)
Re: Attacks on a PKI (Gurripato)
Re: If you're in Australia, the government has the ability to modify (Medical
Electronics Lab)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: Shamir announces 1 sec break of GSM A5/1 (wtshaw)
Re: Attacks on a PKI (DJohn37050)
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Fri, 10 Dec 1999 08:09:31 -0700
Reply-To: [EMAIL PROTECTED]
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony T.
>Warnock) wrote:
>
> >Another (not very problematic) property is that the number of counts in a
> >fixed amount of time is more likely to be even than odd.
>
> Why would this be so?
The sum of the even terms of the Poisson distribution is slightly larger than the sums
of the odd terms
for any parameter. I doubt that this is a real problem.
--
From: Douglas Hinton <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir
Date: Fri, 10 Dec 1999 16:42:52 +0100
Intercepting a cell phone conversation isn`t hard. You need only a
scanner radio and a Ham Com interface. The scanner radio needs a simple
modification to by pass the audio circuit.The signal can be put directly
into a computer and processed. I have intercepted digital signals(not
cell phone), made .wav files of them , converted the files to binary
numbers.Only problem I see with cell phone interception is that they use
a trunking system. That is that the signal is handed off from one base
station to another or channels are switched.Even a standard scanner
radio can follow most of the hand-offs if the base station frequencies
are programed in. Douglas
--
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 15:56:18 GMT
On Fri, 10 Dec 1999 00:10:19 GMT, Scott Fluhrer wrote:
>I'll let bobs respond to the security implications, but if you
>are using 'square and multipy', why don't you go to a more
>efficient modular exponentiation algorithm. In particular, why
>don't you look at the algorithms in 14.6 of the Handbook of
>Applied Cryptography, which should speed you up by 30% with *no*
>reduced security.
Which one exactly are you speaking about ?
If i understand them correctly, the 14.6.1 ones are all variations
of the 'square & multiply'. I haven't look at 14.6.2(fixed exponent)
and 14.6.3(fixed base) sections, are they 30% faster ?
--
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Fri, 10 Dec 1999 08:39:25 -0800
[EMAIL PROTECTED] wrote:
> Having read much of the literature on PKI, it is fairly conclusive that
> this whole PKI thing is an exploitation of people's ignorance.
Could you elaborate on that?
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 16:49:57 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> What if this guy is the radio operator? You expect him to memorise
:> the text of every message he sends?!
:> He may no longer have access to the plaintext of the message - while he
:> may still remember the password he used as a key to encrypt it.
: Your model of encrypted radio operations is nothing like
: what has really been done, and even farther from the current
: mode of operation. [...]
So what? It was a counter-example.
The man who sent the plaintext may not know what it said.
Torturing him for plaintext under these circumstances would be useless.
QED.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Lottery: A tax on people bad at maths.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 16:59:30 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Ti
Cryptography-Digest Digest #719
Cryptography-Digest Digest #719, Volume #10 Fri, 10 Dec 99 17:13:01 EST
Contents:
Re: Ellison/Schneier article on Risks of PKI (DJohn37050)
Re: If you're in Australia, the government has the ability to modify yourfiles.
>> 4.Dec.1999 (James Redfern)
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir (Keith A Monahan)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: NSA future role? (wtshaw)
Re: NSA future role? (wtshaw)
Re: symmetric encryption based on integer factoring ([EMAIL PROTECTED])
Re: High Speed (1GBit/s) 3DES Processor (Michael Paoli)
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: low exponent in Diffie-hellman? (jerome)
Re: symmetric encryption based on integer factoring (Tom St Denis)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir ("H.
Ellenberger")
Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir ("H.
Ellenberger")
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Ellison/Schneier article on Risks of PKI
Date: 10 Dec 1999 19:10:55 GMT
I think this is a very nice paper that asks some fundamental questions.
For those interested in more info, Peter Landrock of Cryptomathic in Denmark
has also asked some similar questions about the PKI.
Don Johnson
--
From: James Redfern <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 10 Dec 1999 18:48:37 +
Reply-To: redfernprivacyxcom
On Tue, 07 Dec 1999 20:08:06 GMT, amadeus @DELETE_THIS.netcomuk.co.uk (Jim
Dunnett) wrote:
| >"These are really untested waters," says Chris Connolly, a vocal Australian
| >privacy advocate. "I don't think there's any example anywhere else in the world
| >that's comparable."
|
| He's a bit out of touch. It's been proposed in 'democratic' Britain, but
| not yet been put into law.
The ELECTRONIC COMMERCE bill passed its first reading 30/11/99 without much
effort. Read it?
You might want to take a look at the DTI web site under something they
euphemistically call "PROMOTING ELECTRONIC COMMERCE":
http://www.dti.gov.uk/cii/elec/ecbill_1.html#Contents
If that doesn't put you off then try:
http://www.fipr.org/ecomm99/part1.html
JR.
-- James Redfern <[EMAIL PROTECTED]> The Redfern Organization
[PGP Key ID:0x8244C43A available from <[EMAIL PROTECTED]> Subject: "get
0x8244C43A"]
...ActiveNames delivers my undeliverable mail at www.ActiveNames.com
--
From: [EMAIL PROTECTED] (Keith A Monahan)
Crossposted-To: alt.privacy
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir
Date: 10 Dec 1999 19:19:36 GMT
Douglas,
Your post wasn't incredibly clear and I'd like to fix it up.
Douglas Hinton ([EMAIL PROTECTED]) wrote:
: Intercepting a cell phone conversation isn`t hard.
Intercepting an ANALOG cell phone call isn't hard.
If the scanner was manufactured before the current 'privacy' laws, no
modification is required to listen to the frequency range. I'm speaking
of current US laws(not .dk) and frequencies.
If the scanner was manufactured AFTER, then a small modification, usually
removing a diode perhaps a few resisters, is required to 'open' the radio
to receive those types of calls.
: You need only a
: scanner radio and a Ham Com interface. The scanner radio needs a simple
: modification to by pass the audio circuit.The signal can be put directly
: into a computer and processed.
Yes, performing what's known as a descriminator modification or tap, allows
you to get access to the 'raw' signal received.
: I have intercepted digital signals(not
: cell phone), made .wav files of them , converted the files to binary
: numbers.
If you are referring to POCSAG or FLEX paging or perhaps MDT, thats one thing.
Decoding the paging protocols is simple and there exists software out there
to do just that. POC32 comes to mind.
However, digital VOICE conversations is another story. I haven't seen a
program yet that will take the output from a descrim. tap, decode it, and
then output the voice via your sound system. I keep my ear to the ground
and haven't seen anything like that. By all means, let us know if you
have seen this and provide us a download reference! :)
Furthermore, you're assuming the digital voice is in PLAINTEXT. If it's
encrypted this adds to the complexity of the problem. It doesn't make
it IMPOSSIBLE but it makes the task HARD, assuming cryptanalysis on the
used algorithm yields an easy break. And easy in the crypto world could
mean a month's processing 1 second
Cryptography-Digest Digest #720
Cryptography-Digest Digest #720, Volume #10 Fri, 10 Dec 99 22:13:00 EST
Contents:
Re: Attacks on a PKI ("Lyal Collins")
Linear Congruential Generators ("Steven Alexander")
CDSA 1.2 specs (JCA)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Random Numbers??? (Keith A Monahan)
Re: Linear Congruential Generators ("Steven Alexander")
Re: NSA future role? (Terry Ritter)
Re: Attacks on a PKI ([EMAIL PROTECTED])
Re: Attacks on a PKI ([EMAIL PROTECTED])
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: Linear Congruential Generators ("Douglas A. Gwyn")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Rick Braddam")
Anyone using Freedom 1.0 ? What are your thought? [nt] ([EMAIL PROTECTED])
Re: Linear Congruential Generators (David A Molnar)
Re: Attacks on a PKI (David A Molnar)
Re: Anyone using Freedom 1.0 ? What are your thought? [nt] (Steve K)
Questions about message digest functions (Pelle Evensen)
Re: Digitally signing an article in a paper journal ("rosi")
Re: Questions about message digest functions (Jim Gillogly)
Re: NSA should do a cryptoanalysis of AES ("Rick Braddam")
Re: If you're in Australia, the government has the ability to modify your files.
>> 4.Dec.1999 ("Rick Braddam")
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Sat, 11 Dec 1999 09:30:23 +1100
- Replacing the Rooth CA key in everyone's clients
- Modifying clients to verifying against multiple Root CA's
- Storing private keys on an insecure workstation
- Using a password processed and verification on an insecure workstation to
permit private key use
- having to archive messages and signatures and certs in "average security"
databases (if the database record is later modified, the signature cannot be
re-verified, and the recipient loses a case, unless they can _prove_ their
database and systems admin is top notch for the entire period. The UK
Munden case is an example where a bank couldn't do this - for it's internal
reasons.
- the need for a highly secure CA and secure Client is approximately the
same effort required in a secret key scheme to keep both end points secure.
Not strictly on-topic, but an important cost consideration.
Most of this is paraphrasing stuff in the recent Schnier and Ellison paper -
but have always been obvious.
Lyal
[EMAIL PROTECTED] wrote in message <82qq8g$odp$[EMAIL PROTECTED]>...
>Having read much of the literature on PKI, it is fairly conclusive that
>this whole PKI thing is an exploitation of people's ignorance.
>
>I am currently compiling a list of attacks on a PKI, and if you know of
>any then please post some.
>
>David
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Linear Congruential Generators
Date: Fri, 10 Dec 1999 14:34:22 -0800
I was reading about LCG's in The Art of Computer Programming and have also
read briefly about them in Applied Cryptography. I was wondering if they
can be used to generate keys for a cryptographic algorithm with a new
approach. If you were using strong values for the multiplier and increment
value(so that it would iterate through all possible values of x) could you
seed the generator with user input? My idea was to generate 128-bit key by
the following:
Either
a) ask the user to enter 4 32-bit numbers
b) ask the user to type randomly and create 4 32-bit numbers by shift and
XOR
Then:
Use the generator numbers to seed four instances of the generator
Ask the user to specify a number of iterations
Use the values of x at the end of the last iteration as your key
I would love to hear any problems with this scheme and any suggestions for
an improvement of this method.
--
Steven Alexander
[EMAIL PROTECTED]
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
--
From: JCA <[EMAIL PROTECTED]>
Subject: CDSA 1.2 specs
Date: Fri, 10 Dec 1999 14:21:29 -0800
Does anybody know where to get the CDSA 1.2 API specs in electronic
format? At Intel they only carry those for CDSA 2.0 these days.
--
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Fri, 10 Dec 1999 15:46:56 -0700
Reply-To: [EMAIL PROTECTED]
Steven Alexander wrote:
> I was reading about LCG's in The Art of Computer Programming and have also
> read briefly about them in Applied Cryptography. I was wondering if they
> can be used to generate keys for a cryptographic algorithm with a new
> approach. If you were using strong values for the multiplier and increment
> value(so that it would iterate through all possible values of x) could yo
Cryptography-Digest Digest #721
Cryptography-Digest Digest #721, Volume #10 Sat, 11 Dec 99 01:13:00 EST
Contents:
Totally off (Re: NP-hard Problems) ("rosi")
Re: low exponent in Diffie-hellman? (Scott Fluhrer)
Re: SRP - a secure alternative for authentication >> Nice reading ... ("rosi")
Re: Ellison/Schneier article on Risks of PKI ("rosi")
Re: Digitally signing an article in a paper journal ("rosi")
New RNG Technique (Steve Harris)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
From: "rosi" <[EMAIL PROTECTED]>
Subject: Totally off (Re: NP-hard Problems)
Date: Fri, 10 Dec 1999 22:58:24 -0500
Dear Bill,
Do not be discouraged. See there are all those intelligent people,
the issue is still so 'definite' ...
It may depend on what you were taking as the definition of NP-hard.
There is only one, right? Well, only when some ONS guy comes up
with another, even if equivalent. Else thousands of copies can float
around and nobody blinks. :)
I thought I was seeing a definition, but the very moment it went to
errata. :-\ We once were hacking out the definition of complexity.
I hope we do not do one for definition itself.
(Not personal, though I mention names for things do not get
created out of the void)
Anton held (I believe) that was a definition. Did not quake a bit
till he probably went along the pointer. Well, how can he, just in
the flash of a second, turn a definition to a non-definition?
HP was brought in as a support for the tangibility of HPh. Can
we think a bit? (Sure, redundant, by def.)
One of Safaut's post is very good, but one thing I paid special
attention: 'if NP != PSPACE' and 'it is widely believed'. Can hardly
deduce anything (but well, sure we can).
Somebody mentioned the reduction issue. I would like to bring
people's attention to the piece I said to be held firmly for people
to see. Safuat made it clear and well, if I am not mistaken, that
poly reducibility had its scope of being meaningful as far as
complexity is concerned.
It is funny that whenever, it seems, this comes up, I either get a
proof of P != NP or the cat stuff, not the Schroedinger type but much
worldly kind. (Please, not personal, but I can not help it) There is:
There are NPh ones and there are NPc ones.
Well, for all the cats in the world there are white cats. And we know
there are white ones. It did not get put the other way round: Since
there are white cats, so there are cats.
If ever (BIG IF) P = NP, we will have the ideal situation: an NP-hard
problem is a problem. Universal, absolute truth. Only that what I over-
heard about absolute truth did not sound very pleasant. :)
--- (My Signature)
Bill Unruh wrote in message <827f7i$27j$[EMAIL PROTECTED]>...
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (James Pate
Williams, Jr.) writes:
>
>>What are some problems that are NP-hard but not NP-complete? I know
>
>Well, it is not known if there are any NP hard problems. But assuming
>that say factoring is NP hard, I believe it is not NP complete.
--
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: low exponent in Diffie-hellman?
Date: Sat, 11 Dec 1999 03:55:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (jerome) wrote:
>On Fri, 10 Dec 1999 17:37:08 GMT, Scott Fluhrer wrote:
>>>Which one exactly are you speaking about ?
>>>If i understand them correctly, the 14.6.1 ones are all variations
>>>of the 'square & multiply'. I haven't look at 14.6.2(fixed exponent)
>>>and 14.6.3(fixed base) sections, are they 30% faster ?
>>>
>>I was thinking of 14.6.3, specifically. The obvious square & multiply
>>takes 1.5*lg(N) expected multiplies (where N is the exponent) while
>>14.6.3 is closer to 1.1*lg(N) expected for the range of N's we're
>>talking about.
>>
>>Ok, maybe 30% is a little over-optimistic. 25% is realistic.
>
>interresting but unfortunatly i can't use them. My application has indeed
>a fixed g and p (with g^x mod p). But i do a diffie-hellman key exchange
>with it:
>- The offer (g^x mod p) can be precomputed and used several times
> so it's cost is amortized.
>- The reply (m^x mod p with m=g^y mod p) is harder, it can't be
> precomputed or reused.
>
>To optimize my computation, i have to optimize the second case.
>I will look at the fixed exponent algorithms to see how efficient
>they are in my case.
One of us is confused. The sliding window exponentiation does evaluate
m^x mod p, with no special preconditions on m, x or p. So, why can't
you use it?
I've used it (actually, a varient of it) with DH before, and had no
problems.
--
poncho
--
From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: Fri, 10 Dec 1999 23:18:33 -0500
Did not do the nice reading but took another look at the SRP paper.
Do not know if I am lo
Cryptography-Digest Digest #722
Cryptography-Digest Digest #722, Volume #10 Sat, 11 Dec 99 11:13:01 EST
Contents:
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Linear Congruential Generators (wtshaw)
Re: Questions about message digest functions (wtshaw)
Re: If you're in Australia, the government has the ability to modify (fungus)
Re: Random Numbers??? (Scott Nelson)
Re: Random Numbers??? (Scott Nelson)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: Questions about message digest functions (Paul Rubin)
Re: New RNG Technique ("Douglas A. Gwyn")
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 ("Rick Braddam")
Re: Random Numbers??? (Anthony Stephen Szopa)
Re: Linear Congruential Generators ("Gary")
Former DDS database cracked (CLSV)
Scott's Screaming Security Method (SCOTT19U.ZIP_GUY)
Re: Random Numbers??? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Linear Congruential Generators (Tim Tyler)
Re: If you're in Australia, the government has the ability to modify ("Trevor
Jackson, III")
Re: Questions about message digest functions (Tim Tyler)
Re: Questions about message digest functions (Tim Tyler)
Re: Attacks on a PKI (DJohn37050)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Fri, 10 Dec 1999 23:49:38 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > An html format pushed a reliance on the browser, *text* being better.
> > Reminders: html is not friendly to casual use of what it considers
> > control characters, while text is. For a full descussion of character
> > sets and programming, html is a backward's movea dumbing down.
>
> We were talking about a help system, not arbitrary text being
> incorrectly converted into HTML format. HTML supports hyperlinks,
> which are extremely useful, as Ted Nelson explained for decades.
And, Helps need to extend conveniently to ANYTHING, in the most complete
manner possible, especially in matters of programming. If you must, and
are not too lazy, copy and paste a URL. It that in attempting to be
universal, lots of reality needs to be dismissed as inconsistent for the
simple-minded, where it is the fine points that at times can count most.
--
When the horse dies, get off.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Linear Congruential Generators
Date: Sat, 11 Dec 1999 00:08:26 -0600
In article <82s5nv$b7u$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote about multiseeded keys, which I consider a
most useful option for algorithms not easily tapped in a simple sequence.
> Steven Alexander <[EMAIL PROTECTED]> wrote:
> Your goal is key generation? What does this gain over using the
> randomly typed values directly?
It makes a key generator possible at both ends. This means that the
runtime key can be derived from something meaningful, subject to being
remembered, not stored.
>
>
> I think that if you allow someone to input values and get out
> "sufficiently many" keys(*), they will be able to recover enough
> information to predict the LCG on any seed.
If the runtime key and algorithm are good, no. Most that come casually to
your mind are bad, however.
> It then seems to me that this method will give you no better protection
> than using the user's 128 bits as they are. So no real reason to use it.
>
Even a simple LCG is adequate if properly used, much to the disgust of
those that do not what simple things to work sufficiently.
--
When the horse dies, get off.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Questions about message digest functions
Date: Sat, 11 Dec 1999 00:12:42 -0600
In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
> Have there been any papers published on
> 1a) Whether SHA-1 is a permutation for a message the same length as the
> digest-length (160 bits)?
> 1b) Whether this (1a) holds true for MD5?
> 1c) Is this true (or can it be true) for any other, supposedly secure,
> one-way, collision resistant, hash-functions?
>
> 2a) Whether SHA-1 in a feedback loop, d[n] = h(d[n - 1]), has any short
> periods?
> 2b) Has MD5?
> 2c) Other message digest functions regarded as secure?
>
> For any 2[abc] to hold, it seems like 1[abc] also has to hold for a majority
> of the possible values of h(m).
>
1c holds a host of sins of presumption.
--
When the horse dies, get off.
--
From: fungus <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Fri, 10 Dec 1999 22:45:33 +0100
"Douglas A. Gwyn" wrote:
>
> "Trevor Jackson, III" wrote:
Cryptography-Digest Digest #723
Cryptography-Digest Digest #723, Volume #10 Sat, 11 Dec 99 12:13:01 EST
Contents:
Re: New RNG Technique ("Trevor Jackson, III")
Re: New RNG Technique (Pelle Evensen)
Re: Scott's Screaming Security Method (Tom St Denis)
some questions about DES ("Buchinger Reinhold")
Re: Quantum Computers and Weather Forecasting ("Phil & Jean Bergerot")
Re: Questions about message digest functions (SCOTT19U.ZIP_GUY)
Re: Questions about message digest functions (lordcow77)
Re: New RNG Technique (Tim Tyler)
Date: Sat, 11 Dec 1999 10:58:43 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Steve Harris wrote:
> I have developed a technique that converts the output of any RNG into a
> cryptographically secure bit stream good enough to pass all statistical tests
> for randomness, including DIEHARD. Its not strictly a generator in itself, but
> a modifier which I call ECHO.
>
> It has the following important features:
>
> 1.) Modifies any RNG; my example uses the C rand() function.
> 2.) The output is not correlated to the seed.
> 3.) The seed length is unlimited. My example uses a 128-bit seed.
> 4.) The same seed does not produce the same sequence twice, unless ECHO is reset
> to its default state.
> 5.) There are many possible default states.
> 6.) After the initial run, ECHO starts in a random state.
> 7.) The output bits are not correlated to each other in any way. Its not that
> they dont appear to be correlated, but they are in fact uncorrelated.
> 8.) ECHO does not repeat, it has a period of infinity.
That's a tall one. How did you figure this out?
> 8.) It ouputs bytes at a time.
> 9.) Entropy collection is not absolutely necessary with ECHO. A seed entered
> manually is enough to make it secure.
> 11.) It uses less than 5K of memory.
> 12.) On my Pentium II 400Mhz it produces 21 Mbps.
>
> It has the following security features:
>
> 1.) Large seed length.
> 2.) No input attack is possible with a manually entered seed.
> 3.) The operator need not know what the seed is.
> 4.) ECHO can start in an unknown state (dependent on the security of a data file
> which is created when its shut down).
> 5.) An attacker must know the beginning state and seed of ECHO to determine the
> output. Otherwise he must attempt a brute-force attack, which is infeasible.
>
> BASIC GENERATOR
>
> Declare an array of 4096 elements. Fill each element with a byte, from 0 to 255.
> Do this 16 times. Then shuffle the array, using any RNG. For output, take the
> value from each element in order. When you get to the end, shuffle it again.
> Keep going as long as you like. Youll find that this produces a bit stream good
> enough to pass any test for randomness.
>
> Here is an example of the simplified code. This program produces a file of
> 32-bit numbers for testing with DIEHARD. Note that this example does not include
> advanced security; Ill get to that later. The numbers in brackets refer to the
> notes that follow.
>
> // Simplified ECHO RNG //
>
> #include
> #include
>
> #define SIZE 4096// [*** 1 ***] //
> #define SEED 13126 // [*** 2 ***] //
>
> unsigned char bytes[SIZE];
> unsigned int a, b, c;
> unsigned long e, f;
> unsigned int count = SIZE, octet = 0;
> unsigned long MAX, number = 0;
> FILE *fp1;
>
> void initialize(void);
> void numgen(void);
>
> void initialize(void)
> {
> // Initialize New Bytes Array //
> for (a = 0; a <= ((SIZE / 256) - 1); a++) {
> for (b = 0; b <= 255; b++) bytes[(a * 256) + b] = b;// [*** 3 ***] //
> }
> srand(SEED);
> }
>
> void numgen(void)
> {
> puts("\n Please Wait . . .");
> for (e = 1; e <= (MAX * 4); e++) {// [*** 4 ***] //
> if (count == SIZE) {
> // Shuffle the Bytes Array //
> for (a = SIZE; a >= 2; a--) {
> do b = ((a * rand()) / RAND_MAX) + 1; while (b == (SIZE + 1));
> c = bytes[(a - 1)];
> bytes[(a - 1)] = bytes[(b - 1)];
> bytes[(b - 1)] = c;
> count = 0;
> }
> }
> // Assemble and Store Number //
> f = bytes[count];
> f <<= (octet * 8);
> number += f;
> octet++;
> if (octet == 4) {
> fwrite(&number, sizeof(unsigned long), 1, fp1);
> number = 0;
> octet = 0;
> }
> count++;
> }
> }
>
> void main(void)
> {
> initialize();
> while(1) {
> puts("\n\n How many numbers do you want? (0 to exit)\n"); // [*** 5 ***] //
> scanf("%lu", &MAX);
> if (MAX == 0) break;
> if ((fp1 = fopen("\\echo.32", "wb")) == NULL) exit(0);
> numgen();
> fclose(fp1);
> }
> }
>
> Notes:
>
> 1.) The array can be larger, if desired. It must be a multiple of 256. This is
> the smallest size that gives consistently good results with DIEHARD.
> 2.) I chose this seed arbitrarily. Of course, it can be any unsigned integer.
> 2.) This is one of many possible fill patterns. One marvelous feature of ECHO is
> that
Cryptography-Digest Digest #724
Cryptography-Digest Digest #724, Volume #10 Sat, 11 Dec 99 16:13:01 EST
Contents:
Insecure PRNG? ("Gary")
Insecure PRNG? ("Gary")
Re: some questions about DES (Tom St Denis)
Re: Linear Congruential Generators (Mok-Kong Shen)
Re: some questions about DES (Troed)
Re: some questions about DES ([EMAIL PROTECTED])
Re: Linear Congruential Generators (David A Molnar)
New Algorithm (Jeroen van de Erve)
Re: Scott's Screaming Security Method (Loney Ramik)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: New RNG Technique (Loney Ramik)
Re: Attacks on a PKI (David A Molnar)
Re: New Algorithm (Mok-Kong Shen)
Brute Force Time (Maximum v Probable) (UBCHI2)
Re: New Algorithm (Loney Ramik)
Re: some questions about DES (Gunnar Andersson)
Re: If you're in Australia, the government has the ability to modify (Darren New)
Re: Linear Congruential Generators (Mok-Kong Shen)
Re: some questions about DES (Jerry Coffin)
Re: Questions about message digest functions (Tim Tyler)
From: "Gary" <[EMAIL PROTECTED]>
Subject: Insecure PRNG?
Date: Sat, 11 Dec 1999 17:27:00 -
Insecure PRNG?
Linear congruential Pseudo-Random Number Generators (PRNG) of the form
Xn+1=AXn+B are always stated to be insecure as the basis of a cipher
bit-stream.
If only the top bit is used on a PRNG of this form how do I find the
constants X0,A and B., without brute force?
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0;
X=(X*A)+B;
return (X>>31);
}
How do I determine constants X0,A,B collectively forming a key to the cipher
stream?
(The 3 constants are randomly generated but B is odd and A=1(mod 4))
More over, if two PRNGs of this form were used where the top 5 bits of the
first's output are used to select the single cipher-stream bit in the
second's output, how do I go about solving this?
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0,Y=Y0;
X=(X*A)+B;
Y=(X*C)+D;
return ((X>>((Y>>27)&31))&1);
}
How do I determine constants X0,Y0,A,B,C,D collectively forming a key to the
cipher stream?
(The 6 constants are randomly generated but B,D odd and A,C=1(mod 4))
G.
--
From: "Gary" <[EMAIL PROTECTED]>
Subject: Insecure PRNG?
Date: Sat, 11 Dec 1999 17:29:09 -
Insecure PRNG?
Linear congruential Pseudo-Random Number Generators (PRNG) of the form
Xn+1=AXn+B are always stated to be insecure as the basis of a cipher
bit-stream.
If only the top bit is used on a PRNG of this form how do I find the
constants X0,A and B., without brute force?
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0;
X=(X*A)+B;
return (X>>31);
}
How do I determine constants X0,A,B collectively forming a key to the cipher
stream?
(The 3 constants are randomly generated but B is odd and A=1(mod 4))
More over, if two PRNGs of this form were used where the top 5 bits of the
first's output are used to select the single cipher-stream bit in the
second's output, how do I go about solving this?
IE Given a large cipher bit-stream produced by the following C function
long NextBit(void)
{
static long X=X0,Y=Y0;
X=(X*A)+B;
Y=(Y*C)+D;
return ((X>>((Y>>27)&31))&1);
}
How do I determine constants X0,Y0,A,B,C,D collectively forming a key to the
cipher stream?
(The 6 constants are randomly generated but B,D odd and A,C=1(mod 4))
G.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: some questions about DES
Date: Sat, 11 Dec 1999 18:11:05 GMT
In article <82tt20$q4u$[EMAIL PROTECTED]>,
"Buchinger Reinhold" <[EMAIL PROTECTED]> wrote:
> Hi !
>
> I write a paper about DES for my school - leaving exam and I need some
> further informations.
>
> Where was and is DES used ?
> Has DES been verified in 1998 ?
> If not what's its succession ?
> How fast and with which computer (price) can DES been broken
nowadays ?
>
> If you have some references (websites, ...) for your knowledge please
let me
> know !
> I am VERY grateful for you help !
DES in it's original form is no longer used. It was originally used
primarly in hardware, but has been adapted for password hashing in
unix. 3DES is still in use today, primarly in software but some
hardware for it is out there.
It can be cracked with 12 spare computers over the inet in about 20
hours. [well DES anyways].
It was originally broken with differential cryptanaylsis using 2^51
pairs. Then linear analysis in 2^47 [or something like that, I have a
paper by Biham on the Differential Cryptanalysis if you want].
That's all I know off hand.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sat, 11 Dec 1999 19:40:31 +0100
Gary schrieb:
>
> Ins
Cryptography-Digest Digest #725
Cryptography-Digest Digest #725, Volume #10 Sun, 12 Dec 99 03:13:02 EST
Contents:
Re: Brute Force Time (Maximum v Probable) (Scott Nelson)
Re: Synchronised random number generation for one-time pads ("Charles Meigh")
Re: Brute Force Time (Maximum v Probable) (Bill Unruh)
Re: New RNG Technique (Guy Macon)
Re: New RNG Technique (Guy Macon)
Re: Insecure PRNG? ("Gary")
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: low exponent in Diffie-hellman? (jerome)
Re: New Algorithm (Tim Tyler)
Re: Linear Congruential Generators ("Steven Alexander")
Re: New RNG Technique ("Steven Alexander")
Re: New Algorithm ("Steven Alexander")
Re: some questions about DES (jerome)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (zapzing)
Encryption of I-Mail? Someone Invent this Please! (UBCHI2)
Re: Encryption of I-Mail? Someone Invent this Please! (Nike Y. Molar)
Re: Encryption of I-Mail? Someone Invent this Please! (UBCHI2)
Re: Encryption of I-Mail? Someone Invent this Please! (Johnny Bravo)
Re: Attacks on a PKI (lcs Mixmaster Remailer)
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Brute Force Time (Maximum v Probable)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 21:24:22 GMT
On 11 Dec 1999 19:35:59 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>1) You have a 50% chance of finding the key after only running only half the
>possible keys. Basically, there is a 1 in 2 chance of the attack taking only
>half the time allocated given the total possible number of keys.
>
>2) You only have to search for keys equal to the keylength of the target. For
>example, you only have to search for a key equal to 128, 256, 512, 1024. I
>estimate that less than 1 in 100 people use a key of an "off" size. You don't
>have to search for all keys smaller than 128. This cuts the number of keys
>down by perhaps 50%.
>
>In other words, .5*.5 is only 25%. This corresponds to the time needed to
>attack a key with brute force versus the time allocated given the total number
>of possible keys.
>
>The industry should shift from quoting maximum time to crack a key to quoting
>probable time to crack a key.
>
Producers who list the time taken to break a cipher in a
particular way, have an interest in having it be as large
as possible. In other words, they want you to view their
products in the best possible light. Consumers on the other
hand, have an interest in having uniform numbers to make
comparison "shopping" easier.
Given these two goals, it's seems better to choose
the most generous numbers possible - if you don't
then an unscrupulous producer can dupe some consumers
with inferior products. Not that they won't anyway,
but there's no reason to make it easy for them.
Scott Nelson <[EMAIL PROTECTED]>
--
From: "Charles Meigh" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Fri, 10 Dec 1999 20:57:04 -
Guy Macon <> wrote in message ...
>> (Charles Meigh) wrote:
> >
> >I'm still thinking that there might be some
> >vastly wide choice of 'celestial' events that could produce truly random
> >numbers that will still be sufficiently similar observed from any two (or
> >more) points on the globe, which would make OTP use more economical.
>
> You have that already. Just generate your random numbers using whatever
> method you prefer and post them in a newsgroup. Or you can put them on
> a CD and sell the CD on a web site. Or broadcast them with a ham radio.
> Getting your random numbers to two or more points on the globe is trivial.
> What is hard is getting your random numbers to exactly two (and no more
> than two) points on the globe and not to any other points on the globe.
> Alas, the latter is what you need if you want to have the shared secret
> that is the basis of OTP encryption.
>
>
But would those methods realistically allow you to distribute a sufficiently
large set of random data that from which enough potential OTP keys can be
generated without allowing brute force attacks. Interception of the pool
of random data is not a concern if it is large enough.
--
Charles Meigh
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Brute Force Time (Maximum v Probable)
Date: 11 Dec 1999 22:13:08 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (UBCHI2)
writes:
...
>The industry should shift from quoting maximum time to crack a key to quoting
>probable time to crack a key.
The estimates are so crude that the difference between the two is
irrelevant.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New RNG Technique
Date: 11 Dec 1999 17:13:52 EST
In article <[EMAIL PROTECTED
Cryptography-Digest Digest #726
Cryptography-Digest Digest #726, Volume #10 Sun, 12 Dec 99 12:13:01 EST
Contents:
Re: Encryption of I-Mail? Someone Invent this Please! (Troed)
Re: Attacks on a PKI (David A Molnar)
Re: Linear Congruential Generators ("Gary")
Re: Linear Congruential Generators ("Gary")
Re: Insecure PRNG? (Mok-Kong Shen)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Scott's Screaming Security Method (Nogami)
Re: Encryption of I-Mail? Someone Invent this Please! ([EMAIL PROTECTED])
Re: Encryption of I-Mail? Someone Invent this Please! (Troed)
Re: Attacks on a PKI ("Douglas A. Gwyn")
Re: Insecure PRNG? ("Douglas A. Gwyn")
Re: Linear Congruential Generators (Herman Rubin)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Attacks on a PKI (Anne & Lynn Wheeler)
Re: Attacks on a PKI ("Trevor Jackson, III")
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 09:32:39 GMT
[EMAIL PROTECTED] (UBCHI2) wrote:
>To clarify, I am referring to Instant Messenger on AOL when I write I-Mail, not
>to e-mail.
Have you americans still not learned that the rest of the world is
using ICQ?
How ignorant.
Encrypted ICQ messages, with a public key stored on the ICQ server,
would be nice though. Or maybe it exists? (I'm not using the latest
version ... )
___/
_/
Nazister, rasister och andra dårar - ger bara sig själva kalla kårar
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: 12 Dec 1999 09:43:17 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
[snip explanation of PKI, pointing out that even personal key file
is in sense a PKI]
> authority can specialize in this task. The disadvantage is that you
> now must trust this other entity to securely and accurately manage his
> certifications. Of course, you entrust your very life every day to the
> expectation that third parties have professionally applied their skills
> and energies, so there is nothing particularly revolutionary in extending
> such trust to a key infrastructure.
Eventually I will agree with you. :-\
What seems "revolutionary" to me _now_ is that the key infrastructure
does not seem to be as well understood, as accountable, or as well
regulated as many of the other third parties I depend on. It's not
completely clear what I should expect from a PKI, while in many real
life cases the expectations are so amazingly clear that stating them
seems pedantic.
For example, I trust that the food I eat is free of disease; in doing so
I'm implicitly trusting half a dozen third parties. The farmer must
have grown the crop correctly, without allowing it to become rotten. The
food processor must avoid introducing toxic chemicals. The distributor
must prevent spoilage. Since I'm in the United States, somewhere along
the line the State gets involved, too. Eventually the food comes to
market, where I trust it wasn't injected with poison. From there it
comes to me, and I have to trust the ppl who cooked it...
None of these is the real expectation. The real expectation is that
"this food won't make me sick." The rest is professionalism.
The difference seems to me that with a PKI, I take a look at a key
and it's not clear immediately what kind of keys "won't make me sick."
Do I expect this key to map to a name? what kind of name?
Do I expect this key to meet a certain standard of "quality" ?
Do I expect this key to be still in use?
Do I expect that all my correspondents expect what I expect?
Do I expect all my correspondents to be part of the PKI ?
Do I expect signatures with this key to be legally binding?
checked by anyone?
I trust the Verisigns, Thawtes, CertCos and like to do the
best honest job they can. There's ample precedent for that.
I just do not think that we can compare extending trust to a PKI
to extending trust to another third party, unless we have a
comparable expectation of what we'll "get" for that trust. This
doesn't affect your point once we know that a PKI "is", but
it's not clear to me that we're at that point yet.
Until we are, it seems fine to be skeptical of extending too much
trust to a PKI. We might not even know enough to know when
something has gone wrong...until someone _else_ notices and it's too
late.
Thanks,
-David Molnar
--
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sun, 12 Dec 1999 10:26:50 -
David A Molnar wrote
>
>I don't know off the top of my head, but it seems to me that you
>might be able to get an equation relating the output to the top 5 bits
>of your first generator. Maybe this can be leveraged?
Since the top 5 bits are never explicitly output, recovery of these is
incredibly hard.
Cryptography-Digest Digest #727
Cryptography-Digest Digest #727, Volume #10 Sun, 12 Dec 99 17:13:01 EST
Contents:
Re: New RNG Technique (Scott Nelson)
Re: Attacks on a PKI (Larry Kilgallen)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
The Cracking of SecurityPlus! 4.32 (JPeschel)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: The Cracking of SecurityPlus! 4.32 (Troed)
Re: How do you get past the password screen to the crypto? (Joseph Durusau)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (wtshaw)
Re: Linear Congruential Generators (wtshaw)
Re: Attacks on a PKI ("Lyal Collins")
Are thermal diodes as RNG's secure ([EMAIL PROTECTED])
Re: Brute Force Time (Maximum v Probable) ([EMAIL PROTECTED])
Re: Questions about message digest functions (wtshaw)
Re: Scott's Screaming Security Method (wtshaw)
Re: Linear Congruential Generators (Mok-Kong Shen)
Re: Insecure PRNG? (CLSV)
Re: Insecure PRNG? (Guy Macon)
Please help this newbie crack a potentially simple encryption (John)
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: New RNG Technique
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 17:53:53 GMT
On 10 Dec 1999 [EMAIL PROTECTED] (Steve Harris) wrote:
[suspiciously troll-like stuff sniped]
>3.) For DIEHARD, you collect four bytes, then store them as a 32-bit number. For
>other implementations, harvest as many bytes (or bits) as desired.
>5.) You probably know that you need at least 2,867,200 numbers for DIEHARD.
>
Considering the rest of the post, this is but a minor quibble,
but... you usually need less than 211 numbers.
The squeeze test can in theory require more, but it's
exceptionally unlikely. The documentation for DiehardC
includes a list of the exact numbers of bytes used by
each of the tests. If you use Diehard at all,
it's probably worth downloading DiehardC just to read
the documentation.
ftp://ftp.helsbreth.org/pub/helsbret/random/
Scott Nelson <[EMAIL PROTECTED]>
--
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Attacks on a PKI
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 18:13:32 GMT
In article <82vqnl$q1d$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes:
> What seems "revolutionary" to me _now_ is that the key infrastructure
> does not seem to be as well understood, as accountable, or as well
> regulated as many of the other third parties I depend on. It's not
> completely clear what I should expect from a PKI, while in many real
> life cases the expectations are so amazingly clear that stating them
> seems pedantic.
But real life cases are not so clear. If you buy a house in the
United States you typically need a title search. In Massachusetts
you need a lead paint certification, etc.
The main difference with a vendor of PKI services is that the
governing law is mainly limited to contract law, so you have
to read the contract with your chosen vendor before signing it.
You should not expect anything not stated in the contract, and
your contract should not impose ridiculous constraints. For
example, if you agree to run your CA with a BBN Safekeeper
using at least 3 out of 5 physical keys you should expect
the same degree of security from your PKI vendor.
Larry Kilgallen
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Sun, 12 Dec 1999 18:29:57 GMT
[EMAIL PROTECTED] (Guy Macon) wrote:
> [...] [EMAIL PROTECTED] (Tim Tyler) wrote:
> >Guy Macon <[EMAIL PROTECTED]> wrote:
> >: [EMAIL PROTECTED] (Tim Tyler) wrote:
> >:>OTPs are [...] useless against simple complete known-plaintext
> >:>attacks.
> >
> >: It depends on what you mean by "useless". I would say that
> >: being able to send other plaintexts without the attacker being
> >: able to decode them is quite usefull, wouldn't you?
> >
> >If (as I specified) the attacker has a "complete known plaintext",
> >he has no need to decode and read the encrypted message - since he
> >knows its entire contents completely anyway.
>
> Except for the (huge!) hole of allowing the attacker to substitute
> his own plaintext if and only if he can stop the senders messsage,
> a known plaintext attack that only reveals the known plaintext and
> no other would seem to be, to coin a phrase, useless. [...]
The attacker gets the key. This means that - if he can get a number of
consecutive messages - he can *directly* examine the random numbers that
compose the OTP for deviations from randomness.
Since such deviations from randomness are not practical to completely
eliminate - and these have existed in a number of hitorical sources of
numbers for actual OTPs - this might even be worth doing.
Sometimes, if the eavsdropper has knowl
Cryptography-Digest Digest #728
Cryptography-Digest Digest #728, Volume #10 Sun, 12 Dec 99 21:13:01 EST
Contents:
Re: Scott's Screaming Security Method (Okra Meinly)
Re: Are thermal diodes as RNG's secure (Tom St Denis)
Re: Questions about message digest functions (Lasse Reichstein Nielsen)
Re: Digitally signing an article in a paper journal (Steve K)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Insecure PRNG? ("Trevor Jackson, III")
Re: Are thermal diodes as RNG's secure ("Trevor Jackson, III")
Lots of cryptography book recommendations (David Youd)
Re: Insecure PRNG? (CLSV)
Re: Insecure PRNG? ("Douglas A. Gwyn")
Re: Insecure PRNG? ("Douglas A. Gwyn")
Re: Are thermal diodes as RNG's secure ("Douglas A. Gwyn")
Re: Please help this newbie crack a potentially simple encryption ("Douglas A. Gwyn")
Re: Lots of cryptography book recommendations ("abe kohen")
Re: Are thermal diodes as RNG's secure (Tim Tyler)
Re: Are thermal diodes as RNG's secure (Bill Unruh)
Re: Questions about message digest functions (Tim Tyler)
From: [EMAIL PROTECTED] (Okra Meinly)
Crossposted-To: comp.compression,alt.security
Subject: Re: Scott's Screaming Security Method
Date: Sun, 12 Dec 1999 22:10:40 GMT
[EMAIL PROTECTED] (wtshaw) wrote:
>Probably helps if you have lots of hair too, but since Scott is a bit shy
>on that department, I figure that he is not the intended one to do the
>screaming. It's a catchy name, however.
The name reminds me of a failed snack food called "Screaming Yellow
Zonkers". Remember those?
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Date: Sun, 12 Dec 1999 22:40:30 GMT
In article <831142$s6l$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Is a termal diode being used as a RNG secure?
>
> Is it possible to manipulate the electronics to make the output of the
> diode not-so-random?
Change the voltage? As I understand it diodes work by letting current
go thru only when it passes a voltage, but when it equals the voltage
it let's it pass at 'random'.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Lasse Reichstein Nielsen <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Date: 12 Dec 1999 23:51:11 +0100
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> >
> >It appears to be a desirable property.
> >
> >Part of the point of hashes is to avoid hash collisions. A permutation
> >would avoid collisions to the maximum possible extent.
> >Nothing else would do this for the case where message size = hash size.
>
>For the ignorant if you hash a message of the same size and
> it is not bijective then certains patterns of the hash will be impossibe
> to achieve so if the hash used for a key certain keys can be eliminated
> from the solution space. Also patterns that can be hashed to by more
> than one input could be checked first.
Sure, but if this happens rarely enough, who cares? If there are
5 collisions in a hash function out of like 2^128 then you gain
nothing you couldn't gain from precomputing the hash of 5 messages.
Same goes for any negligable subset of the set of messages.
A desireable property of a hash-function is that it is "collision
intractable", i.e. that your chance of finding a collision (given a
random hash-value find something that hashes to the same value) is not
much better than chance. You can set the threshold yourself depending
on your needs, and it corresponds nicely to the chance of bruteforcing
a crypto-algorithm.
IF there exist collision intractable hashfunctions (afaik. still not
decided) then a lot of cryptologers will be happy, because they have
been proven usable to make crytographyas about as strong as the CIH
itself (i.e. breaking the crytography means finding a collision).
This doesn't require the hashfunction to be a permutation on messages
of the appropriate size.
/L
--
Lasse Reichstein Nielsen - [EMAIL PROTECTED]
"Faith without judgement merely degrades the spirit divine."
--
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Digitally signing an article in a paper journal
Date: Sun, 12 Dec 1999 22:52:32 GMT
My suggestion:
Create a key for the sole purpose of signing and encrypting a drafts
of articles, messages, etc. under your pseudonym. Take great care,
never to use this key pair for any other purpose, of your anonymity
may be endangered.
http://www.itconsult.co.uk/stamper/stampinf.htm
This is the URL to a PGP time stamping service. There are others.
Encrypt and sign a draft of your document, and send it to a time
stamping service. You will recieve it back, with another signature
added, specifically for the purpose of verifying where and when the
service signed your document. Here you have nearly perfect proof of
priority, in your posession, which can be disclo
Cryptography-Digest Digest #729
Cryptography-Digest Digest #729, Volume #10 Mon, 13 Dec 99 02:13:01 EST
Contents:
Re: Questions about message digest functions (Tim Tyler)
An attack on the WTLS SHA_XOR_40 MAC algorithm (David Hopwood)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Tim Tyler)
Better encryption? PGP or Blowfish? (molypoly)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: Are thermal diodes as RNG's secure (Tom St Denis)
Re: Better encryption? PGP or Blowfish? (Y. Karmenoil)
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: old Microsoft Mail 3.0b encryption? (Keith A Monahan)
Re: Please help this newbie crack a potentially simple encryption ("r.e.s.")
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: Digitally signing an article in a paper journal (Lincoln Yeoh)
Re: Are thermal diodes as RNG's secure (Lincoln Yeoh)
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: Scott's Screaming Security Method (wtshaw)
Re: Questions about message digest functions (wtshaw)
The future of telecommunication? ("Melinda Harris")
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 02:03:10 GMT
Lasse Reichstein Nielsen <[EMAIL PROTECTED]> wrote:
: IF there exist collision intractable hashfunctions (afaik. still not
: decided) [...]
Surely this may be answered in the affirmative, in that such functions
definitely *exist*. Whether any human can ever find one is much more
questionable, of course.
The construction is much the same as the demonstration that a "perfect"
block cypher exists. Fill an infinitely big book with random numbers the
length of the hash, one for each message. As the hash size increases,
the chance of a hash collision becomes miniscule, and the chances of
finding one dwindle. Since the hashes are allocated on a completely
random basis, no attack is better than brute force.
The hash may be effectively made one-way if required by listing the hashes
in size order (and then in alphabetical order), of the messages.
Such a collision-intractable hash function exists only in mathematical
never-never land, of course - but I /presume/ this was the sense in
which you asked about existence.
Can such a hash be found in the form of a finite function? Not IMO.
: This doesn't require the hashfunction to be a permutation on messages
: of the appropriate size.
In this sort of context, "intractability" is sometimes taken as a
statement about how the work factor scales with the size of the hash.
You don't need a hash that is a bijection when the message size is equal
to the size of the hash in order to get security - if you have a big
enough hash.
The bijection property minimises the chance of hash collisions (when
choosing messages at random). Whatever size hash you use, a bijection
will make collisions as unlikely as possible. This seems a desirable
property - especially when there are other reasons for not wanting to
transmit a monster-sized hash.
Part of the point of a hash is to make it hard to find two messages that
hash to the same value. A bijection makes it not just hard, but
/impossible/ (for messages of the right length).
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It is easier to get forgiveness than permission.
--
Date: Mon, 13 Dec 1999 01:25:45 +
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: An attack on the WTLS SHA_XOR_40 MAC algorithm
=BEGIN PGP SIGNED MESSAGE=
WTLS, "Wireless Transport Layer Security", is the security layer of the
WAP protocol suite (www.wapforum.org). It is loosely based on TLS, with
modifications to allow running on datagram transports, removing
dependencies on ASN.1, support for elliptic curve key exchange, and
various other tweaks.
The latest proposed spec (for version 1.2) is in PROP-WTLS-19991105.pdf
in the technical docs section of the WAP forum site. For the MAC
algorithms (which have not changed from the previous version, 1.1),
it lists
- a null algorithm that provides no authentication (not a good idea
IMHO, but at least it's documented as such),
- four algorithms based on HMAC-MD5 and HMAC-SHA1 truncated to 40
and 80 bits,
- and the following algorithm, which I've just broken:
# SHA_XOR_40 (4)
#
# A 5-byte XOR checksum. The input data is first divided into the
# multiple blocks of 5 bytes. Then all blocks are XOR'ed one after
# another. If the last block is less than 5 bytes, it is padded with
# 0x00. SHA is much stronger than XOR for generating MAC's,
# although there were no significant attacks reported on XOR MAC's,
[Note that this is *not* the XOR MAC described in "XOR MACs: Ne
Cryptography-Digest Digest #730
Cryptography-Digest Digest #730, Volume #10 Mon, 13 Dec 99 07:13:01 EST Contents: Re: Are thermal diodes as RNG's secure (Bill Unruh) Re: Insecure PRNG? (Mok-Kong Shen) Re: Insecure PRNG? (Mok-Kong Shen) Re: Insecure PRNG? (CLSV) SecurityPlus! (JPeschel) Simple newbie crypto algorithmn (Steven Siew) Re: Are thermal diodes as RNG's secure (Guy Macon) Re: Insecure PRNG? (Guy Macon) From: [EMAIL PROTECTED] (Bill Unruh) Subject: Re: Are thermal diodes as RNG's secure Date: 13 Dec 1999 07:26:04 GMT In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Lincoln Yeoh) writes: ]On 13 Dec 1999 01:34:18 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote: ]>In <831142$s6l$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: ]> ]>>Is a termal diode being used as a RNG secure? ]> ]>If it is used properly. The big problem with hardware random number ]>generators is bias. You must cook theoutput to get rid of any effects of ]>the biases. ]How can we cook such output? Eg, if you suspect that the output is not really random, but is "partially" random, so that say a fraction f of the information really is random,then you could feed say 128/f bits into a hash function like MD5 and use the 128 bits of output. That output should be "fully" random. There are whole theories as to how to distill the biases out of partially random data. -- From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: Insecure PRNG? Date: Mon, 13 Dec 1999 10:40:50 +0100 Douglas A. Gwyn wrote: > > Mok-Kong Shen wrote: > > Does encrypting 2 charaters out of 100 > > results in twice the strength of encrypting 1 character out of 100? > > Just because Guy Macon doesn't have a good measure of cryptographic > strength doesn't mean anything one way or another for the general > issue of whether such a measure is possible. It is obvious, however, > that your question would not fit into the framework of any valid > measure. I have expressed my opinion that a rigorous measure is not possible and offered arguments. The lines you quoted is only a side remark intended merely to say that the issue is not so simple as Mr. Macon apparently has thought. M. K. Shen -- From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: Insecure PRNG? Date: Mon, 13 Dec 1999 10:40:55 +0100 Douglas A. Gwyn schrieb: > > Mok-Kong Shen wrote: > > But what interests the user of encryption algorithms is the security > > against all currently possible attacks. Since that 'context' is > > difficult to deal with or ill-defined (since one is never sure to > > know all these attacks) that's one reason why defining a standard > > unit of strength of crypto algorithms is impossible in practice, > > I believe. > > You're going about this the wrong way. You might as well say > that, since it is impossible to know all the exact situations > *any* real-world object will be subjected to, it is therefore > impossible to say anything definite about the relative quality > of different objects of the same kind. Yet in reality, we make > such judgments all the time. > > What you're really lacking is a good theoretical basis for > doing this for cryptosystems (or just for encryption algorithms); > that doesn't mean that no good theory is possible, just that > you're not (yet) aware of one. Yes, in most situations of life one accepts, consciously or unconsciously, compromises and doesn't demand 'exact solutions' even in case these could be obtained (with sufficient expenditure). For crypto applications the only thing special, in my view, is that there may exist analysis methods that are kept secret from the public and hence not available for evaluation independent of expenditure. Thus I said previously that an examination of security needs in the end one's own judgement and inevitably involves certain amout of subjectivity. In other words, a rigorous, precise practical treatment of the matter, which some crypto users seem nevertheless to desire for fairly comprehensible psychological reasons, is not (or to be correct, not yet) available. M. K. Shen -- From: CLSV <[EMAIL PROTECTED]> Subject: Re: Insecure PRNG? Date: Mon, 13 Dec 1999 10:22:39 + Mok-Kong Shen wrote: > Douglas A. Gwyn schrieb: > > What you're really lacking is a good theoretical basis for > > doing this for cryptosystems (or just for encryption algorithms); > > that doesn't mean that no good theory is possible, just that > > you're not (yet) aware of one. Hmm, I find it hard to believe that the security of block ciphers could ever be determined precisely. Provable security could possible be found in public key system. > Yes, in most situations of life one accepts, consciously or > unconsciously, compromises and doesn't demand 'exact solutions' even > in case these could be obtained (with sufficient expenditure). > For crypto applications the only thing sp
Cryptography-Digest Digest #731
Cryptography-Digest Digest #731, Volume #10 Mon, 13 Dec 99 12:13:01 EST
Contents:
Re: Insecure PRNG? (Guy Macon)
Re: Simple newbie crypto algorithmn (Eric Hambuch)
Re: Simple newbie crypto algorithmn ("Tim Wood")
Re: Simple newbie crypto algorithmn (CLSV)
Re: Simple newbie crypto algorithmn ([EMAIL PROTECTED])
Re: Simple newbie crypto algorithmn (CLSV)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Questions about message digest functions (James Felling)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Why no 3des for AES candidacy (UBCHI2)
lfsr based cryptosystem ([EMAIL PROTECTED])
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: The future of telecommunication? ("Tim Wood")
Re: Better encryption? PGP or Blowfish? (Neil Bell)
Re: some questions about DES (Anton Stiglic)
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Are thermal diodes as RNG's secure (Tim Tyler)
Re: some questions about DES (Paul Koning)
Re: Simple newbie crypto algorithmn (Glenn Larsson)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Insecure PRNG?
Date: 13 Dec 1999 06:56:32 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mok-Kong Shen)
wrote:
>
>CLSV wrote:
>> So what is stronger: a steel or a wooden beam?
>> Again, given no context there is no valid comparison.
>> *Proving* real-world characteristics is much harder than proving
>> theoretical concepts.
>
>Look into an engineering handbook and you will find the strength
>of different construction materials. Note however that a beam is a
>structure. Its breaking load depends on its cross-section etc. and
>is much more complicated than (but can be computed from) the 'pure'
>strength of the material it is made of. Given a steel and a wooden
>beam, an engineer can do computations to determine which is stronger
>and give a numerical figure for that. To do the same with two
>crypto algorithms seems to be very hard or impossible in general.
Actually, this is an excellent analogy. Steel has tensile strength
that is much better than stone but the compressive strength isn't
so superior. Wood has different strengths in different directions.
As an erngineer, I can not answer the question "what is stronger:
a steel or a wooden beam?". It depends on what kind of load and
on what kind of support the beam has. Just like crypto strength
depends on what kind of attack.
--
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 13:16:25 +0100
Steven Siew wrote:
> 2. The program must be cryptographically powerful enough not to be cracked
>even by using all the computers in the world in less than a 1000 years.
[...]
> It will create a 607 bytes key file which should be almost completely
> random.
That means: Your key size is 4856 bits. Many algorithms are good if they
are used with such a long key. But normally you want to encrypt "long
secrets" (e.g. files)
with "short secrets" (keys etc.), so you should use the shortest key as
possible (of course long enough to prevent brute-force).
> The program uses permutation or "card shuffling" type tricks to encrypt the
> original text (plaintext). It also makes use of XOR to further confuse the
> attacker.
I will have a detailed look at your algorithm this evening.
So long
Eric
--
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 12:21:41 -
>
>It you need to generate a random key but you dont have a source of pure
>random bytes then you can use the following trick.
>
>gzip -9 bigfile
>scramble bigfile.gz < bigfile.gz > key9
>scramble key9 < key9 > key8
>scramble key8 < key8 > key7
>scramble key7 < key7 > key6
>scramble key6 < key6 > key5
>scramble key5 < key5 > key4
>scramble key4 < key4 > key3
>scramble key3 < key3 > key2
>scramble key2 < key2 > key1
>tail -c 607 key1 > key
>rm key1 key2 key3 key4 key5 key6 key7 key8 key9
>gunzip bigfile.gz
>
>It will create a 607 bytes key file which should be almost completely
>random.
>
It's a minor point, but shouldn't that read
It will create a 607 bytes key file which should appear random, and should
be harder to recreate than brute-forcing the key.
There is no randomness at all in this generation method (unless I'm much
mistaken) only secrets.
tim
--
>From my one-bit brain with a parity error.
--
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 12:27:58 +
Steven Siew wrote:
> [...] It's not uncommon to hear things like "All codes that have been invented so
> far (with the exception of one time pads) have been broken by the NSA."
Where do you hear such t
Cryptography-Digest Digest #732
Cryptography-Digest Digest #732, Volume #10 Mon, 13 Dec 99 13:13:01 EST
Contents:
Re: Please help this newbie crack a potentially simple encryption (Jim Gillogly)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: NP-hard Problems (Anton Stiglic)
Re: Simple newbie crypto algorithmn (SCOTT19U.ZIP_GUY)
Re: Attacks on a PKI ("Tim Wood")
Re: some questions about DES (John Myre)
Re: Why no 3des for AES candidacy (Scott Fluhrer)
Re: NP-hard Problems ([EMAIL PROTECTED])
Re: Why no 3des for AES candidacy (John Myre)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: The future of telecommunication? (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: Attacks on a PKI (Helger Lipmaa)
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Mon, 13 Dec 1999 17:16:51 +
John wrote:
> "The solution is a single sentence taken at random from a renowned
> Englishlanguage encyclopedia. Punctuation is ignored"
It's also possible that this cipher might be solved exhaustively:
some "renowned English-language encyclopedias" are available in soft
copy -- Britannica is inexpensive, Grolier is free with some CDROM
drives, and so on. You could reverse-engineer the storage format on
each of them and scan for single sentences of 223 letters in your
first pass, and for each of these see whether the repeated letters
show up in the right places. That might be less programming than
the hidden Markov model Doug suggested.
--
Jim Gillogly
Mersday, 23 Foreyule S.R. 1999, 17:11
12.19.6.14.1, 3 Imix 9 Mac, Second Lord of Night
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 12:21:23 -0500
Tim Wood wrote:
> >You can see why 3-DES, with it's single sized 168 bit key, does not fit in
> this
> >categorie.
>
> of course it's effective key length (strength) is 112bit not 168bit...
I agree, but it counts as a 168 bit key cipher since you need 168 bit of
randomness to create the key.
Anton
--
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Mon, 13 Dec 1999 12:24:06 -0500
[EMAIL PROTECTED] wrote:
> Do you have a reference for this? That was the
A professor (in complexity theory) told me it might be
found in Garey-Johnson's book, pp 110-111. I have
not had the chance to look at it yet...
Anton
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 18:20:17 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Steven Siew) wrote:
>It's sad to know that nowadays a lot of people held the NSA in such high
>regards as to wrongly believe that they have god like powers in cryptography
>and cryptoanalysis.
>
>It's not uncommon to hear things like "All codes that have been invented so
>far (with the exception of one time pads) have been broken by the NSA." or
>even "Today it is impossible for a newbie with basic C programming experience
>to write a crypto program that cannot be cracked by the NSA."
Yes this is the kind of Bull Shit the Crypto Gods would have the public
belive.
>
>Because a lot of people does not have cryptography experience, they have
>regarded cryptography as a black art. They believe that only crypto wizards
>are capable of coming up with wierd crypto algorithmns which no basic mortals
>are capable of understanding without devoting years to the studying of the
>black arts.
>
>That of course is total bullshit. Anyone with basic C programming skills and
>basic high school maths can write a crypto algo that the whole world cannot
>crack in less than 1000 years.
I think one can only say one can make it stronger and more secure than what
the phony crypto gods do with there short keyed methods. But to say its secure
for 1000 years is meaining less since who the hell knows where quantum
computers will be able to do in ten years.
>
>So I set about proving the above statement. In short I want to write a
>crypto program with the following chracteristics:
>
>1. The program must be simple and easy to understand. Thus the public can
> see easily the strengths of the encryption.
You will be surprised it how stupid the public is. They can't
understand high school math.
>
>2. The program must be cryptographically powerful enough not to be cracked
> even by using all the computers in the world in less than a 1000 years.
>
>3. No special knowledge of arcane cryptography is required. No maths more
> difficult than that encountered in high school is required.
>
>I have provided the source code below. I will explain what is needed to
>compile and use the program.
>
>There are two programs. The encryption program is called scramble and the
>decrypt
Cryptography-Digest Digest #733
Cryptography-Digest Digest #733, Volume #10 Mon, 13 Dec 99 17:13:01 EST
Contents:
Re: Are thermal diodes as RNG's secure (Scott Nelson)
Re: Linear Congruential Generators ("Gary")
Re: Linear Congruential Generators ("Gary")
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Insecure PRNG? (CLSV)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: How can you tell? (Tim Tyler)
Economic Espionage Act of 1996 and the U.S.A. government's violations ("Markku J.
Saarelainen")
Re: Linear Congruential Generators (Mok-Kong Shen)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: Insecure PRNG? (CLSV)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Data Encryption in Applet? ("Law Wun Suen, Brian")
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Attacks on a PKI (Darren New)
Re: Data Encryption in Applet? (Chris Wolfe)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Simple newbie crypto algorithmn (Eric Hambuch)
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 18:26:12 GMT
On Mon, 13 Dec 1999 16:58:56 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Bill Unruh <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Lincoln Yeoh) writes:
>
>[removing biases from hardware sources of randomness]
>
>: ]How can we cook such output?
>
>: Eg, if you suspect that the output is not really random, but is
>: "partially" random, so that say a fraction f of the information really
>: is random,then you could feed say 128/f bits into a hash function like
>: MD5 and use the 128 bits of output. That output should be "fully"
>: random.
>
>Yes, although you seem to be using "should" in the same sense as in the
>sentence:
>
>"The output from a pseudo-random number generator should be fully random."
>
>If any practical hash were as good at distilling entropy as this,
>it would be a miracle.
If the hash produced a random (rather than evenly distributed)
128 bits based on the input 128/f bits, then the number of states
would only be 1/e*2^128. That sounds bad, but it's less than
2 bits off of perfect, or under 2% error. Secure hash
functions aren't perfect, but they are very good.
I think a much bigger problem is the estimation of f.
Historically, entropy estimates have been off by as much as
two orders of magnitude. Being wrong by a factor of 2
is not uncommon.
Scott Nelson <[EMAIL PROTECTED]>
--
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 18:25:07 -
Tony T. Warnock wrote in message <[EMAIL PROTECTED]>...
>A long cycle (128 bit) LCG with only the leading bit exposed is
>difficult to decode but it should be possible with a lattice reduction
>computation.
>
How much of it's output is required for a lattice attack?
--
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 18:30:22 -
The non linear mix was suggested so that instead of solving AXn+B+CYn+D, one
would need to solve the non linear problem (AXn+B)^(CYn+D).
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 19:39:03 +0100
Guy Macon wrote:
>
> Actually, this is an excellent analogy. Steel has tensile strength
> that is much better than stone but the compressive strength isn't
> so superior. Wood has different strengths in different directions.
>
> As an erngineer, I can not answer the question "what is stronger:
> a steel or a wooden beam?". It depends on what kind of load and
> on what kind of support the beam has. Just like crypto strength
> depends on what kind of attack.
The point is that, given all the details, an engineer can normally
do computations to obtain fairly well an estimate of the load
carrying capacity/behaviour of a structure, becuase all the theories
are public, while in crypto some knowledge are purposedly kept
from public access. That's why one can't have the same kind of
'sureness' in evaluating crypto algorithms as the engineer does, I
believe.
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 19:38:53 +0100
CLSV wrote:
> It does not matter, technically, if there are analysis methods
> that are kept secret from the public or that they just haven't been
> invented yet. There is nothing special about it.
The first case is clearly critical, because it means that the
security you have evaluated is deceptive.
> I think, correct me if I'm wrong, that you have trouble with the
> fact that most people concern themselves with finding new
> upperbounds for the effort to break a cipher rather than attacking
> the interesting problem of fi
Cryptography-Digest Digest #734
Cryptography-Digest Digest #734, Volume #10 Mon, 13 Dec 99 20:13:01 EST
Contents:
Re: Are thermal diodes as RNG's secure ("Kasper Pedersen")
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations (
-=>JB<=-)
Re: Attacks on a PKI (Anne & Lynn Wheeler)
Re: New RNG Technique (Eric Lee Green)
Re: Insecure PRNG? (CLSV)
Re: Why no 3des for AES candidacy (Jerry Coffin)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
NAI granted export license for PGP (Bubba)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: How can you tell? (Pelle Evensen)
Re: The future of telecommunication? ("Douglas A. Gwyn")
Re: Why no 3des for AES candidacy (Pelle Evensen)
Re: Simple newbie crypto algorithmn ("Douglas A. Gwyn")
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations ("Markku
J. Saarelainen")
Re: lfsr based cryptosystem ("Douglas A. Gwyn")
Re: Please help this newbie crack a potentially simple encryption ("Douglas A. Gwyn")
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Date: Mon, 13 Dec 1999 22:51:59 +0100
<[EMAIL PROTECTED]> wrote in message
news:831142$s6l$[EMAIL PROTECTED]...
> Is a termal diode being used as a RNG secure?
>
> Is it possible to manipulate the electronics to make the output of the
> diode not-so-random?
The three things that can hurt you in this game are
1) Influence from outside sources.
High intensity HF radio waves will ALWAYS get into your circuit to some
degree. The point is to shield the device well enough that it won't hurt the
entropy too much.
Zeners make good AM receivers - they are easier to influence than resistors.
They might also work as X-ray receivers.
My goal when I built mine was to have an operating GSM phone lying on the
box, under the box etc, without making the predictability more than 0.55 (as
opposed to 0.5 ideal).
This is a small-signal device, and it should accept more disturbances than
your monitor.
2) influence by yourself
This is more likely than influence from outside sources - great care must be
taken to shield the device, and this includes shielding it from your PC's
power supply (or whatever..)
Zener diodes require biases, which makes power supply a problem.
3) listening outside attacker. Emission from the device itself is not the
problem (you already shielded the out of it), but it could be heard on
the cable from the device to the PC.
Enough. This isn't sci.electronics. Yes, they can be made good. No, it's not
easy.
/Kasper Pedersen
--
From: [EMAIL PROTECTED] (-=>JB<=-)
Crossposted-To: alt.politics.org.cia
Subject: Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
Date: Mon, 13 Dec 1999 15:16:29 -0800
In article <[EMAIL PROTECTED]>, "Markku J. Saarelainen"
<[EMAIL PROTECTED]> wrote:
> I do believe that the government of the U.S.A. with the assistance of
> its intelligence agencies and commercial agencies have violated my
> private property rights and taken away my intellectual property ("Genie
> Services")
Markku,
Did you ever transmit this "intellectual property" over a
modem? I notice you speak of modem technology & was wondering
if you used one to send the info to anyone. I think there
was another company who was robbed via modem of their secrets.
It seems for some reason it was even legal although corrupt.
-=>JB<=-
--
Subject: Re: Attacks on a PKI
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Mon, 13 Dec 1999 23:13:46 GMT
Helger Lipmaa <[EMAIL PROTECTED]> writes:
> Secure electronic commerce necessitates wide-scale employment of
> public-key cryptography that, in turn, requires secure and efficient
> methods of certificate management in the \emph{Public-Key
> Infrastructure} (PKI). Most of the known techniques for the latter
AADS looks at just upgrading existing online authentication schemes
from shared secret to public-key ... which inherits infrastructure
improvements from the transition from shared-secret to public-key.
certificates provide great introductory credentials for offline
comfort involving parties that have no previous knowledge of each
other and/or no prior business relations.
however, certificates have poor transactional characteristics in both
consumer<->business e-business and business<->business e-business
(simple offline analogy is oldtime purchase department checks with
printed "signing" limit authority ... of something like $5,000 until
they discovered $1m projects were being funded by signing 200 such
checks, i.e. aggregation involves online accounts).
also in the consumer to business e-business, consumer certificates
tend to violate al
Cryptography-Digest Digest #735
Cryptography-Digest Digest #735, Volume #10 Mon, 13 Dec 99 22:13:01 EST
Contents:
Re: Why no 3des for AES candidacy (Jim Gillogly)
Re: Better encryption? PGP or Blowfish? (Phillip George Geiger)
Deciphering without knowing the algorithm? (HKXLF)
Re: Why no 3des for AES candidacy ("karl malbrain")
Re: Better encryption? PGP or Blowfish? (Anime Rokly)
Re: Please help this newbie crack a potentially simple encryption ("r.e.s.")
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Re: Better encryption? PGP or Blowfish? ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Better encryption? PGP or Blowfish? (I. Realmonky)
Correction and apologies (Re: Digitally signing an article in a paper journal)
("rosi")
The Code Book (Warner)
Re: Insecure PRNG? (William Rowden)
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Deciphering without knowing the algorithm? (Arthur Dardia)
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 01:15:01 +
"Douglas A. Gwyn" wrote:
>
> "SCOTT19U.ZIP_GUY" wrote:
> > 1. Depending on how one combines the cipher to make 3DES it could be come
> > to hard for current NSA to quickly decode the message for law enforcement.
>
> I think you mean FBI. It is explicitly against the law for NSA to
> intercept communications for the purpose of domestic law enforcement,
> unless one or more of the communicants are foreign.
Is it also against the law for NSA to decrypt communications that
were intercepted and handed to them by the FBI working a domestic
case? (This may be a naive question, but it's not disingenuous --
I don't know the answer.)
--
Jim Gillogly
Highday, 24 Foreyule S.R. 1999, 01:12
12.19.6.14.2, 4 Ik 10 Mac, Third Lord of Night
--
From: Phillip George Geiger <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: 14 Dec 1999 01:13:18 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: I was just being honest. People never think twice before launching a
: flame war when I am wrong. I know two wrongs don't make a right, but
: what other response could i give?
You could have briefly explained why his question was a bad one, and
pointed him at a FAQ.
: His ignorant comparaison was just plain silly.
And in the time it took you to think up that "witty" response, giggle
like the child you are, and hit "enter" - you could have posted something
far more interesting and useful to a newbie.
--
Phil Geiger
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (HKXLF)
Subject: Deciphering without knowing the algorithm?
Date: 14 Dec 1999 01:35:47 GMT
Hi,
I am new to cryptography although I am very interested in the subject. From
browsing though this newgroup, I have come to a conclusion that, in order to
decipher some message, all you need is to find the key. But how about the
algorithm that is used the encrypt the text in the first place. Is it possible
to decrypt some text without first knowing what algorithm is used to encrypt
it?
Anyway, I'll be grateful if anybody can satisfy my curiosity.
Thanks,
Herry.
--
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 17:45:20 -0800
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "SCOTT19U.ZIP_GUY" wrote:
> > 1. Depending on how one combines the cipher to make 3DES it could be
come
> > to hard for current NSA to quickly decode the message for law
enforcement.
>
> I think you mean FBI. It is explicitly against the law for NSA to
> intercept communications for the purpose of domestic law enforcement,
> unless one or more of the communicants are foreign. And, before you
> say that NSA just ignores the law, that's not so -- this requirement
> has an effect on how operations are conducted, which wouldn't be
> necessary if the law were being ignored.
This is an example of VULGAR MATERIALISM. Yes, it's true, that ANY
measurable operations-effect means that the law is not being ignored, per
se. That's hardly the point, however. Karl M
--
From: [EMAIL PROTECTED] (Anime Rokly)
Subject: Re: Better encryption? PGP or Blowfish?
Date: Tue, 14 Dec 1999 01:48:10 GMT
Phillip George Geiger <[EMAIL PROTECTED]> wrote:
>And in the time it took you to think up that "witty" response, giggle
>like the child you are, and hit "enter" - you could have posted something
>far more interesting and useful to a newbie.
Or better, you could have flamed David Scott instead.
--
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Please help this newbie crack a potentially simple encryption
Date: Mon, 13 Dec 1999 17:54:48 -0800
T
Cryptography-Digest Digest #736
Cryptography-Digest Digest #736, Volume #10 Tue, 14 Dec 99 01:13:01 EST
Contents:
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (David Wagner)
Re: SRP - a secure alternative for authentication >> Nice reading ... (Thomas Wu)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Deciphering without knowing the algorithm? ("Surface Mount")
Re: Deciphering without knowing the algorithm? (Jim Gillogly)
How do you crack a Rotating Grille? (UBCHI2)
Re: Are thermal diodes as RNG's secure ("John E. Kuslich")
Re: The Code Book (Septyn)
Re: Simple newbie crypto algorithmn (SCOTT19U.ZIP_GUY)
Re: Economic Espionage Act of 1996 and the U.S.A. government's violations
(SCOTT19U.ZIP_GUY)
Re: How do you crack a Rotating Grille? (Jim Gillogly)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Security analysis of digitalPersona's U.are.u? ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
Date: 13 Dec 1999 19:16:17 -0800
Good catch. Yeah, I agree: the so-called WTLS `XOR MAC' is seriously
flawed, and definitely should be eliminated with all possible haste.
Submitting your result to WAP might be useful, to keep them honest.
Last I heard, they were a semi-secret design committee, and one always
has to wonder about the effects of secrecy & politics on the resulting
standards.
You might also be interested in the following paper:
Markku-Juhani Saarinen, ``Attacks against the WAP WTLS protocol.''
1999 Communications and Multimedia Security conference.
This paper shows some different attacks on the `XOR MAC', and also
describes several other security misfeatures of WTLS.
Finally, here is a third observation on the `XOR MAC', not mentioned in
the above paper or in your post. Take any ciphertext block and replace
it with 10n+1 repetitions of itself, for any n>0; then the MAC will
remain unchanged. This presents yet another easy forgery attack.
For example, modifying ciphertext X Y Z into X (11 Y's) Z will not be
detected by the MAC, if X,Y,Z each represent a single (8-byte) ciphertext
block. This has a very easily predicted effect on the resulting
plaintext: it inserts 10n copies of the plaintext block Decrypt(Y) xor Y.
If you repeat a ciphertext block that corresponds to some known plaintext
block (perhaps because it is part of a predictable TLS header or guessable
HTTP request or somesuch), you can even control the inserted plaintext
block to some extent.
You can also apply similar tricks to any sequence of consecutive
ciphertext blocks, if you like.
You can use this trick to do cut-and-splice attacks, a la Bellovin's
IPSEC work. For instance, suppose we have the ciphertext U V W that we
want to get decrypted for us. We wait until we get ahold of the channel,
perhaps using an echo feature in some application like suggested in
M.-J. Saarinen's paper. Then, when we see ciphertext X Y Z, we modify
it to become X (10 copies of U V W X) Y Z. This attack will not be
detected by the XOR MAC, and it lets us read any traffic we like.
At this point I would claim it should be clear that the `XOR MAC' is
fatally and fundamentally flawed.
--
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: 13 Dec 1999 19:24:07 -0800
"rosi" <[EMAIL PROTECTED]> writes:
>Also, password-based and password-dependent convey slightly different
> meanings. (Personal taste again). As far as SRP is concerned, due to
> the intended (DH) transformation, it gives an uncomfortable feeling to
> view it in the old concept of a password.
That's exactly the point - although the technology has been improved,
from the user's point of view, it's still password authentication. The
only difference is that it can't be broken from the wire. The user
should be unaware that the software is executing an authenticated DH-based
exchange underneath.
>It is implicit that the hash is necessarily:
>
> for all x, y, z, H(x, y, z)=H(H(x, y), z)
No, H(x, y, z) = H(concat(x, y, z)).
> Maybe too obvious, but B = v + g^b should really be B = H(v, s) + g^b?
No. The salt is already used to compute x, which is then used to
compute v.
> Similarly, x being defined as 'A private key derived from the password
> and salt' is not accurate. Let v = H(P, t), then x = H(P, t, s) for
On page 6, x is defined as being H(s, P), which is exactly a private key
derived from the password and salt.
> some (random t) and P being the password. Of course, if we look closely,
> such as going back to page 6, or looking at step 5, the relationship
> between x and v seems confusing.
On page 6 (assuming you have the canonical published paper), v = g^x (mod n).
>One other thing I find interesting is the dividing line between
> encryption and non-encryption.
Cryptography-Digest Digest #737
Cryptography-Digest Digest #737, Volume #10 Tue, 14 Dec 99 08:13:01 EST
Contents:
Re: Deciphering without knowing the algorithm? (Anti-Spam)
Re: Deciphering without knowing the algorithm? (Guy Macon)
Re: Insecure PRNG? (Guy Macon)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Insecure PRNG? (CLSV)
Re: Simple newbie crypto algorithmn (CLSV)
Re: How do you crack a Rotating Grille? (James Pate Williams, Jr.)
Re: How do you crack a Rotating Grille? (Jim Gillogly)
Re: Deciphering without knowing the algorithm? (Paul Schlyter)
From: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Mon, 13 Dec 1999 22:55:39 -0800
HKXLF wrote:
>
> Hi,
> I am new to cryptography although I am very interested in the subject. From
> browsing though this newgroup, I have come to a conclusion that, in order to
> decipher some message, all you need is to find the key. But how about the
> algorithm that is used the encrypt the text in the first place. Is it possible
> to decrypt some text without first knowing what algorithm is used to encrypt
> it?
>
> Anyway, I'll be grateful if anybody can satisfy my curiosity.
> Thanks,
> Herry.
HKXLF -
It is possible to decrypt text without knowing at first what the
employed cipher is. Properties of the ciphertext can reveal information
about the nature and operation of the cipher. There are books on
cryptanalysis that explain how to do this and give examples.
I'm a cryptanalysis neophyte. I'm working my way through William F.
Friedman's books on Military Cryptanalysis ( Parts I - IV )in the "Books
in the Cryptographic Series" from Aegean Park Press (You can get them
from Amazon.com). Some might say the example cipher systems are dated -
but working through the problems and examples is worth it. These are
example problems just as you described - decrypting text without first
knowing the algorithm used. Mr. Friedman shows how to determine the
likely cryptosystem used from several candidate systems by assessing the
characteristics of the ciphertext.
F.L.Bauer's "Decrypted Secrets" provides an additional overview of
cryptanalysis methods.
As for post-World War II (or post-Great Patriotic War for some readers)
cryptanalysis,
Schneier's book "Applied Cryptography" and Stinson's "Cryptography,
Theory and Practice" give examples of diffential cryptanalysis of block
ciphers. (Mr. Schneier also has a guide to self-education in block
cipher cryptanalysis at the Counterpane web site - see
http://www.counterpane.com/self-study.html ) Schneier's book covers
cryptanalysis of stream ciphers. And there's Barker's Cryptanalysis of
Shift-Register Generated Stream Cipher Systems from Aegean Park Press.
(Next on my list after I finish the 4 volume Friedman workout. )
Hope this is of some help,
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Deciphering without knowing the algorithm?
Date: 14 Dec 1999 02:08:29 EST
In article <834g8r$ou0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Surface Mount) wrote:
>
>If you were to take a common algorithm for encryption, and modify it
>significantly, how hard would it be to decipher the message, assuming a good
>algorithm?
The problem is that there are subtleties that newbies like you and me
don't understand - your significant mod might make it really easy
to crack usinf cryptoanalysis.
Do a web search on "security through obscurity" for some very
interesting concepts related to hiding your algorithm.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Insecure PRNG?
Date: 14 Dec 1999 02:11:53 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mok-Kong Shen)
wrote:
>
>Douglas A. Gwyn wrote:
>>
>> Mok-Kong Shen wrote:
>> > Does encrypting 2 charaters out of 100
>> > results in twice the strength of encrypting 1 character out of 100?
>>
>> Just because Guy Macon doesn't have a good measure of cryptographic
>> strength doesn't mean anything one way or another for the general
>> issue of whether such a measure is possible. It is obvious, however,
>> that your question would not fit into the framework of any valid
>> measure.
>
>I have expressed my opinion that a rigorous measure is not possible
>and offered arguments. The lines you quoted is only a side remark
>intended merely to say that the issue is not so simple as Mr. Macon
>apparently has thought.
To be totally fair, I thought that the issue was really, really
hard, then your side remark showed me that it was harder than that!
--
From: Mok-Kong Shen <[EMAIL PROT
Cryptography-Digest Digest #738
Cryptography-Digest Digest #738, Volume #10 Tue, 14 Dec 99 13:13:01 EST Contents: Re: Better encryption? PGP or Blowfish? (Tom St Denis) Re: Better encryption? PGP or Blowfish? (Tom St Denis) Re: Better encryption? PGP or Blowfish? (Tom St Denis) Re: Simple newbie crypto algorithmn (Eric Hambuch) Re: The Cracking of SecurityPlus! 4.32 (JPeschel) Re: The Code Book (Paul Schlyter) Re: Synchronised random number generation for one-time pads (Richard Herring) "The Cracking of Security Plus" completed (JPeschel) Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY) Re: Why no 3des for AES candidacy (Eric Lee Green) Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY) how easy would this encryption be to crack? (Christoffer =?iso-8859-1?Q?Lern=F6?=) How to implement different modes using the twofish algorithm? (Martin Bädeker) Re: NSA should do a cryptoanalysis of AES (Derek Bell) Re: NSA should do a cryptoanalysis of AES (Derek Bell) Looking for a DES implementation in JavaScript or VBScript ([EMAIL PROTECTED]) Re: Are thermal diodes as RNG's secure (Tim Tyler) Re: Data Encryption in Applet? (Tim Tyler) Re: how easy would this encryption be to crack? (Jerry Coffin) Re: Deciphering without knowing the algorithm? (Tim Tyler) Re: Deciphering without knowing the algorithm? (albert) From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: Better encryption? PGP or Blowfish? Date: Tue, 14 Dec 1999 12:58:55 GMT In article <8345je$4v8$[EMAIL PROTECTED]>, Phillip George Geiger <[EMAIL PROTECTED]> wrote: > Tom St Denis <[EMAIL PROTECTED]> wrote: > : I was just being honest. People never think twice before launching a > : flame war when I am wrong. I know two wrongs don't make a right, but > : what other response could i give? > > You could have briefly explained why his question was a bad one, and > pointed him at a FAQ. > > : His ignorant comparaison was just plain silly. > > And in the time it took you to think up that "witty" response, giggle > like the child you are, and hit "enter" - you could have posted something > far more interesting and useful to a newbie. But that's the thing, no one in sci.crypt cares about any real scientific discussion, it's just a flame war waiting to happend. Tom Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: Better encryption? PGP or Blowfish? Date: Tue, 14 Dec 1999 13:04:07 GMT In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote: > > Not always. Depends on the message space. > > Consider the reponse to a proposed contract. It can be encoded in a bit. > Any boolean message has this property. Some messages have even less > information. > > Consider the case of a "Go!" command. The message itself contains zero > information. The recipient is waiting for exactly this message and no > other. So the message consists of zero bits of plaintext plus whatever > authentication is necessary. > > Now consider the data rate of a channel used to transmit the Go! message. > Normally it has no data flowing through it, but there's a tacit streams of > "Not Yet!" messages that match the sampling rate of the receiver. This data > stream has no bits in it at all. Perhaps it has a stream of noise to > reassure the receiver that a mesage hasn't been missed. But there's no > information in the noise. It's just noise. > > Tough to crack such virtual messages. Ok true, I would not attack a message with 'Go!' in it. I would attack the messages that described what they should go do. Tom Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: Better encryption? PGP or Blowfish? Date: Tue, 14 Dec 1999 13:02:23 GMT In article <8348is$2g18$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote: >This just shows how fucking stupid you are little boy pain > in the ass. Try reading what a ZERO Iinformation system is > sometimes instead of opening your mouth. In a ZERO information > protocall the seeds are in there to solve any encryption including > that of a random file. IF you think mine has enough information > for a random file break your not only full of shit but you know > nothing about encryption. Try to learn something Tom becasue > your posts are gettting dumber and dumber and it is getting > frustracting wasting my time to try to improve your pee brain. I will just go out invent this new attack called brute force. I will win a nobel. If I can brute force any system, then that system has given me enough information to break it. And last time I checked most block ciphers fell into this category. No matter how you use the block cipher, if the key is fixed, and used on more then one block it can be attacked. Tom Sent v
Cryptography-Digest Digest #739
Cryptography-Digest Digest #739, Volume #10 Tue, 14 Dec 99 16:13:01 EST
Contents:
Re: How to implement different modes using the twofish algorithm? (Medical
Electronics Lab)
security of 3des ?= des ([EMAIL PROTECTED])
Re: security of 3des ?= des (James Felling)
Conditional (keyed) bidirectional hash function ? (Niall Parker)
Re: Why no 3des for AES candidacy ("karl malbrain")
Re: security of 3des ?= des (DJohn37050)
Re: security of 3des ?= des ("karl malbrain")
Re: Conditional (keyed) bidirectional hash function ? (Anton Stiglic)
Re: Are thermal diodes as RNG's secure (Scott Nelson)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Better encryption? PGP or Blowfish? ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy (Anton Stiglic)
How easy would this encryption be to crack? - revised (Christoffer
=?iso-8859-1?Q?Lern=F6?=)
Re: Why no 3des for AES candidacy (Anton Stiglic)
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: How to implement different modes using the twofish algorithm?
Date: Tue, 14 Dec 1999 12:09:42 -0600
Martin Bädeker wrote:
> I'm a newbie to this and have problems to implement following modes of
> Twofish: CFB1,CBC,ECB. I already verified - using given testvectors -
> that my implementations of makeKey, BlockEncrypt and BlockDecrypt are
> delivering the valid outputs, but I can't get proper results in CBC
> mode.
> For CBC I XORed the plaintext (PT) and the IV and at then encrypted it
> using my function. But the resulting ciphertext (CT) differs from the
> CBC testvectors.
> CT = Encrypt(PT xor IV)
> Any suggestions?
First set the IV = 0 and see if you get the same result as you'd
get for ECB. If so, your xor works.
Second, set PT xor IV = ECB PT. Try again and make sure that works.
If you get past those 2 steps, then it should be right, check that
you're feeding the ciphertext back to the right place for CBC.
Patience, persistence, truth,
Dr. mike
--
From: [EMAIL PROTECTED]
Subject: security of 3des ?= des
Date: Tue, 14 Dec 1999 19:02:53 GMT
i was wondering if it has been shown that 3des is more secure
than des.
my understanding is that if des transformations form a group
than any composition of des transformations is equivalent to
a single des encryption, which is bad from a security standpoint, but
that currently nobody knows if des transformations form a
group.
so ... if it is still up in the air, couldn't the EFF use it's
super-fast des cracking machine to try to find single-des equivalent
keys to some 3des-encrypted known plaintexts? if it finds equivalent
single-des keys for even just a few 3des keys (with no obvious
degenerate structure) that would really convince me not to use 3des
for anything.
or maybe the EFF has already tried this?
-- p
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: security of 3des ?= des
Date: Tue, 14 Dec 1999 13:28:45 -0600
[EMAIL PROTECTED] wrote:
> i was wondering if it has been shown that 3des is more secure
> than des.
>
> my understanding is that if des transformations form a group
> than any composition of des transformations is equivalent to
> a single des encryption, which is bad from a security standpoint, but
> that currently nobody knows if des transformations form a
> group.
DES has been proven not to be a group.
>
>
> so ... if it is still up in the air, couldn't the EFF use it's
> super-fast des cracking machine to try to find single-des equivalent
> keys to some 3des-encrypted known plaintexts? if it finds equivalent
> single-des keys for even just a few 3des keys (with no obvious
> degenerate structure) that would really convince me not to use 3des
> for anything.
>
> or maybe the EFF has already tried this?
>
> -- p
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Date: Tue, 14 Dec 1999 11:37:05 -0800
From: Niall Parker <[EMAIL PROTECTED]>
Subject: Conditional (keyed) bidirectional hash function ?
Hello,
I'm looking to find some information about defining a function which
can be computed initially in one direction using a key, then checked
in the reverse direction without the key, ie:
B = fcn_1(A,key)
A = fcn_2(B)
but fcn_2 is not invertible (can't compute B from A without key)
I've perusing the FAQs and web pages but haven't seen anything yet,
perhaps someone is aware of relevant places to look ? (hopefully this
is a trivial problem I'm too thick to notice the solution for ;)
Thanks.
... Niall
--
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject
Cryptography-Digest Digest #740
Cryptography-Digest Digest #740, Volume #10 Tue, 14 Dec 99 17:13:01 EST
Contents:
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Deciphering without knowing the algorithm? (wtshaw)
Re: how easy would this encryption be to crack? (Jim Gillogly)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Conditional (keyed) bidirectional hash function ? (wtshaw)
Re: how easy would this encryption be to crack? (wtshaw)
Re: How do you crack a Rotating Grille? (wtshaw)
Re: Deciphering without knowing the algorithm? (Douglas Hinton)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: Conditional (keyed) bidirectional hash function ? (Niall Parker)
Re: Conditional (keyed) bidirectional hash function ? (John Bailey)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Non-linear PRNGs (Mok-Kong Shen)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Conditional (keyed) bidirectional hash function ? ("Gary")
Re: security of 3des ?= des (James Felling)
Date: Tue, 14 Dec 1999 15:48:56 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Anton Stiglic wrote:
> Uri Blumenthal wrote:
>
>>
>>
>> > Do you have any idea of what you are talking about?
>>
>> Do you have any brains to comprehend what I'm talking about?
>> --
>> Regards,
>> Uri
>> -=-=-==-=-=-
>>
>
> Gee, you are a smart ass Uri Blumenthal, very polite person as
> well! Do you have any matters at all? You got a paper written and
> you think you are a genius. Read my other reply to see why your
> objection was nonsens and just confuses people...
You did not say why the objection was nonsense and confuses people, you
just asserted so. Is there some divine revelation you can share with
us?
--
Date: Tue, 14 Dec 1999 15:51:15 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Tim Wood wrote:
> Uri Blumenthal wrote in message <[EMAIL PROTECTED]>...
> >> >> Why isn't 3des being considered for the AES?
>
>
>
> >> >One good reason:
> >> >The AES is supposed to support the following different key sizes:
> >> > 128, 192, 256
> >> >
> >> >You can see why 3-DES, with it's single sized 168 bit key,
> >> >does not fit in this categorie.
> >
> >No I can't - there are ways to securely make key of any length
> >(from 64 bis to 768*3 bits) for 3DES.
> >
> >> of course it's effective key length (strength) is 112bit not 168bit...
> >
> >In general - this is incorrect. In particular, it HIGHLY depends
> >on the key schedule and how the DES engine is employed.
> >
> >See "A Better Key Schedule for DES-like Ciphers" paper on
> >
>
> Why Is it incorrect in general? There are lower strength attacks, but even
> then I think it would be incorrect to quote 3DES as 168bits ? It is
> missleading.
3DES can be used with two or three 56-bit DES keys, producing a 112-bit flavor
and a 168-bit flavor.
>
>
> Also doesn't DES include the Key schedule? a small quote from the above
> paper;
>
>
> A Feistel cipher consists of two parts:
>
> *the key schedule, which produces subkeys for each round, normally from the
> generating or main key;
> and
> *scramblingthe real encryption, which mixes the subkey bits with the
> input bits to produce the output bits.
>
>
> Not that it really matters that much, since 3DES is not a candidate.
>
> Tim
>
> --
>
> From my one-bit brain with a parity error.
>
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 15:22:51 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> HKXLF wrote:
> > Is it possible
> > to decrypt some text without first knowing what algorithm is used to encrypt
> > it?
>
> Yes, depending on the class of cipher being used.
The quickest means of attack, which has a good chance of working in many
cases, is to assign a tantalizing quest to Jim in the first place. If
your object is to learn what he knows, plan to work hard and well directed
for more years than you care to count.
--
There are those who are neither constrained by in belief of
their power over time and space.
All will have found too late when their time has run out,
and others find for them, a little space to be forgotten in.
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: how easy would this encryption be to crack?
Date: Tue, 14 Dec 1999 21:04:51 +
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]
Cryptography-Digest Digest #741
Cryptography-Digest Digest #741, Volume #10 Tue, 14 Dec 99 20:13:01 EST
Contents:
Re: Why no 3des for AES candidacy ("Rich Ankney")
Re: Non-linear PRNGs (John Savard)
Re: The Cracking of SecurityPlus! 4.32 (Troed)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Re: How to implement different modes using the twofish algorithm? (Eric Lee Green)
Re: Simple newbie crypto algorithmn (David Wagner)
Re: NAI granted export license for PGP (Keith)
Re: Non-linear PRNGs (David Wagner)
Re: Deciphering without knowing the algorithm? ("Arrianto Mukti Wibowo")
Re: Deciphering without knowing the algorithm? ("Arrianto Mukti Wibowo")
help: why q|(p-1) ("Arrianto Mukti Wibowo")
Re: Non-linear PRNGs (Tim Tyler)
Re: Non-linear PRNGs (Tim Tyler)
Re: Non-linear PRNGs (Tim Tyler)
Re: help: why q|(p-1) (David A Molnar)
From: "Rich Ankney" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 17:18:33 -0500
Trevor Jackson, III wrote in message <[EMAIL PROTECTED]>...
>Anton Stiglic wrote:
>
>> >
>> >
>> > You did not say why the objection was nonsense and confuses people, you
>> > just asserted so. Is there some divine revelation you can share with
>> > us?
>>
>> Sure, I could share (don't know if it's divine do!). The initial
>> question,
>> to the post was:
>>
>> Why isn't 3des being considered for the AES? Is it because it is
slower
>> than
>> DES?
>>
>> For which I answered:
>> One good reason:
>> The AES is supposed to support the following different key sizes: 128,
>> 192, 256
>> You can see why 3-DES, with it's single sized168 bit key, does not fit
>> in this
>> categorie.
>>
>> To which Mr. Uli responded:
>>
>>No I can't - there are ways to securely make key of any length
>> (from 64 bis to 768*3 bits) for 3DES.
>>
>> To which I responded negatively. 3DES, as define in the standard,
>> does not use 128, 192 nor 256 bit keys.
>
>"The standard"? What standard is that?
>
Umm, that would be FIPS 46-3 and ANSI X9.52, both of which allow
either 112-bit or 168-bit keys.
>3DES was originally proposed with a 112-bit key and E(D(E())) arrangement
to
>insure backward compatibility with DES. The 168-bit variant is not the
only
>valid usage.
>
True; 112-bit or 158-bit are allowed (and have been heavily studied).
>>
>>
>> What is so complicated? A modification of 3DES, as slight as it might
be,
>>
>> no longer defines 3DES (the standard).
>>
>> What do you not agree with?
>
>Your last statement. 3DES with 128/168 bits of warm key is still 3DES. It
>just has a key (mis)management wrapper to match the AES requirements.
>
No. Also, you both forget that AES has a 128-bit blocksize...
>In a similar vein standard ciphers with 64 or 128-bit keys can be damaged
by
>restricting the key space in order to get export approval. Such a
mechanism
>does not invalidate the algorithm. It still operates according to the
>standard. Thus the key restriction mechanism introduces no new weaknesses
or
>attacks except that of the reduced key space.
>
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Non-linear PRNGs
Date: Tue, 14 Dec 1999 15:11:43 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>Question: Has anyone studied such PRNGs from cryptological point
>of view? I surmise that they are extremely hard for analysis even
>with moderate values of n.
One thing is clear: the Blum-Blum-Shub algorithm, regarded as secure,
is closely related to this.
John Savard (jsavardecnabca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (Troed)
Subject: Re: The Cracking of SecurityPlus! 4.32
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Dec 1999 22:22:18 GMT
[EMAIL PROTECTED] (JPeschel) wrote:
>source code to Kremlin for analysis. But he didn't
>crack Kremlin or find any weakness; he recently
>e-mailed Mach5 Software and admitted defeat,
>saying 'OK, you won. I surrender!'."
Nice to hear, even though it makes all those photos in my .kgb a loss
:) Thanks for your input!
___/
_/
Nazister, rasister och andra dårar - ger bara sig själva kalla kårar
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 23:39:35 GMT
In article <[EMAIL PROTECTED]>, Douglas Hinton <[EMAIL PROTECTED]>
wrote:
>Something which no one mentioned is that if you know what kind of
>encryption equipment is being used, one needs only to buy a similar unit
>and install the known key. The equipment could have the worlds strongest
>algorithm, but a person wouldn't need to anything about it to "listen
>in."
>
Something tells me that your not to bright. Where does one get the
"known key" You must be the kind of person who would be the type
t
Cryptography-Digest Digest #742
Cryptography-Digest Digest #742, Volume #10 Wed, 15 Dec 99 00:13:01 EST
Contents:
Re: The Code Book (David Hamer)
Re: Why no 3des for AES candidacy (albert)
Does this seem scary to anybody else??? It should!!! (albert)
Re: security of 3des ?= des (Tim Tyler)
Re: security of 3des ?= des ("karl malbrain")
Re: NAI granted export license for PGP (Pelle Evensen)
Re: Security analysis of digitalPersona's U.are.u? (Eric Murray)
Re: Non-linear PRNGs (Pelle Evensen)
Re: Security analysis of digitalPersona's U.are.u? (Eric Murray)
Re: NAI granted export license for PGP (Mike Andrews)
discrete logorithm reduction to factoring ([EMAIL PROTECTED])
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Better encryption? PGP or Blowfish? (molypoly)
Date: Tue, 14 Dec 1999 20:09:03 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: The Code Book
Possibly due to confusion stemming from differences
between the Gregorian and Julian calendars. While the
former was officially proclaimed by Pope Gregory XIII in
1582 and was adopted almost immediately by most European
Catholic states it was not adopted in England until 1752.
According to my [Gregorian] calendar program 15 October
1586 fell on a Wednesday.
DHH
Warner wrote:
>
> The first sentence of Simon Singh's _The Code Book_ is, "On the morning of
> Wednesday, 15 October 1586, Queen Mary entered the crowded courtroom of
> Fotheringhay Castle". The calendars I have referred to give this date as
> being on a Saturday. I'm interested in hearing comments on this apparent
> inconsistency or references to such.
--
~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED] http://www.eclipse.net/~dhamer
~~~
--
From: albert <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 17:38:29 -0800
And Bill Clinton didn't have sexual relations with that woman Monica... What's your
point? What, because it's in some book in the law library that the NSA can't read
domestic mail, you assume it's true?? Get a clue, watch some conspiracy movies or
something. Oh, I mean, they are a government organization, they would NEVER break
the law...
yada yada yada repeat that next time you pass by Waco TX or Ruby Ridge...
Albert
"Douglas A. Gwyn" wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > 1. Depending on how one combines the cipher to make 3DES it could be come
> > to hard for current NSA to quickly decode the message for law enforcement.
>
> I think you mean FBI. It is explicitly against the law for NSA to
> intercept communications for the purpose of domestic law enforcement,
> unless one or more of the communicants are foreign. And, before you
> say that NSA just ignores the law, that's not so -- this requirement
> has an effect on how operations are conducted, which wouldn't be
> necessary if the law were being ignored.
>
> Last I heard, the FBI *were* being budgeted to establish a significant
> network/cryptologic intelligence branch. Comrades Clinton, Gore,
> Reno, and Freeh have this Big Brother plan, you see... law enforcement
> is just an excuse.
>
> > The speed thing is what most phony crypto gods would have you belive the
> > reason is. But in fact with the bloated operating systems one uses know a days
> > and as machines get faster very week this is really a lame reaon when one
> > wants real security.
>
> Speed *is* important in order that encryption become as widespread as
> it really should, e.g. on network links. We're already in the age of
> fiber-optic communication.
--
From: albert <[EMAIL PROTECTED]>
Subject: Does this seem scary to anybody else??? It should!!!
Date: Tue, 14 Dec 1999 17:42:28 -0800
I'm referring to the fact that we are suppose to trust NAI products for
security, they are suppose to be the premiere in security products, yet
they run NT??? This cannot scare just me. ASP has more holes than a
drug user on Santa Monica BLVD. I seriously call into question now, the
quality of their "security" products if this is what their idea of
"security" is.
Albert
Keith wrote:
> On Mon, 13 Dec 1999 23:25:52 GMT, Bubba
> <833v9r$vn5$[EMAIL PROTECTED]> wrote:
>
> >http://www.nai.com/asp_set/about_nai/press/releases/pr_template.asp?
> >PR=/PressMedia/12131999.asp&Sel=647
> >
> >
>
> The problem is that we don't know what strength the cipher is.
> PGP could be allowed to export 40 bit versions. Or maybe NSA
> has created a crack for PGP. If the NSA has developed a crack
> then it won't affect home users, but would be a concern to
> business and government users world wide.
> --
> Best Regards,
>
> Keith
> ---
> Free Software: Pegasus & Mercury E
Cryptography-Digest Digest #743
Cryptography-Digest Digest #743, Volume #10 Wed, 15 Dec 99 07:13:01 EST
Contents:
Re: NAI granted export license for PGP ([EMAIL PROTECTED])
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: How easy would this encryption be to crack? - revised (Steven Siew)
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: security of 3des ?= des ("Douglas A. Gwyn")
Re: Simple newbie crypto algorithmn ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? (Guy Macon)
Re: The Code Book (Guy Macon)
Re: Simple newbie crypto algorithmn ([EMAIL PROTECTED])
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Simple newbie crypto algorithmn (Steven Siew)
Re: Deciphering without knowing the algorithm? (CLSV)
Re: Simple newbie crypto algorithmn (CLSV)
Re: Simple newbie crypto algorithmn (CLSV)
From: [EMAIL PROTECTED]
Subject: Re: NAI granted export license for PGP
Date: Wed, 15 Dec 1999 05:27:36 GMT
Mike Andrews <[EMAIL PROTECTED]> wrote:
> : Why haven't we seen any people ranting about "NSA must have solved the
> : discrete log and factoring problems" yet? :)
> They've all been taken away in the black helicopters.
Don't be silly, the NSA uses standard rental car models and colors for
this sort of thing, not an eye-catching black helicoptor. They've all
been taken away in white Plymouth Voyagers. :)
--
Matthew Gauthier <[EMAIL PROTECTED]>
--
From: Steven Siew <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Wed, 15 Dec 1999 16:46:44 +1100
David Wagner wrote:
>
> In article <[EMAIL PROTECTED]>,
> Steven Siew <[EMAIL PROTECTED]> wrote:
> > It's not designed to be fast. It's designed to be secure. Again memory
> > was not considered by me during the design process.
>
> Anyone can design a secure cipher if it's allowed to be big and slow.
> Just use umpteen-DES, or somesuch, with ten copies of D. Scott's favorite
> chaining mode thrown in for good measure (why not?).
>
> The question is, why would anyone use a new, slow algorithm when there
> are others available that are both faster and better understood (=> more
> likely to be secure)?
>
> (Maybe this was intended only for fun, and was not suggested for actual
> use. If so, I apologize; my comments would be irrelevant in such a case.)
Why would anyone uses a new slow algorithmn? People would use it if they
can TRUST it! Please refer to my design criteria.
So I set about proving the above statement. In short I want to
write a crypto program with the following chracteristics:
> 1. The program must be simple and easy to understand. Thus
the > public can see easily the strengths of the encryption.
2. The program must be cryptographically powerful enough not to
be cracked even by using all the computers in the world in
less than a 1000 years.
3. No special knowledge of arcane cryptography is required.
No maths more difficult than that encountered in high
school is required.
Remember I'm aiming at people who is not particularly skilled in
cryptography. People are naturally reluctant to use program which they
don't understand how it works.
Steven Siew
--
From: Steven Siew <[EMAIL PROTECTED]>
Subject: Re: How easy would this encryption be to crack? - revised
Date: Wed, 15 Dec 1999 17:05:27 +1100
Christoffer Lernö wrote:
> Oops.. saw the flaws myself.
> What about this:
>
> (the class itself holds the two key arrays (byte[]) meKeyA and meKeyB,
> there are also
> two looking variables, meSpin (getting its starting value from meKeyA &
> meKeyB)
> and meSpin2 with starting value 0)
>
> To decode a byte b:
Can you tell us why you think this is a strong crypto algo? Frankly I'm
not good at java, is byte same as char or is it same as unsigned char?
Kindly provide some explaination to your algo. What are your design
criterias? Have you thought about how to crack it yourself? How well
does it defend against known plaintext attacks?
How well does it encrypt a plaintext which differs from another
plaintext by a single bit?
Steven Siew
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Wed, 15 Dec 1999 06:48:49 GMT
albert wrote:
> Get a clue, watch some conspiracy movies or something.
That's apparently where you get *your* "information".
Mine is much more reliable.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Wed, 15 Dec 1999 06:50:23 GMT
Jim
Cryptography-Digest Digest #744
Cryptography-Digest Digest #744, Volume #10 Wed, 15 Dec 99 11:13:02 EST
Contents:
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: security of 3des ?= des (Frank Gifford)
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: discrete logorithm reduction to factoring (Nick Williams)
help: I need to crack a ms-access pwd (Olaf Kesch)
Re: how easy would this encryption be to crack? (Christoffer
=?iso-8859-1?Q?Lern=F6?=)
Re: discrete logorithm reduction to factoring (Anton Stiglic)
SSL/RC4_128_EXPORT40 ("Tobias Martin")
Re: help: why q|(p-1) (Anton Stiglic)
Re: Non-linear PRNGs (John Myre)
Prime series instead (Re: Pi) (Matthew Montchalin)
Re: SSL/RC4_128_EXPORT40 (Arturo)
Re: Better encryption? PGP or Blowfish? (James Felling)
Re: Why no 3des for AES candidacy (Paul Koning)
Re: discrete logorithm reduction to factoring (John Bailey)
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Wed, 15 Dec 1999 12:32:42 GMT
In article <836gmb$1g50$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Asshole even if I used a 4 bit key if the program I used was done
> correctly you may not know what the anwser is. With a ZERO
> knowledge method you KNOW what the encyrpted message is.
> You may not know what it means but you know what the message
> is ASSHOLE wake up and learn something. I getting tired of changing
> your diapers so to keep from using so many swear words you going
> back on my Kill file list. Actually your the only one on it.
You are possibly the most ignorant person on the face of earth and may
god have mercy on your soul.
BTW: If the message space is larger then the key space as is the case
for all block ciphers/stream ciphers, then you can always brute force
the keyspace. It might be infeasible in the ammount of time it will
require, but it's still possible.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: security of 3des ?= des
Date: 15 Dec 1999 08:29:58 -0500
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>karl malbrain <[EMAIL PROTECTED]> wrote:
>: <[EMAIL PROTECTED]> wrote in message
>
>:> i was wondering if it has been shown that 3des is more secure
>:> than des.
>:>
>:> my understanding is that if des transformations form a group
>:> than any composition of des transformations is equivalent to
>:> a single des encryption,
>
>: In the sense that DES is a 64 bit block function that MAPS one input to one
>: output, yes, you can combine DES operations as a single MAPPING, and there
>: is no security gain. [...]
>
>However you look at it, it's been proven not to be true that any
>composition of DES transformations is equivalent to a single DES
>encryption.
Well, you should be clear here. It's true that since DES is not a group,
that 3-DES cannot be reduced to 1-DES. But that does not imply that it
is impossible for some (plaintext1, key1, ciphertext1) tupple in N-DES to
be found as (plaintext1, key2, ciphertext1) in 1-DES.
-Giff
--
Too busy for a .sig
--
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Wed, 15 Dec 1999 13:43:08 -
>I am just an Engineer also but had to do programming all my life
>since most computer people not up on engineer problems.
>They lack the mathematical background one gets in Engineering.
>
you taking the mickey?
>David A. Scott
>--
tim
--
From: [EMAIL PROTECTED] (Nick Williams)
Crossposted-To: comp.theory
Subject: Re: discrete logorithm reduction to factoring
Date: 15 Dec 1999 13:54:47 -
In article <8373h1$7vb$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>It is my understanding from these discussions that
>if there was a solution for discrete log, with say
>a worst case asymtote that was cubic, that then factoring
>would be polynomial as well.
Given that this is cross-posted to sci.crypt, as well as
comp.theory, I guess you're most interested in the cryptographic
take on this.
To be honest, I've no idea whether being able to do a discrete
logarithm in polynomial time implies the ability to factor in
polynomial time.
I do know that the ability to do discrete logarithms in finite
groups would be allow you to break (for example) RSA much more
easily, since the inverse operation of modular exponentiation is
the calculation of a discrete logarithm in a finite group: the
difficulty of breaking the RSA cryptosystem has not (to my
knowledge) ever been proven to be difficulty of factoring (pq).
Cheers,
Nick.
--
[ Nick Williams ]
[ MSc Computation Mobile - 07957-138179 ]
[ New College, Oxford http://www.new.ox.ac.uk/~nick/ ]
Cryptography-Digest Digest #745
Cryptography-Digest Digest #745, Volume #10 Wed, 15 Dec 99 14:13:01 EST
Contents:
Re: How easy would this encryption be to crack? - revised ("Tim Wood")
Re: Non-linear PRNGs (David Wagner)
Re: Non-linear PRNGs (David Wagner)
beginner question (Michael Combs)
Re: discrete logorithm reduction to factoring (David Wagner)
Re: SSL/RC4_128_EXPORT40 (David Wagner)
Re: Why no 3des for AES candidacy (wtshaw)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: The Code Book
Re: Data Encryption in Applet? ("Law Wun Suen, Brian")
Re: Conditional (keyed) bidirectional hash function ? (Niall Parker)
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Skytale? (John Bottoms)
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Re: Better encryption? PGP or Blowfish? (James Felling)
Re: Why no 3des for AES candidacy (Eric Lee Green)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Non-linear PRNGs (Mok-Kong Shen)
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: How easy would this encryption be to crack? - revised
Date: Wed, 15 Dec 1999 16:39:29 -
Steven Siew wrote in message <[EMAIL PROTECTED]>...
>Frankly I'm
>not good at java, is byte same as char or is it same as unsigned char?
nothing about the algorithm:
but in Java a "char" is a Unicode character (16 bits) a "byte" is 8bits (not
pretentious it _could_ be different in Java).
>Steven Siew
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Non-linear PRNGs
Date: 15 Dec 1999 08:36:04 -0800
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> I'm not convinced that the bootstrapping to more bits would work
> so straightforwardly. Doesn't the same observation about low bits
> not depending on high bits hold for linear systems? AFAIK, those
> are not solved in this stepwise way.
Linear systems usually aren't (because there are better ways),
but they could be.
> And even reducing mod 4 leaves
> f(x) = a_0 + a_1*x + a_2*x^(2) + a_3*x^(3).
Suppose there are n unknown coefficients a_0,...,a_n. Then it should
be clear that, at the very least, there is an attack using O(m * 2^n)
work, since once you know the a_i's mod 2^{k-1}, you can learn them
mod 2^k by simply guessing their k-th bits and checking the equation
above mod 2^k. Now iterate from k=1 to k=m; in each iteration, you
guess n bits (one bit for each coefficient), so the total running time
is as claimed.
And I think this idea can be further improved, by noting that
x^(k) = 0 mod 2^k for all x,
and Pr[x^(k) = 0 mod 2^{k+1}] = 1/2,
and so on.
(Or roughly like that: it might be x^(k+c) for some small constant c.)
Consequently, in the k-th iteration, we need to know only k bits of a_0,
k-1 bits of a_1, k-2 bits of a_2, ..., one bit of a_{k-1} -- and we
don't need to know a_j for any j>=k.
Therefore it will take only O(k * 2^k) work to be able to predict the
low k bits of the output of this generator. This will often already be
enough to provide enough of an entry to read a fair amount of traffic,
given the redundancy in English text.
(It takes O(m*min(2^m,2^n)) work if you want to predict the entire output,
using this technique, so better choose n and m to be large...)
And I suspect there may well be better attacks.
I just don't have time to look any deeper.
-- David
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Non-linear PRNGs
Date: 15 Dec 1999 08:38:18 -0800
In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
> Side note, has anyone studied the cryptographic properties of multiply with
> carry generators?
What cryptographic properties?
--
From: Michael Combs <[EMAIL PROTECTED]>
Subject: beginner question
Date: Wed, 15 Dec 1999 16:27:29 GMT
I have little or no experience with encryption/decryption and have a
small problem I hope you can help me with. I am trying to decode a file
format that appears to be encrypted by the rearrangement of chunks of
data and apparently the use of offsets. Most of the data is text and
can be clearly read, although in pieces throughout the file. These
files are large and the data doesn't seem to have a simple systematic
scheme. A data set, encrypted twice, results in a different output
file. This, I am assumming, means that all of the data to decode the
file is in the file. Is there any logical or statistical analysis I can
use the break this code. I have access to the data set and the
encryption app so I can create the encrypted output. I would be
extremely greatful to anyone that could assist me.
Thanks in advance,
mike
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: comp.theory
Subject: Re: d
Cryptography-Digest Digest #746
Cryptography-Digest Digest #746, Volume #10 Wed, 15 Dec 99 18:13:01 EST
Contents:
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: discrete logorithm reduction to factoring ("Roger Schlafly")
Re: Non-linear PRNGs (John Savard)
Re: Skytale? (John Savard)
Re: Prime series instead (Re: Pi) (Erik Max Francis)
Re: Deciphering without knowing the algorithm? (Paul Koning)
which is safer for creating session keys (Tom St Denis)
Re: The Code Book (Jim Reeds)
Re: how easy would this encryption be to crack? (Frank Gifford)
Re: discrete logorithm reduction to factoring (Scott Fluhrer)
Re: how easy would this encryption be to crack? (Jerry Coffin)
Off topic -- 4 year old (Sukhoi2000)
Re: Simple newbie crypto algorithmn ([EMAIL PROTECTED])
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Re: security of 3des ?= des (Paul Schlyter)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Wed, 15 Dec 1999 19:44:52 +0100
Tim Tyler wrote:
>
> The BBS PRNG derives its security from the difficulty of
> factoring the modulus into its large prime factors.
>
> The generator described at this thread's head has a modulus of 2^m -
> and multiplying primes together is not even mentioned.
I don't think that all cryptologically good PRNG must follow the
line of BBS. If the cofficients of the polynomial can be shown to
be hard to infer and the bits are statitically good,then one has a
serious candidate of use in applications. Note that BBS takes
only 1 bit from each number generated. The present scheme is
intended, as far as I understand, to use all 32 bits (assuming 32
bit word size). Now one can take the parity of the 32 bits, i.e.
obtaining only 1 bit from each number generated. In this case I am
not quite sure that the present scheme does not offer quite high
security. (Anyway I am not yet aware of any work on analsis about
parity bit sequences.)
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Wed, 15 Dec 1999 19:44:22 +0100
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> :Let f(x) = a_0 + a_1*x^(1) + a_2*x^(2) + . + a_n*x^(n)
> :where x^(k) = x(x-1)(x-2)...(x-k+1).
> :Then the generator u(i) = f(u(i-1)) mod 2^m (m>2) has period
> :2^m if and only if the following congruences hold:
> :a_0 = 1 mod 2, a_1 = 1 mod 4, a_2 = 0 mod 2, a_3 = 0 mod 4.
>
> [...]
>
> : Question: Has anyone studied such PRNGs from cryptological point
> : of view? I surmise that they are extremely hard for analysis even
> : with moderate values of n.
>
> The reference I was thinking of was from RFC1750:
>
>Not only have linear congruent generators been broken, but techniques
>are now known for breaking all polynomial congruent generators
>[KRAWCZYK].
>
> [KRAWCZYK]: How to Predict Congruential Generators, Journal
> of Algorithms, V. 13, N. 4, December 1992, H. Krawczyk.
>
> http://www.cis.ohio-state.edu/htbin/rfc/rfc1750.html
> http://blitzen.canberra.edu.au/RFC/rfc/rfc1750.html
>
> I /believe/ the generator proposed above *is* simply a polynomial
> congruent generator - if you expand out the "^" operations into their
> component parts.
You don't have to /believe/. Isn't it at first look obvious to you
that f(x) IS polynomial? Isn't BBS based on a polynomial (a quadratic)
and hence according to the above broken?
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Wed, 15 Dec 1999 19:44:38 +0100
John Savard worte:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >Question: Has anyone studied such PRNGs from cryptological point
> >of view? I surmise that they are extremely hard for analysis even
> >with moderate values of n.
>
> One thing is clear: the Blum-Blum-Shub algorithm, regarded as secure,
> is closely related to this.
I have only poor knowledge of BBS, hence a question: What can be said
of the period of BBS in general? (Would the period be dependent on
the choice of the seed?) Thanks in advance.
M. K. Shen
--
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: discrete logorithm reduction to factoring
Date: Wed, 15 Dec 1999 10:07:52 -0800
<[EMAIL PROTECTED]> wrote in message
news:8373h1$7vb$[EMAIL PROTECTED]...
> Is it true that discrete log reduces to factoring ?
Unknown. All we know is that known techniques for factoring
have analogous techniques for discrete logs, and vice versa.
The asymptotics are similar, but in the range of cryptographic
interest the discrete log implementations are a lot more
difficult than factoring.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Non-linear PRNGs
Date:
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #10 Thu, 16 Dec 99 00:13:02 EST
Contents:
Re: Deciphering without knowing the algorithm? (CLSV)
Re: which is safer for creating session keys (Hanna Pehrson)
Re: Non-linear PRNGs (Hanna Pehrson)
Re: Non-linear PRNGs (Tim Tyler)
Re: Non-linear PRNGs (David Wagner)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Invitation to our homepage ("(ÁÖ)»ó¾Æ´º¸Åƽ")
"Day of Deceit" by Robert Stinnett (Anonymous)
Re: Prime series instead (Re: Pi) ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Off topic -- 4 year old ("r.e.s.")
Re: Scott's Screaming Security Method (lobsterboy)
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Wed, 15 Dec 1999 23:18:34 +
"SCOTT19U.ZIP_GUY" wrote:
> [...] Yes I know not all the good cryptoheads live in the US
> but what makes you think the NSA would not kill or silence
> them if they are precieved as a threat. I though just this last
> year there was a strange death of a European expert. Do
> you really thing the NSA would let some one in Europe
> make real progress who was not controlled directly by
> them.
Well I wasn't talking specific of Europe. Asia has many
bright cryptographers, they can also be found in the Middle East,
maybe some are in Africa and South Amerika. The former Soviet Union
probably has more than we can count.
Some are working for agencies like NSA (i.e. out of reach),
many of them work for universities and companies. Their
safety lies in their numbers. There are just too much to
threaten, bribe or kill. But this kind of discussion belongs
to alt.conspiracy.
> Don't forget even the Swiss are in bed with the NSA
> you do remember how they modifed the swiss crypto equipment
> so as to help in spying.
I have heard the rumors. But remember that Crypto AG
can not really be considered a member of the open cryptographic
community. They use many (company)secret algorithms.
> >Breaking a cipher costs effort. So if someone is willing to
> >take time to look into a design on this forum it is a favour.
> Yes I did consider it a favor. And I understanf Mr BS and
> friends have looked at my stuff but don't have the balls to say
> much about it. I think it is to embarassing for them.
Well, maybe your cipher is hard to understand and/or break.
This does not mean per se that the security is as high as you
claim it is. Most attention these days goes to the AES contest
which is the most important cryptographic event
of this moment. So it is logical to see more cryptanalysis
on the contestants than on your (probably complex) cipher.
Regards,
Coen Visser
--
From: Hanna Pehrson <[EMAIL PROTECTED]>
Subject: Re: which is safer for creating session keys
Date: Thu, 16 Dec 1999 00:55:36 +0100
Tom St Denis wrote:
> Which is safer hashing KEY+SALT or SALT+KEY? I meant the actual order
> in which the data is stored. [or does it matter at all]. I am using
> SHA-1 as the hash btw.
>
> I ask this because I have been fiddling with Peekboo which uses
> KEY+SALT format, and I wonder if that is ok. Normally if KEY+SALT were
> under 256 bits it wouldn't matter with sha since it expands them with
> thourough mixing, however in peekboo I hash the hexidecimal copy of
> both so it's actually 576 bits of data being hashed.
This paper discusses some vulnerabilities in MACs built on hash functions,
in particular analysis of using keys as prefix, suffix and envelope for
the message;
B. Preneel and P. van Oorschot, MDx-MAC and building fast MACs from hash
functions,
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/preneel/mdxmac_crypto95.ps.gz
/Pell
--
From: Hanna Pehrson <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Thu, 16 Dec 1999 01:32:07 +0100
David Wagner wrote:
> In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
> > Side note, has anyone studied the cryptographic properties of multiply with
> > carry generators?
>
> What cryptographic properties?
Sorry for being vague. In particular, how easy it would be to deduce the
state of a generator of this kind, based on its output?
All multiplication and addition is mod 2^w.
h = w / 2
m[] are constants satisfying m[x] * 2^h -1 is prime.
s[] is the state of the generator
m[] and s[] are the same size
For each output of h bits, do
c' = m[x-1] * s[x-1] + m[x-2] * s[x-2] + m[x-...] * s[x-...] +
c / 2^h
s[x] = c' / 2^h
output = s[x]
This assuming m[] is kept secret.
/Pell
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Dec 1999 00:20:46 GM
Cryptography-Digest Digest #748
Cryptography-Digest Digest #748, Volume #10 Thu, 16 Dec 99 10:13:01 EST
Contents:
Keystrokes monitored/encryption useless (molypoly)
Re: Off topic -- 4 year old (Jim Gillogly)
Cryptanalysis ([EMAIL PROTECTED])
Re: Simple newbie crypto algorithmn ("Douglas A. Gwyn")
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: "Day of Deceit" by Robert Stinnett ("Douglas A. Gwyn")
Re: Skytale? (Robert Stonehouse)
Re: Why no 3des for AES candidacy (Hideo Shimizu)
How to check the speed of encryption/decryption (=?EUC-KR?B?wPyw5sit?=)
Re: Why no 3des for AES candidacy ("Douglas A. Gwyn")
Help needed determining algorithm/key ("security199")
Re: Keystrokes monitored/encryption useless (Timothy M. Metzinger)
Re: Non-linear PRNGs (Herman Rubin)
Re: Why no 3des for AES candidacy ("Trevor Jackson, III")
Re: Cryptanalysis (SCOTT19U.ZIP_GUY)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: How to implement different modes using the twofish algorithm? ("M.Bädeker")
Re: Simple newbie crypto algorithmn (Terry Ritter)
From: molypoly <[EMAIL PROTECTED]>
Subject: Keystrokes monitored/encryption useless
Date: Thu, 16 Dec 1999 04:56:56 GMT
Take a look at the latest article from Privacytimes.com at
http://www.privacytimes.com/dirt_8_17.htm
The program is called DIRT and it records all your keystrokes. When
you're online, it sends them to the receipient.
This means that your keystrokes made while making your encryption
keys are now worthless! How would one get around this if this software
got into the wrong hands?
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Off topic -- 4 year old
Date: Thu, 16 Dec 1999 05:36:24 +
"r.e.s." wrote:
> This looks to me like a re-run of the hoax known
> as "the Internet's most prevalent thought virus".
> See
> http://www.web.co.za/arthur/craig01b.htm
Agreed, but it's not. The Urban Legends site researched this one,
and as of 9 Dec 1999 Miss Paige Lane was alive and expected to
live a few more weeks, and has gotten sacks of cards already.
Spamming it to unrelated groups is a terrible idea, but the info
appears legit. See www.snopes.com, select Search at the bottom,
and search for Paige. I imagine she has plenty of cards by now.
--
Jim Gillogly
26 Foreyule S.R. 1999, 05:29
12.19.6.14.4, 6 Kan 12 Mac, Fifth Lord of Night
--
From: [EMAIL PROTECTED]
Subject: Cryptanalysis
Date: Thu, 16 Dec 1999 05:25:14 GMT
I'm doing a paper on Cryptography and It's Affect On The Information
Age. It's mostly about crypto in regards to current US law, however,
I have a brief primer on crypto in the first few pages. I need to
source everything that is not an oppinion. I remember reading
sometihng a few weeks ago about how cryptosystems are often created to
meet a purpose and you wouldn't use a difficult cryptosystem to apply
to a message to send info that will expire in one week.
My line is "The basic theory is to make a cryptosystem which can be
applied with the least amount of effort but is impractical to break
before the information becomes irrelevant using the currently available
equipment."
I need to source that, anyone know a web page, book, magazine article,
etc which covers the above? I can't remember for anything where I saw
that info.
I'd appreciate a quick reply.
Thanks,
Stephen Benjamin
EML: [EMAIL PROTECTED]
Fax: 815-333-3186
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Thu, 16 Dec 1999 06:21:35 GMT
[EMAIL PROTECTED] wrote:
> You are asking for free cryptanalysis with no reward. Proving that
> your method is insecure would mean spending a lot of time to reach a
> conclusion that most readers of your post would immediately suspect --
> that you are perhaps a little too keen on your skills for your own good.
Worse, invariably the result is that the person proposes a tweak
to his original flawed proposal to address the specific weakness
pointed out (which is usually just the first one discovered, not
an exhaustive list of them), and we're back to square one. A lot
of time can be wasted playing that game.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Thu, 16 Dec 1999 06:24:47 GMT
wtshaw wrote:
> Of course, you could always weave in a foreign angle, like the guy
> was wearing foreign made threads, or ate at other than a domestic
> oriented cafe.
Don't be absurd.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subj
Cryptography-Digest Digest #749
Cryptography-Digest Digest #749, Volume #10 Thu, 16 Dec 99 12:13:01 EST
Contents:
Re: Help needed determining algorithm/key (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: Off topic -- 4 year old (SCOTT19U.ZIP_GUY)
Mr SHAW needs a BEER (SCOTT19U.ZIP_GUY)
Re: Ellison/Schneier article on Risks of PKI ("Tim Wood")
Re: Simple newbie crypto algorithmn (Johnny Bravo)
Re: Deciphering without knowing the algorithm? (CLSV)
Re: Keystrokes monitored/encryption useless (Roger Carbol)
Re: Keystrokes monitored/encryption useless (Johnny Bravo)
Re: Why no 3des for AES candidacy (Paul Koning)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Help needed determining algorithm/key
Date: Thu, 16 Dec 1999 16:04:12 GMT
In article , "security199"
<[EMAIL PROTECTED]> wrote:
>
>
>Hi,
>
>I am evaluating a software application that protects some
>data using a method that needs a password. That password
>is encrypted and stored in an easily access able file.
>
>I am sure that this method of security is not secure at
>all, but the company selling the application doesn't
>seem to "get it", insisting that it is secure.
Maybe they really don't want secureity. I have heard of
some large banks that were using secure crypto that the Feds
may have had trouble reading the data so they stepped in and
made them use something else. If its for a job here in the US
you have to realize security is only a PR thing you really can't
do to good a job.
>
>I would like to determine the algorithm and key used
>to encrypt the password, thus showing them how the encrypted
>password stored in the file is easily decrypted thus allowing
>access to the data.
One common way to show this is see how they use the
encrypted data. Let them give you a test set of files and with
something that traces through the program see what different
paths are taken when the correct and incorrect password are used.
That is how many common systems fail. It is never wise to store the
password in the file even in encrypted form that is to be checked.
In my software I never store the password. I show a check number of
some sort that the users can look out to see it it is the same as when
he first encrypted a file but I will use whatever he types in as password
there is no check and it will encrypt or decrypted based on what the
user types in. If he types in the wrong one to bad. There is nothing
to test it with. WHen I worked for the FEDS they used commerical
applications that used the password in the wrong why on the Univac
and when you showed management how trival it was to break they
just got angry since they prefer to pretend it is safe.
Thats just the way commerical applications are and I think that is
really what the governent prefers business people use. After all they
can just pass a law saying its illegal to decrypted the data if your
not the intended recipent and of course our enimes are afraid of our
paper laws.
>
>I don't have the skills necessary to determine this, so I am
>asking you experts for help. I have generated a bunch of
>encryption's of the following: A,AA,ABCD,ABCDEFGHIJKLMNOP
>A salt must be used allowing different encrypted
>values so I have encrypted each of these plaintexts several times.
>Note that the encrypted values are always exactly twice as long as
>the plaintext. Also note that in lines 18, 35, 37, 39, and 40,
>the .'s (period's) are actually characters with hex code 7F.
>The . character doesn't otherwise appear to occur in the
>encrypted text. These plaintext passwords were entered as
>upper case, but I believe the password actually needed is
>case insensitive, so the case may not necessarily be preserved
>in the encryption/decryption process (but I have no reason to
>believe it isn't).
>
>If more plaintext encryption's would be helpful, let me know, I
>can create more.
>
>Also, if determining the algorithm/key used in this encryption
>is more difficult than I believe (unable to determine it without
>a major effort), then I would like to know that.
>
>Thank you all for any thoughts on this.
>
>
>Line PlaintextEncrypted
> ==
>01 ACR
>02 AN_
>03 Adu
>04 Akz
>05 A>O
>06 AET
>07 Afw
>08 ACR
>09 A9H
>10 AL]
>11 AET
>12 A;J
>13 A;J
just looking at a few I do see patterns CR ET ;J each of these is repeated
more than once notice these are 15 apart. Some are not my guess is this
method will not encrypt random bytes but only a subset of printable ascii
>
>14 AA N@;@@FU6Sj_QJQQWdGb{
Notice the N and the
Cryptography-Digest Digest #750
Cryptography-Digest Digest #750, Volume #10 Thu, 16 Dec 99 17:13:00 EST
Contents:
Q: BBS (Mok-Kong Shen)
Re: Q: BBS (David A Molnar)
Re: Deciphering without knowing the algorithm? (Paul Schlyter)
Peekboo V2 (Tom St Denis)
Not Quite Identity-Based RSA Variant (John Savard)
Re: BBS ("Michael Scott")
Re: Simple newbie crypto algorithmn (SCOTT19U.ZIP_GUY)
Re: Deciphering without knowing the algorithm? (CLSV)
Re: Deciphering without knowing the algorithm? ("Steve Feldman")
More idiot "security problems" (Eric Lee Green)
Re: Simple newbie crypto algorithmn (Johnny Bravo)
Re: Q: BBS ("Baruch Even")
Re: Q: BBS (Tim Tyler)
Re: Deciphering without knowing the algorithm? (drickel)
Re: Prime series instead (Re: Pi) (SDpikachu)
Re: Q: BBS (Mok-Kong Shen)
Re: Q: BBS (Mok-Kong Shen)
Re: Invitation to our homepage (Keith A Monahan)
Edgar Allan Poe Crypto Challenge. ("DM")
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: BBS
Date: Thu, 16 Dec 1999 19:34:20 +0100
The present question stems from a follow-up of mine in another thread.
The interation underlying BBS:
X_(i+1) = (x_i)^2 mod n
ultimately cycles. From any seed X_0 there may be an initial
unrepeated segment in the sequence generated, but after that it
goes into a loop. It is trivial to see the existence of such loops.
An element belonging to a loop of length 2 satisfies
x^4 = x mod n
Generally, an element belonging to a loop of length m satisfies
x^(2^m) = x mod n
Question: Does this signify anything to the security offered by BBS?
M. K. Shen
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Q: BBS
Date: 16 Dec 1999 18:43:33 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Question: Does this signify anything to the security offered by BBS?
Well, if you start over in a cycle, you will output the same bits,
and this will be bad. So you should know how long the cycle is for your
particular instance of the generator. The last part of the BBS paper
covers methods for determining parameters which yield maximum-length
cycles. Terry Ritter also has an article in Cryptologia (?) and some
discussion on his web page as to how to determine the cycle length
of given parameters.
It's an interesting kind of problem - if you implement a BBS in say,
Scheme, and keep iterating it, you can actually play with a lot of
different parameters and notice that some work and some don't. and you can
notice that if n isn't a blum integer, then your least sig bit is not
particularly random at all...
-David
--
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Deciphering without knowing the algorithm?
Date: 16 Dec 1999 19:02:45 +0100
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
> "SCOTT19U.ZIP_GUY" wrote:
>
>> I know enough to know that you don't understand C "very"
>> well if you can't follow a simple C program.
>
> Have you ever seen the winners of the obfuscated C
> programming contest? Those are small and simple programs.
> Yet they are really hard to read.
These programs are far from typical small and simple C
programs. The authors have deliberately abused C as much as
they can, in order to make the code as unreadable as possible
(that's what the contest is about).
--
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Peekboo V2
Date: Thu, 16 Dec 1999 19:09:32 GMT
Well V2 is out... some of the additions/changes include the chat
client, new layout, new session key construction, slightly easier to
follow source code etc..
In case you don't know, peekboo is my free Win95/98/NT Cryptographic
Toolset.
You can check it out on the web at
http://www.cell2000.net/security/peekboo/index.html
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Not Quite Identity-Based RSA Variant
Date: Thu, 16 Dec 1999 12:29:38 GMT
It would seem that the security of RSA would not be decreased if,
after choosing one prime, I chose the second prime so that the
product, a very long number, began with a string giving my identity.
If so, I see a possible "benefit"; since the moduli starting with such
a string are a subset of possible moduli, there would be fewer
possible moduli having a given checksum.
Of course, that won't _really_ provide any benefit in security, at
least not one I can see - a restricted search for collisions will turn
up results as quickly as an unrestricted one, so key certificates
aren't improved. But perhaps the
Cryptography-Digest Digest #751
Cryptography-Digest Digest #751, Volume #10 Thu, 16 Dec 99 21:13:01 EST
Contents:
Re: Keystrokes monitored/encryption useless (Keith A Monahan)
Re: Deciphering without knowing the algorithm? ("Trevor Jackson, III")
Re: Deciphering without knowing the algorithm? ("Trevor Jackson, III")
I was just thinking about a potential Cipher system... ("Pipian")
Re: Better encryption? PGP or Blowfish? (Derek Bell)
8192bit Encrypt - Easy ! ("Glen Bridgland")
Re: More idiot "security problems" (Xcott Craver)
Re: Simple newbie crypto algorithmn ("Douglas A. Gwyn")
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: Q: BBS ("Baruch Even")
Re: More idiot "security problems" ("Trevor Jackson, III")
Re: Keystrokes monitored/encryption useless (Bauerda)
Re: More idiot "security problems" (David Wagner)
Re: 8192bit Encrypt - Easy ! (Eli Akronym)
Enigma - theoretical question (Neil Bell)
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Keystrokes monitored/encryption useless
Date: 16 Dec 1999 22:13:17 GMT
Yeah,
DIRT has been around for quite some time. I remember reading about
it awhile back. I went to the manufacturer's web page(I forget who)
and they had phrases like, "only available to law enforcement" and
"please fax proof of being a LEA prior to asking for additional
information" and blah blah blah.
First off, if they think they can prevent some pirate from distributing
DIRT around to everyone and their brother, they are crazy. I can't
beleive I haven't seen a pirated copy yet. Perhaps I'll take a look :)
I'm sure they are charging an arm and a leg for this software which
was pretty easy to write.
I protect myself using AtGuard which is really an awesome firewall
software for windows. It allows you to log all connections, approve/deny
each connection and so forth. I review the logs on a (somewhat) periodic
basis looking for any funny sitenames/ip's, etc.
Well. http://www.atguard.com just shows me something that may not benefit
end users, but
WRQ, Inc. has licensed AtGuard to Symantec
Corporation and ASCII Network Technology.
WRQ discontinued sales of AtGuard to individual users
on November 22, 1999.
WRQ will stop supporting the AtGuard product on
December 22, 1999.
On December 22, the AtGuard web site and the
AtGuard Forum will close.
Symantec will offer the AtGuard technology as part of
Norton Internet Security 2000.
Keith
molypoly ([EMAIL PROTECTED]) wrote:
: Take a look at the latest article from Privacytimes.com at
: http://www.privacytimes.com/dirt_8_17.htm
: The program is called DIRT and it records all your keystrokes. When
: you're online, it sends them to the receipient.
: This means that your keystrokes made while making your encryption
: keys are now worthless! How would one get around this if this software
: got into the wrong hands?
: Sent via Deja.com http://www.deja.com/
: Before you buy.
--
Date: Thu, 16 Dec 1999 17:54:45 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
>
> > "SCOTT19U.ZIP_GUY" wrote:
> >
> >> I know enough to know that you don't understand C "very"
> >> well if you can't follow a simple C program.
> >
> > Have you ever seen the winners of the obfuscated C
> > programming contest? Those are small and simple programs.
> > Yet they are really hard to read.
>
> These programs are far from typical small and simple C
> programs. The authors have deliberately abused C as much as
> they can, in order to make the code as unreadable as possible
> (that's what the contest is about).
Last time I looked the limit on entries to the contest was 2048
characters. That's pretty small by most standards. Now as for simple,
one of the figures of merit for an obfuscated program is the ratio of the
complexity of code over the complexity of the job it does. The simple
the job the better.
N.B. Scott's code exhibits the classic wholistic doctrine that one cannot
infer the operation of the assembly from inspection of the parts. No
amout of reading the code he generated will allow you to deduce his
intentions at the time he wrote the code. This is why his referrals to
"read the code" and attacks upon others programming skill fall on deaf
ears. His position is not defensible.
--
Date: Thu, 16 Dec 1999 17:57:05 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Steve Feldman w
Cryptography-Digest Digest #752
Cryptography-Digest Digest #752, Volume #10 Fri, 17 Dec 99 05:13:00 EST
Contents:
Re: 8192bit Encrypt - Easy ! (CLSV)
Re: Not Quite Identity-Based RSA Variant ("karl malbrain")
Re: 8192bit Encrypt - Easy ! (Raphael Phan Chung Wei)
Re: Why no 3des for AES candidacy (Jerry Coffin)
Re: 8192bit Encrypt - Easy ! (Tom St Denis)
Re: Cryptanalysis (Scott Fluhrer)
Re: The Code Book (David Hopwood)
Re: Deciphering without knowing the algorithm? (wtshaw)
US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
Re: Keystrokes monitored/encryption useless (Johnny Bravo)
ARC4 cipher... ("Andrej Madliak")
Re: BBS (Mok-Kong Shen)
Re: Non-linear PRNGs (Mok-Kong Shen)
Re: 8192bit Encrypt - Easy ! (Johnny Bravo)
Re: Deciphering without knowing the algorithm? ("Douglas A. Gwyn")
Re: I was just thinking about a potential Cipher system... ("Douglas A. Gwyn")
Re: 8192bit Encrypt - Easy ! ("Douglas A. Gwyn")
Re: More idiot "security problems" (Xcott Craver)
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 02:26:59 +
Glen Bridgland wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption along
> with a host of features.
> It Can be Reviewed at http://www.glen-bridgland.co.uk/Project/Crypt.htm
> Please read the document and express your thoughts.
[Please read the FAQ, please read the FAQ, please read the FAQ.]
[It is at
http://www.cis.ohio-state.edu/hypertext/faq/bngusenet/sci/crypt/top.html]
Ok, having thought all that I am a bit curious about Nanosim.
What is the algorithm?
- CLSV
--
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Not Quite Identity-Based RSA Variant
Date: Thu, 16 Dec 1999 19:07:18 -0800
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It would seem that the security of RSA would not be decreased if,
> after choosing one prime, I chose the second prime so that the
> product, a very long number, began with a string giving my identity.
Of course this approach is just a BACKWARD version of the current method --
taking the product AS your identity. What is wrong with this, anyway. Karl
M
--
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 11:09:06 +0800
Hey Glen, your links are broken
Glen Bridgland wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption along
> with a host of features.
>
> It Can be Reviewed at http://www.glen-bridgland.co.uk/Project/Crypt.htm
>
> Please read the document and express your thoughts.
>
> Thanks - Glen.
--
Regards,
Raphael Phan
Faculty of Engineering
Multimedia University
+603-83125314
--
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Why no 3des for AES candidacy
Date: Thu, 16 Dec 1999 20:48:41 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... why 3DES isn't be considered as part of AES ]
> Because NSA can't break triple DES. In other word, NSA wish to be AES as
> breakable cipher.
How does this make any sense? Keep in mind that 3DES is already in
fairly wide use, and will be standardized in FIPS 46-3 long BEFORE the
work on AES is finished...
--
Later,
Jerry.
The universe is a figment of its own imagination.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 8192bit Encrypt - Easy !
Date: Fri, 17 Dec 1999 03:57:19 GMT
In article <83bv1d$i9$[EMAIL PROTECTED]>,
"Glen Bridgland" <[EMAIL PROTECTED]> wrote:
> Hi, I new to the group however, I hope to be sharing a lot with the
Users
> here over the next few months as I finalise my Project. I am current
> developing an encryption program that will offer 8192bit Encryption
along
> with a host of features.
Here is my response.
DO NOT SPAM THIS GROUP YOU DARN NEWBIE.
Also what the heck is 8192bit symmetric keys need for anyways?
Oh btw
http://www.pgpi.com
and
http://www.cell2000.net/security/peekboo/index.html
and
http://www.pgp.com
and
http://www.scramdisk.clara.net
and
...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis
Date: Fri, 17 Dec 1999 05:46:49 GMT
In article <83arld$2ga4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>In article <839t3o$96d$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>>I'm doing a paper on Cryptography and It's Affect On Th
Cryptography-Digest Digest #753
Cryptography-Digest Digest #753, Volume #10 Fri, 17 Dec 99 10:13:01 EST
Contents:
Re: More idiot "security problems" (Xcott Craver)
Re: Keystrokes monitored/encryption useless ([EMAIL PROTECTED])
Re: ARC4 cipher... (Pelle Evensen)
Reducing Key Sizes ("Adam Pridmore")
Re: Enigma - theoretical question (John Savard)
Breaking a cipher. ("jim")
Euclid Algorithm ("Miryadi")
Re: The Cracking of SecurityPlus! 4.32 (Paul Crowley)
Re: Ellison/Schneier article on Risks of PKI ([EMAIL PROTECTED])
DES key safety ("Tom Pedersen")
Re: 8192bit Encrypt - Easy ! (SCOTT19U.ZIP_GUY)
Re: Keystrokes monitored/encryption useless (SCOTT19U.ZIP_GUY)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Cryptanalysis (SCOTT19U.ZIP_GUY)
Re: More idiot "security problems" (SCOTT19U.ZIP_GUY)
Re: Reducing Key Sizes (SCOTT19U.ZIP_GUY)
Re: Off topic -- 4 year old (Michael Groh)
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 17 Dec 1999 10:26:17 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
>Xcott Craver <[EMAIL PROTECTED]> wrote:
>I like Bruce Schneier's sound byte: "Kindergarten Crypto".
>I think that conveys the essence especially nicely...
The problem with this is, sadly, that the term was used to
describe an attempt at crypto which was many notches above this.
MicroSoft may have messed up their protocols, but at least
they picked strong cryptosystems as building blocks.
If what MicroSoft did was "Kindergarten Crypto," then this
is ... "toddler" crypto? "Embryo" crypto? "Glint in the
milkman's eye" crypto?
But I was looking for the more general term for a coder
developing a hilariously awful algorithm for a basic problem
that can only come from (a) complete ignorance of existing
algorithms; (b) the arrogance to not bother to pick up a book,
and sometimes (like our alt.2600 visitor) enough arrogance
to assume that their first attempt is a world-beater;
(c) the lack of some general common sense about the speed of
computers---what's "slow," what's "fast," what's a "large number";
and (d) the ethical numbness to put the technology in something
human beings will use.
A term which combines the false sense of expertise, the
amazing cluelessness, and the danger to others. Like a manager
of a hardware superstore who never heard of firebrick
(fireproof stuff you use as a work surface for welding), but
tells you to try some of this galvanized sheet metal instead.
-Scott
--
From: [EMAIL PROTECTED]
Subject: Re: Keystrokes monitored/encryption useless
Date: Fri, 17 Dec 1999 11:17:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> On 16 Dec 1999 22:13:17 GMT, [EMAIL PROTECTED] (Keith A Monahan)
> wrote:
>
> >First off, if they think they can prevent some pirate from
distributing
> >DIRT around to everyone and their brother, they are crazy. I can't
> >beleive I haven't seen a pirated copy yet. Perhaps I'll take a look
:)
>
While I hate to add to a thread that really belongs in alt.privacy, no
one seems to be complaining :-)
I think the best joke on uncle sam would be, the first person to
capture this code - anonamously post it to somewhere like alt.privacy
and if you can, post a patch to trace where it was supposed to send its
info. Seems turnabout is only fair :-)
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Pelle Evensen)
Subject: Re: ARC4 cipher...
Date: 17 Dec 1999 11:55:04 GMT
Andrej Madliak ([EMAIL PROTECTED]) wrote:
: Hi!
: Has anybody heard of
: ARC4 stream cipher (w/128-bit key) and/or about its security and
: attacks against it?
It's "Alleged RC4", something that seemingly behaves identically to
RSA's RC4 stream cipher.
http://burtleburtle.net/bob/rand/isaac.html
Source and more comments can be found here;
ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/rc4/
/Pell
--
From: "Adam Pridmore" <[EMAIL PROTECTED]>
Subject: Reducing Key Sizes
Date: Fri, 17 Dec 1999 12:13:33 -
Does anyone know if there are any security issues in symmetric algorithms if
the key size is reduced (eg making the last x bits of the key constant),
other than reducing the number of available keys. (ie Brute force is still
the easiest way to break it).
Could this be very dependant on the algorithm chosen?
TIA
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma - theoretical question
Date: Fri, 17 Dec 1999 12:16:54 GMT
On Thu, 16 Dec 1999 17:59:37 -0800, Neil Bell <[EMAIL PROTECTED]>
wrote:
>Would this be a reasonably
Cryptography-Digest Digest #754
Cryptography-Digest Digest #754, Volume #10 Fri, 17 Dec 99 13:13:01 EST Contents: Re: 8192bit Encrypt - Easy ! (Adam Lock) Cryptologia journal ([EMAIL PROTECTED]) Re: Breaking a cipher. (John Savard) Re: Keystrokes monitored/encryption useless (CLSV) Re: Cryptologia journal (David A Molnar) Re: More idiot "security problems" (Eric Lee Green) Re: Breaking a cipher. (Keith A Monahan) Re: Keystrokes monitored/encryption useless (Guy Macon) Re: Reducing Key Sizes (Tom St Denis) Re: Questions about message digest functions (Tim Tyler) Re: More idiot "security problems" (Jerry Coffin) Re: More idiot "security problems" (Jeff Williams) Re: Breaking a cipher. (Tom St Denis) First step in finding primes (Tom St Denis) Re: The Cracking of SecurityPlus! 4.32 (Troed) Re: DES key safety (Jerry Coffin) Re: First step in finding primes (Scott Fluhrer) Re: First step in finding primes (Tom St Denis) From: Adam Lock <[EMAIL PROTECTED]> Subject: Re: 8192bit Encrypt - Easy ! Date: Fri, 17 Dec 1999 15:21:29 + Glen Bridgland wrote: > Hi, I new to the group however, I hope to be sharing a lot with the Users > here over the next few months as I finalise my Project. I am current > developing an encryption program that will offer 8192bit Encryption along > with a host of features. 8192bit encryption is only any use for someone prepared to remember a 1024 byte or greater key. -- Adam Lock -- From: [EMAIL PROTECTED] Subject: Cryptologia journal Date: Fri, 17 Dec 1999 15:26:57 GMT I would like to acquire all back issues of Cryptologia, but I cannot afford the $ 12.00 per piece§ ! And a good number is out-of-print. Is there someone that would have them available ? Thanks Jean Sent via Deja.com http://www.deja.com/ Before you buy. -- From: [EMAIL PROTECTED] (John Savard) Subject: Re: Breaking a cipher. Date: Fri, 17 Dec 1999 08:51:12 GMT "jim" <[EMAIL PROTECTED]> wrote, in part: >I'm only a newbie to the world of cryptography and I was wodering about >breaking a cipher. Is it a hard task, Yes, it is, because >or is it just reversing the cipher >and using as many keys as possible? if the cipher is any good, there are too many keys to try for this to be a sensible way to try and break it. (However, it is also true that "if the cipher is any good", this should be the only way left, because there should not be any cryptanalytic weaknesses.) John Savard (jsavardecnabca) http://www.ecn.ab.ca/~jsavard/crypto.htm -- From: CLSV <[EMAIL PROTECTED]> Subject: Re: Keystrokes monitored/encryption useless Date: Fri, 17 Dec 1999 15:53:17 + "SCOTT19U.ZIP_GUY" wrote: > [EMAIL PROTECTED] (Bauerda) wrote: > > [..] Before I upgraded to Windows, I had my startup files set so that they traced a > "upgraded to Windows" if this is nat a bastardtisetion of the English > language I don't know what is. :-) Wow, this lack of beer as you mentioned earlier is a very positive thing. Regards, CLSV -- From: David A Molnar <[EMAIL PROTECTED]> Subject: Re: Cryptologia journal Date: 17 Dec 1999 15:57:05 GMT [EMAIL PROTECTED] wrote: > And a good number is out-of-print. > Is there someone that would have them available ? You might try looking for libraries in your area. A local library should have the resources to search for the nearest archive. Plus they may be able to get a specific issue for you via inter-library loan. If you search on the Web, you should be able to find the tables of contents; this may help you pick out the issues you want. Good luck, -David Molnar -- From: Eric Lee Green <[EMAIL PROTECTED]> Subject: Re: More idiot "security problems" Date: Fri, 17 Dec 1999 09:09:56 -0700 Xcott Craver wrote: > Eric Lee Green <[EMAIL PROTECTED]> wrote: > >Let's get this straight. Those passwords are sent across the network IN PLAIN > >TEXT every time that the user logs into an IMAP or POP3 EMAIL server, and you > >can but this "security expert" at "Reliable Software Technologies Corp." > >(hmm, is this a one-man outfit?) doesn't ever mention that, instead focusing > >on how the keys are stored in the registry? > > Firstly, the way the keys are stored in the registry allow the > passwords to be stolen even if you never use your IMAP or POP3 > account. True Story: Once upon a time, in a land far far away, I was one of those kids who stripped copy protection off of games. I was irritated that I couldn't run games off of a decent disk drive and instead was stuck running them off of slow floppy drives that the copy protection always made bang and burp and run like crud. I'm talking about, some games that would load in 10 seconds off of a hard drive took THREE MINUTES to load off of floppy! Game makers tried all kinds of tricks t
Cryptography-Digest Digest #755
Cryptography-Digest Digest #755, Volume #10 Fri, 17 Dec 99 14:13:02 EST
Contents:
Re: Questions about message digest functions (James Felling)
Re: I was just thinking about a potential Cipher system... (John Savard)
Re: DES key safety (John Savard)
Re: Enigma - theoretical question (UBCHI2)
The 20 years periods did apply to 2 of the 3 patents. Why not for RSA ?
([EMAIL PROTECTED])
Re: ARC4 cipher... ("r.e.s.")
Re: Off topic -- 4 year old (Keith A Monahan)
Re: Euclid Algorithm (Medical Electronics Lab)
Re: ARC4 cipher... (John Savard)
Re: Cryptologia journal (John Savard)
Re: More idiot "security problems" (Xcott Craver)
Re: US Patent Office: How Stupid? Look Here... (Paul Koning)
Re: ARC4 cipher... (Paul Koning)
Re: More idiot "security problems" (JPeschel)
Re: First step in finding primes (Keith A Monahan)
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Date: Fri, 17 Dec 1999 11:45:59 -0600
Tim Tyler wrote:
> James Felling <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> wtshaw <[EMAIL PROTECTED]> wrote:
> :> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> :> :> wtshaw <[EMAIL PROTECTED]> wrote:
>
> :> : Since you asked, I resolve a portion of my comment: collisions and
> :> : security of a hash function work in opposition, no collisions meaning
> :> : that the input can be solved, be that perhaps inconvenient. But, if
> :> : lots rode on the solution, it might be worth it.
>
> :> Surely collision resistance and security are generally positively
> :> connected - rather than negatively.
>
> : Simply put, in a hash both are desirable properties.
>
> Yes, indeed.
>
> : Ideally youur hash should be as collision resistant as possible. Ideally
> : it should also be resistant to being worked backward (if every message
> : has a unique hash this can be a problem as far as keeping the messages
> : secure).
>
> Can it? How?
>
> This can only happen if hash-size = message size. The alternative is to
> give some messages the same hash as one another. This makes little
> difference to the ability to locate the hash for any given message, but
> makes collisions infinitely more probable :-(
If Hashsize>=message size.
>
>
>
> : However, pursuing any one of them is a bad thing.
>
> /How/ is pursuing collision resistance a bad thing?
Pursuing any one of them to the exclusion of the other is a bad thing. ( I
should have added that qualifier for clarity)
>
>
> *Ignoring* the difficulty of reversing the hash /would/ be a bad thing.
> But "one-way"ness does not require increased probability of hash
> collisions as far as I can see.
>
> : XORing the message with a fixed key/ permuting it with a fixed permutation
> : is completely resistant to collision [...]
>
> This is only possible if hash size = message size, of course.
If messagesize>hash size then treat hash(block1) as the key. By completely
resistant I mean that it is as resistant to collision as it is possible to be
for a hash of that size.
>
>
> [...] but is horribly insecure [...]
>
> Yes. For one thing, this is not a one-way function.
>
> : [...] and maping all values to 1 of 4 values is very resistant to being
> : worked backward [...]
>
> No. It's likely to be trivial to "work backwards":
>
> Validate the hashes on a few messages - until the values of all four
> hashes are known.
>
> Then append these four hashes in turn to your target message. One of them
> will validate as being correct. You don't need the private information
> about the primes (or whatever) that are used to generate the hash in order
> to be able to do this.
Accepted -- though this attack is equivalent to for an n bit hash append all 2^N
possible hashes to the message and see which one works. In addition if you are
given two messages, both of which hash to value #4 which message was the valid
one?
>
>
> This attack can be applied in a large number of the cases where hashes are
> applied in practice.
>
> : One must seek to maximize both and remain aware that when it gets down
> : to it, there are tradeoffs that must occur.
>
> Tradeoffs are not required. Collision resistance and security do not
> pull in opposed directions.
They do indeed, it is simply that if one posseses a very good hash that manages
a high level of both, it is hard to improve one without hurting the other.
>
>
> I'll qualify this. Look at the attack that minimal collision-resistance
> leads to in the case when message size = hash size:
>
> Having a message (of the same length as the hash) with a correct hash
> gives the attacker information that no other messages (again of the same
> length of the hash) do not have this hash.
>
> The attacker would not have this information if the hash simulated a
> genuinely random function.
>
> This attack /could/ conceivably lead somewhere if most possible
> messages of that length had ha
Cryptography-Digest Digest #756
Cryptography-Digest Digest #756, Volume #10 Fri, 17 Dec 99 15:13:01 EST
Contents:
Re: More idiot "security problems" (Xcott Craver)
Re: Keystrokes monitored/encryption useless (Stefek Zaba)
Re: Deciphering without knowing the algorithm? (Derek Bell)
Re: Euclid Algorithm ("Dann Corbit")
Re: More idiot "security problems" (Xcott Craver)
Re: More idiot "security problems" (SCOTT19U.ZIP_GUY)
Re: I was just thinking about a potential Cipher system... (Derek Bell)
Re: Keystrokes monitored/encryption useless (Liyang Hu)
Re: Off topic -- 4 year old (Liyang Hu)
Re: Keystrokes monitored/encryption useless (Johnny Bravo)
Re: Keystrokes monitored/encryption useless (Johnny Bravo)
Re: More idiot "security problems" (JPeschel)
Re: More idiot "security problems" (Johnny Bravo)
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 17 Dec 1999 19:06:14 GMT
Jeff Williams <[EMAIL PROTECTED]> wrote:
>
>Convenience does seem to be more important to Joe Average than security.
>Perhaps we need to modify the system from the ground up, so that security is
>not only built in, but transparent (or as close to transparent as possible).
>Those aspects which cannot be transparent need to be arranged such that
>they cannot be disabled or bypassed.
Luckily (?) for us, it is often the case that those non-transparent,
annoying, often-bypassed security measures could have been avoided.
Often they are there because something better could have been
implemented but wasn't, leaving a huge gaping hole that can only
be locked down completely, or at least with a disclaimer of liability
("You are about to enter the Internet. From this point on, it's
your ass. Continue? [Yes] [No]")
It is true, however, that people will want features which will
be misusable, and there's little we can do to tell them no. Any
Sufficiently cool software technology is almost surely adaptable to
destructive ends (Craver's first law of computer security:
Fireworks are made out of Gunpowder. :P )
>Jeff
-Xcott
--
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: Keystrokes monitored/encryption useless
Date: Fri, 17 Dec 1999 19:06:47 GMT
In sci.crypt, Bauerda ([EMAIL PROTECTED]) wrote:
> Before I upgraded to Windows, I had my startup files set so that they traced a
> few interrupts (DOS, disk access, and keyboard) and checked most of the
> interrupt table against stored results. While this is harder under Windows, it
> is still relatively easy to get a program which looks at the devices and
> threads running (hidden or not).
Sussing which threads are running can help, but will only detect whole new
threads, not modifications to the code being executed by the "standard"
Windows handlers. Similarly, knowing that some piece of malware has not
hooked a particular low-level interrupt is nice, but doesn't tell you that
the "normal" interrupt routine, or any of the "standard" DLLs/VXDs, is
unmodified. For that you need hashes of the trusted versions (and why do
you trust the shipped versions anyway?), a non-modifiable store of the
hashes and the hash-computation code, and non-bypassable alerting when
the hash check fails.
Stefek
--
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: 17 Dec 1999 19:16:37 -
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Yes I know not all the good cryptoheads live in the US
: but what makes you think the NSA would not kill or silence
: them if they are precieved as a threat. I though just this last
: year there was a strange death of a European expert.
If you mean Boris Floriciz, the case is still open - if it turns out
to be homicide, there are *many* possible suspects, including cable pirates.
Derek
--
Derek Bell [EMAIL PROTECTED]| Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html|usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc |- [EMAIL PROTECTED]
--
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Euclid Algorithm
Date: Fri, 17 Dec 1999 11:28:20 -0800
Here is one I wrote. It should be easy to transform it into a C++ template
so that you can use it with extended precision types.
/*/
/* This function uses the Euclidean Algorithm to */
/* calculate the greatest common divisor of two */
/* unsigned long integers. */
/*/
/* Programmer: Danniel R. Corbit */
/* */
/* Copyright (C) 1992 by Dannie
Cryptography-Digest Digest #757
Cryptography-Digest Digest #757, Volume #10 Fri, 17 Dec 99 18:13:01 EST
Contents:
Re: Enigma - theoretical question (Johnny Bravo)
Re: The 20 years periods did apply to 2 of the 3 patents. Why not for RSA ? (wtshaw)
Re: I was just thinking about a potential Cipher system... (Jim)
Re: Enigma - theoretical question (Jim)
Re: DES key safety (Scott Nelson)
SHA-1 hash (was Re: ARC4 cipher...) ("Andrej Madliak")
Re: More idiot "security problems" (Eric Lee Green)
Re: More idiot "security problems" (Eric Lee Green)
Re: First step in finding primes (Johnny Bravo)
Re: Are thermal diodes as RNG's secure (Bill Unruh)
Re: I was just thinking about a potential Cipher system... (SCOTT19U.ZIP_GUY)
Re: Reducing Key Sizes (Scott Nelson)
Re: Skytale? (UBCHI2)
Re: discrete logorithm reduction to factoring (Bill Unruh)
RSA, how to calculate big numbers ("Bart Peeters")
Re: discrete logorithm reduction to factoring (DJohn37050)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Breaking a cipher. ("Markus Eiber")
Re: RSA, how to calculate big numbers ("Markus Eiber")
Re: First step in finding primes (Eric Bach)
DES as pseudo random number generator ("Markus Eiber")
Re: discrete logorithm reduction to factoring (Jerry Coffin)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Enigma - theoretical question
Date: Fri, 17 Dec 1999 15:10:48 GMT
On 17 Dec 1999 17:53:22 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>If you are going to use the enigma software that you can download off the
>internet, you should rewire the rotors to a custom pattern. The wiring of the
>rotors can be an important secret.
Given that and the other conditions he used above, like not putting
three test letters repeated twice at the start of every message, and
not putting known plain text at the start of every message, it should
be pretty secure for short messages. Much more secure than the actual
Enigma as the Germans used it, since they broke all the above rules on
a regular basis.
Best Wishes,
Johnny Bravo
--
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. Why not for RSA ?
Date: Fri, 17 Dec 1999 14:29:22 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> The 3 most known patents in the encryption area are :
>
> Name Number Filed Expires
>
> Diffie-Hellman 4,200,770 Sept. 6, 1977 Sept. 6, 1997
> Hellman-Merkle 4,218,582 Oct. 6, 1977Oct. 6, 1997
> RSA 4,405,829 Dec. 14, 1977 Sept. 20, 2000
>
> The 20 years periods did apply to 2 of the 3 patents.
> Why it is not applicable to the last one ?
*Contributions*
--
Pbashgngvf znyrqvpgvf, synzzvf npevohf nqqvpgvf.
--
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: I was just thinking about a potential Cipher system...
Date: Fri, 17 Dec 1999 20:22:58 GMT
Reply-To: Jim
On Thu, 16 Dec 1999 17:22:51 -0600, "Pipian" <[EMAIL PROTECTED]> wrote:
>I was thinking that a polymorphic cipher would be fairly secure (well it's
>the same as a one-time pad, I guess) when I came upon an idea...
>
>How secure would a cipher like this be?
>
>There would be 26 Enigma-like mechanisms, theoretically labeled A-Z...
>According to a certain keyword/words, you would switch between the machines
>containing the letters of the keyword... (Sounds similar to a Vigenere
>cipher on top of Enigma) This, I would think, would be fairly secure, but
>which of these methods for rotation of the scramblers would be most secure?
>Rotation of scramblers in all machines when one letter is encoded? Or
>rotation only on the machine the letter is encoded on?
Don't think you'd need to do this. The Enigma machine is secure enough
if you change the rotor wiring, plugboard, ringstelle and rotor start
positions with each message. Extremely easy to do with a PC!
--
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Enigma - theoretical question
Date: Fri, 17 Dec 1999 20:22:58 GMT
Reply-To: Jim
On 17 Dec 1999 17:53:22 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>If you are going to use the enigma software that you can download off the
>internet, you should rewire the rotors to a custom pattern. The wiring of the
>rotors can be an important secret.
Yes. But surely with a computer you can change the rotor wirings
at intervals, or even with each message?
Don't forget to change the plugboard too!
It's secure enough for the stated purpose, if a bit cumbersome.
--
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: DES key safety
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Dec 1999 20:27:23 GMT
On Fri, 17 Dec 1999 "Tom Pedersen" <[EMAIL PROTECTE
Cryptography-Digest Digest #758
Cryptography-Digest Digest #758, Volume #10 Fri, 17 Dec 99 20:13:01 EST
Contents:
Re: DES as pseudo random number generator (Tim Tyler)
Re: RSA, how to calculate big numbers (Ian Wehrman)
Re: Questions about message digest functions (Tim Tyler)
Microsoft- PKI/E-comm Director Opening ([EMAIL PROTECTED])
Re: Reducing Key Sizes (Keith A Monahan)
Re: ARC4 cipher... (Bill Unruh)
Re: RSA, how to calculate big numbers ([EMAIL PROTECTED])
Re: RSA, how to calculate big numbers ("Dann Corbit")
Re: Deciphering without knowing the algorithm? ("Rick Braddam")
Re: Q: BBS (Terry Ritter)
Re: BBS (Terry Ritter)
Re: Euclid Algorithm ("Miryadi")
Re: RSA, how to calculate big numbers ([EMAIL PROTECTED])
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Dec 1999 23:12:04 GMT
Markus Eiber <[EMAIL PROTECTED]> wrote:
: As you know one-time-pad is a cipher with perfect secrecy.
: How about a one-time-pad using a DES generated pseudo random number
: sequence?
[...]
: The seed and DES key will be transmitted secure to the recipiant of the
: message and he may decrypt the message after creating the identical pseudo
: random number sequence by adding it to the cipher.
: The security of this cipher depends only on the quality of the pseudo random
: number sequence.
: How secure is it?
About the same as DES used in OFB mode ;-)
OFB is not generally the most secure DES mode. For example, most
DES modes diffuse plaintext information over an entire block. OFB mode
does not diffuse the plaintext information at all.
In other words, it is vulnerable to governmental DES crackers everywhere ;-)
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Never eat anything bigger than your head.
--
From: Ian Wehrman <[EMAIL PROTECTED]>
Subject: Re: RSA, how to calculate big numbers
Date: Fri, 17 Dec 1999 17:34:03 -0600
get on a unix machine, use 'bc'
later,
ian
Bart Peeters wrote:
>
> I have to calculate:
>
> (32567023914^367151)%437
>
> How can I do that?
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Dec 1999 23:32:41 GMT
James Felling <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> James Felling <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
A hash with only four used values?]
:> : [...] and maping all values to 1 of 4 values is very resistant to being
:> : worked backward [...]
:>
:> No. It's likely to be trivial to "work backwards":
:>
:> Validate the hashes on a few messages - until the values of all four
:> hashes are known.
:>
:> Then append these four hashes in turn to your target message. One of them
:> will validate as being correct. You don't need the private information
:> about the primes (or whatever) that are used to generate the hash in order
:> to be able to do this.
: Accepted -- though this attack is equivalent to for an n bit hash append
: all 2^N possible hashes to the message and see which one works.
Hang on. I thought you said there were only 4 hash values. Do you
also mean the hash is only two bits long?? If so, why would reverse
engineering the hash be *at all* difficult?
I've been assuming the hashes under discussion are suitable for use in
signing or validating messages - i.e that it is a one-way hash function
which can be generated with a private key, but validated with a publicly
available one.
Your comments don't make much sense in this context. I presume you are
thinking about a hash which is used for something else, and is not
suitable for validating messages?
: In addition if you are given two messages, both of which hash to value
: #4 which message was the valid one?
With a 2-bit hash (or effectively a hash with only two bits of
information), forging messages is pretty trivial - even if the attacker is
just guessing hashes he will succeed about 1 time in 4. Such a scheme
offers precious little security - I'm not sure why it is being discussed.
:> : One must seek to maximize both and remain aware that when it gets down
:> : to it, there are tradeoffs that must occur.
:>
:> Tradeoffs are not required. Collision resistance and security do not
:> pull in opposed directions.
: They do indeed, it is simply that if one posseses a very good hash that
: manages a high level of both, it is hard to improve one without hurting
: the other.
You're talking about practical issues in designing hash functions?
Such difficulties don't appear to exist in principle. A hash function
should be as haerd as possible to reverse, and as resiliant to hash
collisions as is possible, and you /can/ do both at the same time.
If you are talking about engineering difficulties - rather than some
theoretical tradeoff - then it mig
Cryptography-Digest Digest #759
Cryptography-Digest Digest #759, Volume #10 Sat, 18 Dec 99 02:13:02 EST
Contents:
Re: discrete logorithm reduction to factoring (Bodo Moeller)
Re: discrete logorithm reduction to factoring (Bill Unruh)
Re: Euclid Algorithm (lordcow77)
Re: RSA, how to calculate big numbers (Michael J. Fromberger)
Re: Microsoft- PKI/E-comm Director Opening (David A Molnar)
Re: RSA, how to calculate big numbers ("Dann Corbit")
Re: Reducing Key Sizes (Scott Nelson)
Re: Ellison/Schneier article on Risks of PKI (Timothy M. Metzinger)
Re: ARC4 cipher... >> is symmetric stream cipher with UNLIMITED key
([EMAIL PROTECTED])
Re: Euclid Algorithm (Jerry Coffin)
Re: 8192bit Encrypt >> Snake Oil, another one. ([EMAIL PROTECTED])
Re: Microsoft- PKI/E-comm Director Opening (Keith A Monahan)
Re: Euclid Algorithm (Jerry Coffin)
Re: The 20 years periods did apply to 2 of the 3 patents. Why not for
([EMAIL PROTECTED])
Re: Euclid Algorithm ("Dann Corbit")
Re: DES as pseudo rng >> Do you have a key to decrypt "Never eat
([EMAIL PROTECTED])
Re: Euclid Algorithm ("Douglas A. Gwyn")
Re: DES key safety ("Douglas A. Gwyn")
From: [EMAIL PROTECTED] (Bodo Moeller)
Crossposted-To: comp.theory
Subject: Re: discrete logorithm reduction to factoring
Date: 18 Dec 1999 01:38:17 GMT
Bill Unruh <[EMAIL PROTECTED]>:
>> Is it true that discrete log reduces to factoring ?
[Apparently the question is meant the other way around: Can factoring
be reduced to DL; i.e. would an efficient DL algorithm allow us to
factor efficiently.]
> Yes. THis is the whole basis of Shor's quantum result in factoring. What
> Shor really did was to solve the discrete logs, and then show that this
> also solved factoring.
While you keep repeating this again and again, it's not true in any
relevant sense. More specifically, breaking DH modulo some prime p
only allows us to factor p, which isn't such a big deal really :-)
The Shor quantum algorithm for discrete logs works in groups (Z/nZ)*
with n composite or prime. Such general algorithms for DL can indeed
be used for factoring n, but there is no proof whatsoever that
algorithms for discrete logs in (Z/pZ)* with p prime are of any
help for factoring composite integers. (E.g. Pohlig-Hellman gives us
some information about discrete logs in (Z/pZ)*, at least one bit
when the base is a generator, but none for (Z/nZ)* where the
factorization of n is unknown.)
--
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: discrete logorithm reduction to factoring
Date: 18 Dec 1999 01:38:40 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (DJohn37050)
writes:
>My understanding that is that if you can solve DL, you can also solve IF. This
>means DL may be stronger than IF (or of equal strength). As if you can solve IF
>you may not be able to solve DL.
Went back to the Shor paper.
Given N, find r such that x^r=1 mod N (clearly this would be easily
solved if discrete logs could be easily solved) for random x. If r is
odd, try another x. If r is even, look at x^(r/2). If this is -1, find
another x. If this is not -1, then the gcd (x^(r/2),N) is a factor of N.
(And this is easily calculated).
He argues that the probability of getting a factor for random x is about
1/2. Thus the probablility of finding a factor gets arbitrarily near
one for not very many trials of x.
Thus an efficient discrete logs algorithm implies a probabilistically
efficient factoring algorithm.
--
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: Euclid Algorithm
Date: Fri, 17 Dec 1999 17:35:58 -0800
TAOCP is not just a crypto book. It is the definitive reference on
practically any algorithmic question. When somebody asks you a question
about algorithms, a pretty safe bet is to say that it's in Knuth's
book, because in all probability it will be.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: RSA, how to calculate big numbers
Date: 18 Dec 1999 02:12:44 GMT
In <8sA64.428$Zi.2380@client> "Dann Corbit" <[EMAIL PROTECTED]> writes:
>"Ian Wehrman" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> get on a unix machine, use 'bc'
>>
>> later,
>> ian
>>
>> Bart Peeters wrote:
>> >
>> > I have to calculate:
>> >
>> > (32567023914^367151)%437
>> >
>> > How can I do that?
>Did you actually try it? On my machine, it just pegs the CPU and sits
>there. I have a feeling BC would never complete this task.
>bc 1.04
>Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc.
>This is free software with ABSOLUTELY NO WARRANTY.
>For details type `warranty'.
>x = (32567023914^367151)%437
>It also seems to chow down more and more memory as it runs.
Cryptography-Digest Digest #760
Cryptography-Digest Digest #760, Volume #10 Sat, 18 Dec 99 07:13:00 EST
Contents:
Re: discrete logorithm reduction to factoring (David Wagner)
Re: Prime series instead (Re: Pi) ("Douglas A. Gwyn")
Re: DES as pseudo random number generator ("Douglas A. Gwyn")
Re: The Code Book
Re: discrete logorithm reduction to factoring (David Wagner)
Re: DES key safety (Paul Rubin)
Re: More idiot "security problems" ("Douglas A. Gwyn")
Re: DES key safety (David Wagner)
Re: DES key safety (David Wagner)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: More idiot "security problems" (Johnny Bravo)
Re: More idiot "security problems" (Johnny Bravo)
Re: More idiot "security problems" (Johnny Bravo)
Re: DES key safety ("Douglas A. Gwyn")
Re: ARC4 cipher... >> is symmetric stream cipher with UNLIMITED key length (Johnny
Bravo)
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: discrete logorithm reduction to factoring
Date: 17 Dec 1999 22:58:14 -0800
In article <83eoj0$a8$[EMAIL PROTECTED]>,
Bill Unruh <[EMAIL PROTECTED]> wrote:
> Thus an efficient discrete logs algorithm implies a probabilistically
> efficient factoring algorithm.
Be careful. This statement, while true if interpreted generously, is
likely to mislead many readers.
An efficient algorithm for discrete logs mod n implies an efficient
algorithm for factoring n.
But today's discrete log systems work mod p, a prime -- and an efficient
algorithm for discrete logs mod p implies NOTHING about factoring RSA
numbers like n. (So far as is known today, in the open literature.)
I could have sworn I explained this just a few days ago, here on sci.crypt.
I must not have done a very good job...
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Prime series instead (Re: Pi)
Date: Sat, 18 Dec 1999 07:00:45 GMT
Matthew Montchalin wrote:
> SDpikachu wrote:
> | Yes, but 1 isnt a prime,
> Unless we make it an honorary prime, like the 2 is an honorary prime.
2 is a genuine prime.
Whether or not 1 is considered a prime was determined by noting
that it was much more *useful* for it not to be so. Then the UFT
(for example) is much simpler to formulate.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Date: Sat, 18 Dec 1999 07:01:36 GMT
Markus Eiber wrote:
> As you know one-time-pad is a cipher with perfect secrecy.
> How about a one-time-pad using a DES generated pseudo random number
> sequence?
You contradict yourself.
--
From: <[EMAIL PROTECTED]>
Subject: Re: The Code Book
Date: Sat, 18 Dec 1999 07:06:45 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Warner wrote:
>>
>> The first sentence of Simon Singh's _The Code Book_ is, "On the morning
>> of Wednesday, 15 October 1586, Queen Mary entered the crowded courtroom
>> of Fotheringhay Castle". The calendars I have referred to give this date
>> as being on a Saturday. I'm interested in hearing comments on this
>> apparent inconsistency or references to such.
> Are you sure that the calendars you referred to are using Julian dates?
> (Most of Europe changed to the Gregorian calendar in 1582; Britain waited
> until 1753, IIRC.)
> - --
> David Hopwood <[EMAIL PROTECTED]>
> PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
> "Attempts to control the use of encryption technology are wrong in principle,
> unworkable in practice, and damaging to the long-term economic value of the
> information networks." -- UK Labour Party pre-election policy document
> -BEGIN PGP SIGNATURE-
> Version: 2.6.3i
> Charset: noconv
> iQEVAwUBOFnE1TkCAxeYt5gVAQFdbggAp1bWm5/K4YeXCHCvsRaWAP/nBlWMws8w
> DIvr1L+00Qb83f2rP+UZ6Q8KDw+j8E1sxB8ZPTiSSk9Hxbj9DAzcg3/xGLP/2qsA
> 8zWr/8Whwoc5sNgZoPrc9SgNCI8dWG76fh8UcvyD3dV9keULA30VjBjzwaMaq2EK
> CFsiniZd+xwfQn2NPeILkQeqKX5wO2RTjI59G9hqjs9vHEes9hVTRy+UhNXla3mw
> ARKdmZTxXJXqpGTCiR49Mus7aR95GtaObFwxupZ4ybkgagB1VjujbPBwXj8/noox
> t+yBepbhx45eUl2SUk4JCd/2ZTE5WLc7vkbLwOl++TWAGYrez3JHaA==
> =XxFC
> -END PGP SIGNATURE-
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: discrete logorithm reduction to factoring
Date: 17 Dec 1999 23:10:48 -0800
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
> My understanding that is that if you can solve DL, you can also solve IF.
This is true in some sense, but false in a much more important sense, as I
have explained in other posts to this forum.
Consequently, it may be highly misleading if you rely on it when choosing
a public key cryptosystem. If you weren't careful, you might conclude from
the above that
~ if you can
