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