Cryptography-Digest Digest #962, Volume #13 Wed, 21 Mar 01 14:13:01 EST
Contents:
Re: Most secure way to add passphrase verification to "CipherSaber"
(SCOTT19U.ZIP_GUY)
Re: BBS ("Dobs")
Re: Advice on storing private keys (those who know me have no need of my name)
Re: I was so so right about PGP ... so right when I started writing (Frank Gerlach)
Re: redodancy ("Tom St Denis")
Re: Advice on storing private keys (those who know me have no need of my name)
Re: How to eliminate redondancy? (moving steadily towards being computer science
terminology) ("Tom St Denis")
Re: BBS ("Tom St Denis")
Re: RC4 test vectors after gigabyte output?. (those who know me have no need of my
name)
Re: I was so so right about PGP ... so right when I started writing about PGP and
about one author .... so right ..... ("Tom St Denis")
Re: RC4 test vectors after gigabyte output?. ("Tom St Denis")
Re: What do we mean when we say a cipher is broken? (David Wagner)
Re: What do we mean when we say a cipher is broken? (David Wagner)
Re: Fast and Easy crypt send (amateur)
Re: redodancy (amateur)
Re: What happens when RSA keys don't use primes? ("Kristopher Johnson")
Re: How to eliminate redondancy? (Benjamin Goldberg)
Re: What happens when RSA keys don't use primes? ("Tom St Denis")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: 21 Mar 2001 17:32:14 GMT
[EMAIL PROTECTED] (John L. Allen) wrote in
<[EMAIL PROTECTED]>:
>I was thinking about adding some rudimentary passphrase (Key)
>verification check capability to the CipherSaber protocol (see
>http://ciphersaber.gurus.com/). So, among the following choices, Which
>of these message streams is most secure as a means of providing a way
>for the decryptor to verify the correctness of the decryption Key
>without giving an attacker useful info:
>
> 0. IV, E(msg) # This is the current
>CipherSaber protocol
> 1. IV, E(IV), E(msg) # bad: "known plaintext"
> 2. IV, E(E(IV)), E(msg)
> 3. IV, E(E(msg{1..10})), E(msg) # bad: "known plaintext"
> 4. IV, E(E(E(msg{1..10}))), E(msg)
> 5. IV, H(msg{1..64}), E(msg)
> 6. IV, E(H(msg{1..64})), E(msg)
> 7. IV, E(Key), E(msg)
> 8. IV, H(Key), E(msg)
> 9. IV, E(H(Key)), E(msg)
>
>Where, IV is a random initialization vector.
> E() is an encryption algorithm using key Key.
> H() is a hash function.
> msg is the message
> msg{1..N} is the first N bytes of the message.
>
>Also, if a hash function is not available, what is the best way then?
>
>I lean toward #9 if a hash is available, otherwise, maybe #2 or #4.
>Encrypting the key and sending that as in #7 doesn't _look_ too good at
>first, but is it really that bad?
>
>John.
>
>
There are other ways to add security that gives no information
to an attacker. I will post a way on the net in a few days. It
will be different than the method I posted at the gov AES site.
but will be of possible use by you. I can give you the basic flow
of it. Howeve it will increase the time to encrypt and decrypt
plus it makes it an 'ALL or Nothing type of encryption" Here is
basic flow. For one assume a message composed in only a subset
of characters.
You have a messeage composed of ony certain characters.
1) you compress it using my compress h2comaf.exe
this makes a special FOF file on output.
or alternatively. You have a file that is a binary file of any
number of 8-bit bytes or you convert to a file or that form and
then run my program hat converts it to a FOF file.
2)You know run my code to convert a FOF file to binary file
that has form where at least one field exists and is 6 bytes
long and rest of fields if they exist is 1 byte in length each.
3) this is phase where you add the authentication and identity
check. You as a user has a secrect auth code which is a series
of values 0-5 in value. For this example say 4 digits of 1 2 3 5
Now you call rotatan and apply the first rotation to the file
and then uses DSC to bind the number in the file.
You repeat above so it occurs 4 times with each of the values above.
4) at this point you still will have a file of at least 6 bytes
where every possible value is possible. run my code to map to
FOF files.
5) run h2uncaf.exe to uncompress the file. Where the condition
file is the set of all 256 bit possible valuses. The ouput
file is a normal byte type of file.
6) run reverse and then compress with h2com.exe you know have
a normal binary byte file of any possiable value.
*****
here you need an encryption program that is fully bijective
from 8 bit binary files to 8 bit binary files
***
the resulting ouput can be any 8- bit byte type of file.
And even if by chance you test this with an output file one
byte long. You will end up when you use the reverse procedures
getting the 4 unique rotations that the byte holds. Though unlikely
to be the one picked for the secret if your checking for it.
If you send any message encrypted with this technique and used
the right values for the individual rotations any output file
is possible. Likewise any possible value used as an encrypted
file will decrypt to a unique file and 4 values of rotation that
are binded to it.
If any enemy sends you false file or modifes it in any way you
have a least 6**4-1 chances out of 6**4 of detecting the false
message or error in message transmission.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Wed, 21 Mar 2001 18:46:48 +0100
p and q kept secret?, what does it mean? , that it should be randomly
choosed from generated primes????
Użytkownik Simon Johnson <[EMAIL PROTECTED]> w wiadomości do
grup dyskusyjnych napisał:998hfv$q54$[EMAIL PROTECTED]
>
> Dobs <[EMAIL PROTECTED]> wrote in message news:9862va$mqp$[EMAIL PROTECTED]...
> > I have a question. How should good Blum Blum Shub Generator looks like?
I
> > know that it needs 2 large prime numbers p and q. Should this generator
> have
> > its own large prime number generator to generate new p and q each time
we
> > found our seed. Or it does not metter and I can for instance declare
that
> p
> > is such and q is such.
> > If it needs generator can somebody tell me one wchich would be proper
for
> > BBS, I mean will generate large prime numbers:
> > Best Regards:)
> > Michal
> >
>
> a BBS looks like this:
>
> x(i) = x(i-1)^2 mod pq -> where p and q are primes, and are kept secret.
> output = x(i) MOD 2^(log2(log2(pq)))
>
> x(0) is what starts this process off and is the key.
>
>
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Advice on storing private keys
Date: Wed, 21 Mar 2001 17:49:46 -0000
<[EMAIL PROTECTED]> divulged:
>Darryl Wagoner <[EMAIL PROTECTED]> writes:
>> I am working on a open source digital signature system using openssl
>> DSA functions. I have create my own cert format because of special
>> needs of ham radio users. I would like to encrypt the private keys
>> for safe keeping, but the passwords/key needs to be kept short.
be very careful how you design it, failure to protect it properly could
cause them to be useless. (e.g., a flaw that would allow anyone to pose
as anyone.)
>I don't understand what you're asking. What needs to be special about
>the certificates? And OpenSSL already lets you encrypt keys by a
>password.
generally the ham community has to send their call sign in the clear, so
having it encoded is something of a problem for them. (that was one of
the major reasons that we hacked up x.25.) their gear is often mcu and
ram limited so having a long stored passphrase is problematical as well.
i haven't paid much attention to the ham community in years, nearly
since the creation of ax.25, so perhaps the conditions have changed --
if so there's probably no good reason for a custom certificate.
--
okay, have a sig then
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing
Date: Wed, 21 Mar 2001 18:46:24 +0100
Tom St Denis wrote:
> JAVA sucks... it's slow, non-portable and gives errors on anything a normal
> C compiler would just warn you about. It's hard to develop software for...
Have you ever written something in java 1.2.x or 1.3 ?
Yes, it doesn't allow every kind of crap a c compiler may not even warn
you.
>
> Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Wed, 21 Mar 2001 17:56:57 GMT
"dexMilano" <[EMAIL PROTECTED]> wrote in message
news:99anrr$gqib$[EMAIL PROTECTED]...
> Is there some simple algoritm to remove redodancy in text?
> I tried ZIP but it's too heavy.
ZIP is not meant to "remove redundancy" in all texts which makes it useless
for specifically constructed non random data...
Tom
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Advice on storing private keys
Date: Wed, 21 Mar 2001 17:58:05 -0000
<[EMAIL PROTECTED]> divulged:
>The certs will carry unique information such as call sign and license
>class which may not fit well into normal certs.
that is easily included using the existing certificate format.
>The other requirements is too have a format that will be easy for
>non-crypto types to add to their programs
if they can't follow the current certificate specs, and can't be
bothered to download very portable library source (e.g., openssl), then
you are going to have lots of other problems.
>and to have a format that could easy be worked into text file formats.
use base64 encoding when necessary. (see rfc1421, sections 4.3.2.4 and
4.3.2.5 for a description of the method.)
>Standard certs maybe able to fit the bill, but I knew I could create
>my own format cert that would in less time.
but would they be as good?
--
okay, have a sig then
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy? (moving steadily towards being computer
science terminology)
Date: Wed, 21 Mar 2001 17:59:57 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <xU4u6.98657$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Tom St Denis) wrote in
> >> <ep4u6.98534$[EMAIL PROTECTED]>:
> >>
> >> >
> >> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >> >news:[EMAIL PROTECTED]...
> >> >> I think you know my anwser to that but to elighten others I
> >> >> will explain what a good sized key is. It is as large as possilbe
> >> >> while getting the job done so as to not to cause the user to much
> >> >> time waiting.
> >> >
> >> >There are other problems with using million byte keys.
> >> >1. Where to get that much good entropy?
> >>
> >> Godd question. The anwser is you most likely don't.
> >> But at least with my system you can use what you can get.
> >> And you can still use a passord of any size to use the
> >> key. Of cousre just like anything else best to use on
> >> computer you have full control of. And if your master
> >> password to short and some. One gets to test it they
> >> may find the password.
> >
> >Ahh... but would a million bad bits be better then 192 good bits (bad =
> >nonrandom, good=random as can be)
> >
>
> If by bad you mean something like the total amount of entropy
> in the not so random million bits. Was less than the entropy
> in the more random 192 bits. Then I think even a kid like you
> knows the anwser. But using 200 bits where the first 192 bits
> are the same as your short key. and 8 good random bits would most
> likely kick ass if first part of millon bit key.
Hmm you missed the point. If you have a million bit key but every bit is
biased by say p=0.999999999, q=0.000000001 then what's the point?
My real point is about efficiency. It's easier to get, store, use,
manipulate 192 (or whatever...) bits then 1million bits. So if 192 bits are
truly random and only say 1/10000 of the million bits are random then is it
really any better?
Note that the avg RNG based on a computer only gets about a few bits per
second at the most. If you sample too quickly it's not decorrelated
enough.... so a million bit key could take a week to make whereas 192 bits
may take a minute or so...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Wed, 21 Mar 2001 18:01:02 GMT
"Dobs" <[EMAIL PROTECTED]> wrote in message news:99ap9p$dff$[EMAIL PROTECTED]...
> p and q kept secret?, what does it mean? , that it should be randomly
> choosed from generated primes????
I suggest you read HAC or some number theory text that talks about the SQRT
problem.
Yes p and q must be secret, BBS is secure only if factoring is hard...If you
give out p and q factoring is not hard...
Now if all you need is a good non-secure PRNG BBS is the totally wrong way
to go.
Tom
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Wed, 21 Mar 2001 18:01:36 -0000
<34Nt6.90673$[EMAIL PROTECTED]> divulged:
>If your implementation matches for about a kb or so then I think you can be
>assured it's ok.
are you sure about that?
>> 73's de Luis
>
>Amateur radio dude?
>>Ampr: eb7gwl.ampr.org
$ whois ampr.org
[...]
Amateur Radio Digital Communications (AMPR-DOM)
[...]
--
okay, have a sig then
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: I was so so right about PGP ... so right when I started writing about
PGP and about one author .... so right .....
Date: Wed, 21 Mar 2001 18:02:55 GMT
"Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
>
> > JAVA sucks... it's slow, non-portable and gives errors on anything a
normal
> > C compiler would just warn you about. It's hard to develop software
for...
> Have you ever written something in java 1.2.x or 1.3 ?
> Yes, it doesn't allow every kind of crap a c compiler may not even warn
> you.
Hmm a good C compiler will warn you about almost everything. Have you ever
used one?
Try this in Java...
static int myfunction(int a)
{
if (a == 0) a = 4;
/* testing something */
return a * 3;
/* more code */
a = a << 1;
return a;
}
Compile that...
Yes it's bad coding but if you wanted to return early just to try something
you can't in Java... in C you get a warning and that's it.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Wed, 21 Mar 2001 18:08:10 GMT
"those who know me have no need of my name" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]...
> <34Nt6.90673$[EMAIL PROTECTED]> divulged:
>
> >If your implementation matches for about a kb or so then I think you can
be
> >assured it's ok.
>
> are you sure about that?
Yup. If you compare the RC4 states of two diff implementations after a kb
or so and they match then you can be reasonably assured they work.
>
> >> 73's de Luis
> >
> >Amateur radio dude?
>
> >>Ampr: eb7gwl.ampr.org
>
> $ whois ampr.org
> [...]
> Amateur Radio Digital Communications (AMPR-DOM)
> [...]
>
> --
> okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: What do we mean when we say a cipher is broken?
Date: 21 Mar 2001 18:17:52 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John Savard wrote:
>The beauty of a different definition of security than the one needed
>in practice, as long as it is strict enough (even if it is excessively
>strict) is of course that it may be usable in proofs of security.
But AES is much more than an encryption scheme. It is a
general-purpose primitive, used, e.g., to build MACs, etc.
For example, the mere assumption that AES does not reveal
anything about the plaintext (for some plaintext distribution)
is (provably!) not sufficient for AES-CBC-MAC to be secure.
For general-purpose primitives that will be used in many ways,
indistinguishability seems to be the right notion. It allows
secure composition, where the weaker notion ("not revealing the
plaintext") is insufficient.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: What do we mean when we say a cipher is broken?
Date: 21 Mar 2001 18:19:16 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John Savard wrote:
>On 20 Mar 2001 20:37:40 GMT, [EMAIL PROTECTED] (David Wagner)
>>Just because we can't prove that a cipher is Crowley-secure
>>doesn't mean that the notion isn't useful. It's the right
>>goal to shoot for, and if anyone finds an attack that shows
>>that Rijndael is not Crowley-secure, then I'd argue we should
>>re-consider whether Rijndael is the best cipher to use.
>
>Why is it the right goal to shoot for?
Because it is what lets us use Rijndael for more than just
encryption, but also for message authentication, for building
stream ciphers, for building pseudorandom functions, and for
all sorts of other uses.
Your other reasons are also good ones, too.
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Wed, 21 Mar 2001 13:19:38 -0400
I'm still not convinced. I do not have to know cryptography to
undertstand that a RANDOM sequence is non information at all.
My encrypted text is RANDOM serie.
How could you exploit random sequence???
Joseph Ashwood wrote:
>
> Honestly, I have explained it, I'm not going to explain it any more, read
> the sci.crypt FAQ, read a book on cryptography, if you still don't get it,
> then just realize that you don't get cryptography, and don't try. If you do
> get it then you will immediately realize that the only valid decryption of
> your example was in fact 10011001, and that attempting to fix this problem
> is useless. To reiterate please read a book on cryptography, please read the
> sci.crypt FAQ, both will explain in great detail just exactly why your
> algorithm is completely useless.
> Joe
>
> "amateur" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
------------------------------
From: amateur <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Wed, 21 Mar 2001 13:21:36 -0400
Simple. You assign specific code to every character.
It's easy.
dexMilano wrote:
>
> Is there some simple algoritm to remove redodancy in text?
> I tried ZIP but it's too heavy.
>
> Thx
>
> dex
------------------------------
From: "Kristopher Johnson" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Wed, 21 Mar 2001 18:12:23 GMT
Does this mean that, after generating your RSA keys, you should test to make
sure that an encrypt operation followed by a decrypt operation yields the
original plaintext?
-- Kris
"Paul Thomas" <[EMAIL PROTECTED]> wrote in message
news:99a8u6$51k$[EMAIL PROTECTED]...
> > the encryption / decryption will break, for example
> >
> > let p=8, let q=6
> >
> > therefore n = 6 * 8 = 48
> > therefore z = 5 * 7 = 35
> >
> > let e = 11,
> >
> > therefore
> >
> > d = 16 since 11 * 16 = 176 = 1 mod 35
> >
> > now suppose the message is 8
> >
> > then encrypting you get ...
> > 8^11 mod 48 = 32
> >
> > but decrypting you get ...
> > 32^16 mod 48 = 16
> >
> > and 32 != 16.
>
> dooh, my first post to sci.crypt and i fecked it up ;-)
>
> last line should read
>
> 8 != 16
>
> Paul
>
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Wed, 21 Mar 2001 18:29:06 GMT
SCOTT19U.ZIP_GUY wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >If you correctly consider (for example) the gzip function, it's
> >domain is the set of all files, and it's range is the set of those
> >files producable by gzip. It would be incorrect to say that it's
> >range is the set of all files. If you consider it's range to be the
> >set of those files producable by gzip, then it is a bijective
> >function. If you incorrectly consider it's range to be the set of
> >all files, then it would appear to not be a bijective function.
>
> If you use the output of the compressor to a general ecnryption
> routines that has as its domain the range of all binary files
> that for the purposes at hand your gzip was difitely not bijective.
Given a general purpose (bijective, nonpermutative) compressor whose
domain is the set of all files, but whose range is a proper subset of
the set of all files, and... Given a general purpose (bijective,
permutative) encipherer whose domain is the set of all files, and whose
range is also the set of all files.
We can create a system which compresses and the encrypts, and it will
have the following properties:
The domain of the system is the set of all files, and the range of the
system is the set of encrypted versions of those files which the
compressor outputs.
Now that the domain and range of the combined compress + encrypt system
are both defined, it is easy to see that it is a bijection. It is also
easy to see that it is not a permutation, since the range of the system
is a proper subset of the set of all files, and thus not equal to the
domain.
> >> > If you use definitions other than those that the scientfic
> >> > community accepts, you can make any sort of claims you like.
> >>
> >> Okay, let's find another term for the property David Scott has
> >> proposed. To name it "bijective" is confusing and not appropriate,
> >> so let's call it "s-bijective" (S in honour of David Scott). But
> >> perhaps that is not even necessary because there's already a
> >> precise term for this that is established in contemporary
> >> mathematics---I'd guess there is.
> >
> >Yes. A function whose domain and range are the same is a
> >permutation.
> >
>
> >> So instead of argueing about names, is there actually someone who
> >> has opinions about how and how much overall security an s-bijective
> >> compressor would add or not add?
> >
> >A trivially small amount of security
>
> And what makes you so sure it trival.
Because all it does is give us a way to test that a trial decryption is
correct. All modern cryptanalysis systems require huge amounts of KNOWN
PLAINTEXT, so we already have a way of testing that a trial decryption
is correct, without needing to rely on the characteristics of the
compressor.
> When the main difference is if you use a poor compressor most of the
> test keys are tossed out as beind impossible to use.
We try our test keys on the known plaintexts that our cryptanalysis
system requires to work, and are able to narrow down to one single
unique key without having to do trial decryption.
> >A person who is doing trial decryptions, and has no plaintext
> >whatsoever, will be able, if normal, nonpermutative compression is
> >used, to be able to use artifacts introduced by the compressor to
> >identify correct plaintexts when doing trial decryption. Normal
> >compressors do not introduce even one complete known plaintext block,
> >merely a few bits of known plaintext here and there, and some
> >distinguishing characteristics.
> >
> >If we take random data, and gzip it, we can distinguish it from
> >random simply by looking for the headers. Also, if we decompress a
> >gzipped random file, it successfully decompresses. If we attempt to
> >decompress a real random file, it is likely to result in CRC errors,
> >or some other errors, and abort and fail to decompress.
>
> There are other ways to add athentication and data integrity to
> an encrypted file than add a CRC to the compression.
True. To add authentication and integrity, we add either an MAC or a
signed hash of the message. However, the presence of a CRC does not
significantly weaken encryption, except with respect to brute force,
since for a CRC of the whole message to be used to test if a trial key
is correct, the enemy must decrypt the entire message. To decrypt the
entire message, we need a trial key. To get a trial key, the enemy must
have many many many blocks of known plaintext, assuming he is using
modern cryptanalysis (as only an imbecile would try brute force against
a modern cipher). If he's got blocks of plaintext, who cares about the
CRC?
> The idea is to hide the real data from an attacker and one way would
> be not to tell the attacker he has the correct key when tested or that
> he has the correct key when tested. It should be hard for the
> attacker.
This can be achieved quite easily by applying an AONT such as OAEP.
> >If we compress a random file with a permutative compressor, it will
> >hopefully still be indistinguishable from random. Also, if we
> >attempt to decompress a random file, there will be no errors, no
> >abort.
>
> Actually one would want this for all compressors it just that 99.9
> per cent fail this test.
Which test? I described two things, and you say one is good, but not
which. Hmm, lossy compression of two ideas to one?
> >Thus, you can see how nonpermutative compressors intruduce
> >distinguishing characteristics. This kind of distinguishability is
> >very very minor, since we normally must have a huge amount of known
> >plaintext for most attacks, and it is just as easy/just as difficult
> >to obtain, regardless of which type of compressor is used.
>
> It only tales a minor flaw to bring down an encryption system
> or do you know anything about the subject. If there a flaw it
> should be fixed no matter how minor expecially if its easy to fix.
A pebble in just the right place can stop an avalanche, or start one.
However, compression is near the bottom of the hill. If it's done
exceedingly well, it can protect you [slightly] from falling rocks, but
it's not likely to be the rock which starts the break.
> >> What do cryptanalists say about s-bijective compression once they
> >> have learned what "s-bijective" is supposed to mean?
> >
> >Most cryptanalysts ignore David Scott since he acts like a Troll.
>
> Well I think most do ignore me. However I do get fan mail from
> some who say they are crypto people.
People who say they are crypto people? Yeah, right. And I'm the king
of england. Really, I am. What, you don't believe me?
> It obvious I don't kiss ass very well like the majority of crypto
> people.
There's no need to *kiss* ass. Just don't *be* an ass. You're not very
good at not being an ass.
> One who thinks BS is a pompous ass helped me set up my crypto
> page.
I forget, what person are you talking about when you say BS? Bruce
Schneier?
Anyway, your crypto web page is rather poorly organized.
> But his identity is secret.
Probably because he is too embarrassed to be associated with you.
> He has meet Mr BS and been to several crypto meeting.
Meeting cryptographers and going to crypto meetings does not make him a
cryptographer. It's breaking ciphers, and publishing those breaks,
which makes a person a cryptographer.
> I was the kind of person at work that they used to fix things
> when they turned to shit.
So you've got alot of experience with shit.
> But got little credit for most of my work.
Yeah, I suppose shit-shovelers are really under-appreciated.
> Since I don't play the PR game well.
Well, if all you work with is shit, then not many people are going to
want to be associated with you.
> I do like to poke fun at stiff establishment assholes in all
> fields and if I was making new code I might call it TROLL or CRAP
> or AES ( for Asshole Encryption System) or something along those
> lines.
Working with shit obviously has distorted your view of the world.
> The only crypto person I know personally ( face to face ) signs
> the name "wtshaw" to most of his posts. But I think the community
> has written him off as well though he is very nice polite guy.
wtshaw's a fairly intelligent, well-spoken person. Some of us may not
agree with his views, but that doesn't mean we've "written him off."
> But he is not in the ass kissing class that most other crypto people
> seem to be in yet he knows many of the others and I think is
> friendly with them.
Still talking about ass, are you? You should go visit a shrink to get
over your anal fixation.
> So he really is the only guy that knows me well enough to communicate
> what I am really like to the others of this closed group.
He's probably embarrassed that he knows you.
> David A. Scott
[snip big, ugly, stupid sig]
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Wed, 21 Mar 2001 18:33:35 GMT
"Kristopher Johnson" <[EMAIL PROTECTED]> wrote in
message news:ba6u6.157193$[EMAIL PROTECTED]...
> Does this mean that, after generating your RSA keys, you should test to
make
> sure that an encrypt operation followed by a decrypt operation yields the
> original plaintext?
No it means you should use a mathematically sound probable prime generator
such that the probability of failure is astronomically small. (i.e
Rabin-Miller)
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
