Cryptography-Digest Digest #419, Volume #12 Fri, 11 Aug 00 15:13:01 EDT
Contents:
Re: Random Number Generator (tomstd)
Re: Secure Operating Systems (Mack)
Re: New version of scott16u and scott19u available (JPeschel)
Re: 1-time pad is not secure... (Mickey McInnis)
Re: Cross-platform secure chat (Ian Upright)
Re: Cross-platform secure chat ("Adam Smith")
Re: 1-time pad is not secure... ("Joseph Ashwood")
Re: Random Number Generator ("Joseph Ashwood")
Re: chap authentication scheme? (Cryptocol)
Re: Cross-platform secure chat ("Adam Smith")
Re: Explain S-boxes please ("Joseph Ashwood")
Re: Random Number Generator ("Joseph Ashwood")
obtaining RSA intemediate variables ("ajd")
Re: 1-time pad is not secure... ("Trevor L. Jackson, III")
Re: 1-time pad is not secure... ("Trevor L. Jackson, III")
Re: 1-time pad is not secure... (Simon Johnson)
----------------------------------------------------------------------------
Subject: Re: Random Number Generator
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 10:06:24 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Arithmetic operations with lose of overflow bit by addition
and overflow
>> byte by multiplication implement one way function. It is
impossible to
>> calculate previous state from current one. Third randomness
factor means
>> that during consequently interpretation of words some of them
may be
>> already modified by previous steps and probably not only one
time.
>> Got knows how you can calculate previous state from the
current one.
>
>Nobody needs to reverse the mapping. Consider:
> /* "absolutely secure" key generator */
> #include <stdio.h>
> int main() {
> FILE *fp = fopen("/dev/random","rb");
> for(;;) {
> int c = getc(fp);
> c &= 0xF0; /* irreversible */
> putchar(c);
> }
> }
>What does the irreversibility of the mapping have to do with
>whether the output can be used securely as a crypto key?
>Indeed, push this to the limit and mask off *all* the
information
>originally in c; clearly the output is the worst possible key.
>
>> Let me ask you how can man implement permutation of bits not
using
>> Assembler?
>
>It's easy enough to do in C; every bit (on all popular
platforms)
>in the representation of an integer is individually accessible
in
>various ways, most commonly by using logical operators (bit
masks).
Better yet
/* "absolutely secure" key generator */
#include <stdio.h>
int main() {
FILE *fp = fopen("/dev/random","rb");
for(;;) {
int c = getc(fp);
c &= 0x00; /* irreversible */
putchar(c);
}
}
which can be optimized (due to my programming expertise) as
#include <stdio.h>
int main() { for (;;) putchar(0); return 0; }
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Secure Operating Systems
Date: 11 Aug 2000 17:24:55 GMT
>
>I keep hearing rumors of a secure version of QNX that they don't want
>advertised...
>
>
If there is it will be in the NSA approved
security products catalog. They list other
highly secure products as well.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: New version of scott16u and scott19u available
Date: 11 Aug 2000 17:25:10 GMT
tomstd [EMAIL PROTECTED] writes:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> This site http://www.radiusnet.net/crypto/
>>know has the latest versions of scott16u and scott19u
>>the scott16u package also contains code that was sent
>>to me from Germany. The code that it uses may make it
>>easier for others to compile on other then DJGPP GNU C.
>>Both methods use a form of "all or nothing" encryption
>>where a single bit change in the plain text would change
>>the whole output file. Also if even one bit changes in cipher
>>text file it changes the whole input file it uses "wrapped
>>PCBC" and the 19 bit version is slow unless you have a very
>>fast machine. I my make more contests later since the
>>last one was not solved. Also any one even with JavaScript
>>on can visit mt website. These changes make it easier to use
>>on other machines.
>
>Who are you to say javascript is bad?
He doesn't, in this post, say Java Script is bad. I believe
he once used JS on his web page to show the possible
dangers of having JS enabled in Netscape. He got quite
a few complaints, as I recall, in this news group.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: 1-time pad is not secure...
Date: 11 Aug 2000 17:11:29 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> writes:
|> fvw <[EMAIL PROTECTED]> wrote:
|> : <8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
|>
|> :>Can you generate truely random numbers? No.
|>
|> : yes. time between radioactive decays for instance is a
|> : textbook example of a perfect random generator.
|>
|> No such thing as a perfect random number generator has ever been created.
|>
|> Time between radioactive decays /may/ be random - or it may not be.
|> Without vertain access to a complete theory of physics nobody knows.
|> ...but this is beside the point - even *if* such a random process were
|> available, there's no way of measuring it without using a detector
|> which is potentially subject to non-random environmental interference.
|>
The RNG doesn't have to be perfect. It just has to be something that
your enemy can't find any useful non-randomness in.
Assume the enemy has all your previous and future messages and
ciphertexts. He knows your exact algorithm and cryptosystem.
He has your ciphertext. He knows the message you sent is one of
two messages of equal length. He doesn't have the section of
pad for this particular message. This gives him two possible
pads generated by your random number generator. It also gives him
sample output from your RNG process for analysis.
By analyzing this data, can he determine which of the two possible pads
is more likely to be correct? If your RNG is not biased, he can't
determine this. If your RNG is biased, but it's biased in some way he
can't detect, he can't do this.
Also, if the RNG is biased in a way he understands, he may get a
relative probability for the two different cleartexts, but not
necessarily an absolute answer.
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: Ian Upright <[EMAIL PROTECTED]>
Subject: Re: Cross-platform secure chat
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Aug 2000 17:53:04 GMT
"Adam Smith" <[EMAIL PROTECTED]> wrote:
>Anyone know of such a thing? I know the idea of a PGPChat has been bounced
>off the walls in alt.security.pgp...
>
>I did a search on it, and it appears someone made a PGPChat back in like '94
>that operated by the two users dialing into each other...LOL! : )
>
>Although someone said it wasn't very secure...
>
>But anyway, something in java would be great...needs to run on a
>PC/Mac...any links?
>
>Thanks!
How about setting up your own IRC server, and using a program like stunnel
(www.stunnel.org) or other similar programs to encrypt all the traffic
between. Then users could use whatever IRC client they like, on whatever
platform they like. Note, that DCC tranfers and the like would *not* be
encrypted.
Unfortunately I'm not sure if there is a program like stunnel for the Mac.
Check here for possibilities: http://www.openssl.org/related/apps.html.
If the Mac is connected to a UNIX or Windows machine on a local network, the
Mac could use the local server which would then provide the secure tunnel to
the real IRC server located elsewhere.
Ian
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: Cross-platform secure chat
Date: Fri, 11 Aug 2000 18:02:52 GMT
I wonder if I could use something like AIM (AOL Instant Messenger) with a
simple VPN package, like PGPNet?
Any thoughts on that one?
"Adam Smith" <[EMAIL PROTECTED]> wrote in message
news:ZRLk5.564$[EMAIL PROTECTED]...
> Anyone know of such a thing? I know the idea of a PGPChat has been
bounced
> off the walls in alt.security.pgp...
>
> I did a search on it, and it appears someone made a PGPChat back in like
'94
> that operated by the two users dialing into each other...LOL! : )
>
> Although someone said it wasn't very secure...
>
> But anyway, something in java would be great...needs to run on a
> PC/Mac...any links?
>
> Thanks!
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 11 Aug 2000 10:46:57 -0700
We have some very ad hoc approximations, that we've through trial and error.
Basically we've kinda decided that uncorrelated, unbiased, unprecictable is
about all we can do. Other than that we can throw various measurements at
and debate for decades on the finer points of them. So we've created this
very abstract object called a perfect random number generator, which no one
can completely agree on how to judge it except that it is all of them.
Joe
"Jott" <[EMAIL PROTECTED]> wrote in message
news:8n0kug$rqj$[EMAIL PROTECTED]...
>
> > Even if there *were* fundamentally random processes in
> > basic physics = which is far from proven - that would be unlikely to
> > make building a "true" random number generator possible.
>
> Is there some fundamental definition of randomness that I have missed? And
> especially of "true randomness"?
> I am only aware of the statistical criteria, and the definitions of
> Kolmogorov/Chaitin/Martin-Löf.
>
> Regards
> Anders J Johansson
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 10:54:54 -0700
I think you are sorely mistaken about the state of affairs here.
> > > - 57% Avalanche Effect
> >
> > Uhh... Was this algorithm supposed to be cryptographically secure?
> > If so, this number should scream out for attention: either you did
> > your avalanche tests incorrectly, or it seems likely that your
> algorithm
> > is unsuitable for cryptographic uses.
>
> What can you propose in this case?
He said EXACTLY what he proposed. He proposes that either you didn't measure
it correctly Avalanche, or your generator isn't good.
> Sorry but DES has nothing to do with random number generation.
> Would you like comparing with something similar?
Actually DES has quite a bit to do with generating random numbers. One of
the most popular methods of doing so is to encrypt a series of known numbers
with an unknown key; take the bottom few bits and concatentate them, and the
output is very good random numbers.
Joe
------------------------------
From: [EMAIL PROTECTED] (Cryptocol)
Date: 11 Aug 2000 18:13:53 GMT
Subject: Re: chap authentication scheme?
>Agreed. And it would be much nicer to have something like SRP. However,
>what I am trying to do is to squeeze as much as I can into a restricted
>protocol. Ie, the server issues the challenge and the client responds.
>The only thing that this can authenticate is client to server-- no two
>way. What I want to protect against is the cleartext transmission of
>passwords, and the cleartext storing of passwords on the server. Any
>additional protections are of course an extra bonus.
YES! SRP-like protocols (there are so many ;) must suffice what we need for
password security over insecure networks. However, if you really want to make
such a restricted protocol that is fit into your assumption, the protocol that
I constructed abrubtly must be useful in some sense.
A-CHAP can be secure if there is NO-sever impersonation. :) ...but how can we
make it?
Message 2 of A-CHAP can be reduced by using a strong one-way hash function.
Again, A-CHAP is...
1. Alice <--- g^x --- Bob
2. Alice --- h(g^y), (g^xg^v)^y ---> Bob
A-CHAP provides one-way authentication and does not allow dictionary attack to
others if Bob is really Bob ;)
I think this protocol is secure only if we assume it is infeasible to
impersonate Bob, for example, he is already authenticated by his certificate or
strongly wired or something like that. <--- but I think this assumption is
quite unreasonable for most environment. ;) ANYWAY, this protocol based on the
amplified password proof, must be secure if we have such a UNREASONABLE
ASSUMPTION.
conclusion again: SRP-like protocol must be the strong solution for password
security over insecure network without any hardware-supported (or
hardware-like) authentication methods.
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: Cross-platform secure chat
Date: Fri, 11 Aug 2000 18:18:16 GMT
Would anyone be interested in attempting to set up a PGPNet connection, with
the goal of achieving a secure chat session on AIM (AOL Instant Messenger)?
The only requirements:
a) PGPNet
b) AIM (one of the newer versions that allows a direct connection)
and I would prefer to attempt it with someone familiar with PGP, VPNs,
etc...
If interested, please email me!
Thanks!
"Adam Smith" <[EMAIL PROTECTED]> wrote in message
news:gdXk5.1018$[EMAIL PROTECTED]...
> I wonder if I could use something like AIM (AOL Instant Messenger) with a
> simple VPN package, like PGPNet?
>
> Any thoughts on that one?
>
> "Adam Smith" <[EMAIL PROTECTED]> wrote in message
> news:ZRLk5.564$[EMAIL PROTECTED]...
> > Anyone know of such a thing? I know the idea of a PGPChat has been
> bounced
> > off the walls in alt.security.pgp...
> >
> > I did a search on it, and it appears someone made a PGPChat back in like
> '94
> > that operated by the two users dialing into each other...LOL! : )
> >
> > Although someone said it wasn't very secure...
> >
> > But anyway, something in java would be great...needs to run on a
> > PC/Mac...any links?
> >
> > Thanks!
> >
> >
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Explain S-boxes please
Date: Fri, 11 Aug 2000 11:21:41 -0700
Actually I had a very similar amount of confusion for quite some time. An
S-box is simply a substitution box. It can be used in any fashion the
designer chooses. The current trend is to use them in a feistel network.
Basically the operation go like this:
Function(Key, Data)
for each round
subkey = GetRoundKey(Key)
subkey = SomeWeirdFunction(subkey, Data[first half])
Data[second half] = Data[second half] XOR subkey
SwapDataHalves(Data)
end for
end Function
Where in SomeWeirdFunction they perform some s-boxing. Becuase it's used in
that way, it can be non-invertible, or it can be invertible, it won't make a
difference because for decryption you compute the subkey's in reverse,
perform the same SomeWeirdFunction and the XOR, and the encryption magically
reverses itself. The key point in the invertability of the system is that
ONLY XOR is used on the half being altered (the first half is unaltered in
each round). However in general we want S-boxes to be invertible because
they resist analysis better.
Joe
"MVJuhl" <[EMAIL PROTECTED]> wrote in message
news:8n0l52$qpr$[EMAIL PROTECTED]...
>
> Could someone please explain where the S-boxes come from ? I mean, how are
> the computed.
> How would you select your own S-boxes ? What should you be careful of and
> what should you have in mind ?
>
> I only know that you substitute any given data with the content of the
> S-boxes in a specified order, and that these S-boxes have a inverse for
> decrypting. So if you would enlighten me, please do so.
>
>
> If you know of any links to papers explaining the S-box, please post/send
> them.
>
> Thanks
> M.V. Juhl
> [EMAIL PROTECTED]
>
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 11:04:33 -0700
> If only one bit of key/seed is changed this produces
> 57% changed bits in random sequence.
> Please test algorithm and all it's properties.
And you tested this on your "infinite" sequence how?
> > >- The probability to find in random sequence 0/1
> > > value bits is exactly 50%
> >
> > Gosh really?
> >
>
> Yes!Gosh.
And you measured this how? You're dealing with infinite sequence that you
are pretending are completely random.
>
> > >Randomness factors
> > >- lose overflow bit by addition
> > >- lose overflow byte by multiplication
> >
> > That's degenerative not random there is a big difference.
> >
>
> It is truly mapping to a random sequence.
No it's mapping to a degenerate sequence, there is a huge difference.
>
> > >Algorithm description, source code and EXE
> > >can be found and download at
> > >
> > >www.alex-encryption.de
> >
> > Hooray. I don't want to be rude but it doesn't look like you
> > have much of a clue.
>
> What about a bit of ethic?
> I believe you have more clue as me if you try to abuse me.
No one is trying to abuse you. We're trying to point out (as we do everytime
you post something new) that you don't have the knowledge yet to make these
things properly. We are more than happy to help you learn, but every time
someone points these things out to you, you get beligerent. I'm surprised
we're still responding to you with much information at all.
Joe
------------------------------
From: "ajd" <[EMAIL PROTECTED]>
Subject: obtaining RSA intemediate variables
Date: Fri, 11 Aug 2000 15:39:42 +0100
Hi,
I've written an RSA implementation using Montgomery's exponentiation method,
and it works (woo-hoo). However, I'm now looking to make the design
smaller - especially with regard to obtaining the intermediate variables
required for the montgomery technique. I would like to know if there is
another way of finding the inverse of m mod R (the orignal modulus, modulo
the new modulus). I am currently using Euclids extended algorithm. Is there
another way?
thanks
ajd
------------------------------
Date: Fri, 11 Aug 2000 14:40:03 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
"Douglas A. Gwyn" wrote:
> [EMAIL PROTECTED] wrote:
> > What seems impossible now will be possible to your grandchildren. So
> > you think nothing can go faster than light? Well keeping watching...
>
> The speed-of-light limit is not guesswork based on incomplete
> understanding; it is inherent in the very structure of our
> universe. "Light" happens to be a phenomenon that propagates
> with that speed, but the speed limit itself has nothing to do
> with light.
The speed of propagation of electromagnetic energy is derived from the two
fundamental properties that describe electromagnetic fields in space. IIRC
its permeability and permittitivity. Are you claiming the exact match of the
speed of light and the limit velocity for mass is a coincidence?
------------------------------
Date: Fri, 11 Aug 2000 14:42:12 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
You typed that with your right hand.
CMan wrote:
> Ok, here is absolutely THE LAST WORD on one time pads:
>
> "poMpYoihj"
>
> There...
>
> JK
>
> --
> CRAK Software
> http://www.crak.com
> Password Recovery Software
> QuickBooks, Quicken, Access...More
> Spam bait (credit E. Needham):
> root@localhost
> postmaster@localhost
> admin@localhost
> abuse@localhost
> webmaster@localhost
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> <[EMAIL PROTECTED]> wrote in message news:8mth1u$vpt$[EMAIL PROTECTED]...
> > Here's a different viewpoint.
> >
> > I think all the crypto-books are wrong. One-time pad is only secure
> > based on the assumption that random numbers do exist.
> >
> > But can you prove that random numbers really exist? No.
> > Can you generate truely random numbers? No.
> >
> > It's like 1/x tends to zero but you'll never get zero, if you use
> > enough bytes to hold the number.
> >
> > One-time pad is only computationally secure, no difference than any
> > other systems. The key-generating process may be duplicated, if not
> > exactly, to some probability. And because the key is so long, getting
> > at least a portion of the key right will be easier than in systems with
> > a shorter key.
> >
> > Get the picture? You can duplicate the key-generating parameters:
> > computer model, OS, PRNG, date, time, location, hardware, software,
> > room temperature, humidity, magnetic field... The list goes on and on.
> > Then the longer the key, the higher possibility that you'll get
> > something right.
> >
> > --Sisi
> >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
------------------------------
Subject: Re: 1-time pad is not secure...
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 12:04:01 -0700
[EMAIL PROTECTED] (fvw) wrote:
><8mth1u$vpt$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>>Can you generate truely random numbers? No.
>yes. time between radioactive decays for instance is a
>textbook example of a perfect random generator.
>
I query this...... Radioactive decay can be described by a
Expodential Curve, and is therefore is not strictly speaking
random.
Though the emmition of particles is truely spontaneous.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
