Cryptography-Digest Digest #970, Volume #13 Thu, 22 Mar 01 11:13:01 EST
Contents:
Re: NSA in the news on CNN (Eric Lee Green)
My note on 5/16/1999 -- PGP etc. ([EMAIL PROTECTED])
Re: A future supercomputer ("JCA")
Re: Most secure way to add passphrase verification to "CipherSaber" ("John L. Allen")
Re: Most secure way to add passphrase verification to "CipherSaber" ("John L. Allen")
Re: Most secure way to add passphrase verification to "CipherSaber" ("John L. Allen")
Re: Speed of factoring (Frank Gerlach)
Re: What happens when RSA keys don't use primes? ("Kristopher Johnson")
Chinese Telegraph Code (Jim Reeds)
Re: Multiple encryption, more secure ciphers (Joe H. Acker)
FYI: trivia regarding DES terminology (John Myre)
Re: Most secure way to add passphrase verification to "CipherSaber" (Joe H. Acker)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: NSA in the news on CNN
Reply-To: [EMAIL PROTECTED]
Date: 22 Mar 2001 09:13:02 -0600
On Thu, 22 Mar 2001 09:42:29 +0100, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>> [EMAIL PROTECTED] writes, in part:
>> >but somehow I don't think it's
>> >possible to support operations by selling coffee mugs :-)
>
>A remark somewhat out of context: There are a number of
>certain non-government organizations that need people
>constantly operating at geographically dispersed locations.
>So they set up businesses ranging from pizza restaurants
>(very common) to banks (few), which solves simultaneously
>the financial, lodging, etc. etc. problems. Wouldn't it be
Ah, I think I know the organizations of which you speak. "Uncle Carlos"
once spent many an evening in the Italian restaurant owned by a friend's
uncle, often in the company of high ranking government officials.
He was just a humble restaurant owner in New Orleans, of course. That's
why they deported him back to Sicily eventually (grin).
>wise for the government secret agencies to do the same, at
>least for the purpose of reducing the budgets? Or are they
>already practicing that?
Two words: "Air America".
Unfortunately, secret agencies appear to be bad businessmen. Their
enterprises seem to rarely be profitable. The reason that, err,
"certain organizations" can operate businesses that appear to make a
profit is because they make their real profit via other means, such as
prostitution, illegal gambling, drug transport, etc.
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.2600,comp.security,alt.security
Subject: My note on 5/16/1999 -- PGP etc.
Date: 22 Mar 2001 15:16:00 GMT
"One of the most popular encryption program is one element of NSA´s covert
action program to control the strength of encryption algorithms in the market
place. An encryption application with backdoors. Its author is the member of
the information security architecture committee." 5/16/1999
Actually I had access already to some interesting memos in 1993 ... it was
great .. these were all from the military security establishment ...
I would not trust Philip Zimmermann or his products ....
The CIA, NSA and FBI are actively stealing business information from
international corporations .....
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "JCA" <[EMAIL PROTECTED]>
Subject: Re: A future supercomputer
Date: Thu, 22 Mar 2001 07:29:27 -0800
Well, I think I have made my point very clear already - raw computing
power, albeit necessary, does not constitute by itself a solid foundation
(to use your words) to attempt to compete with a human brain. That's all.
There is probably so much we ignore on the human brain's internal
working that the computing power afforded by Blue Gene is likely to make
no substantial difference in the effort to attain the goal you mention. Hence
my skepticism about Blue Gene being a solid foundation, etc.
Notice that I am not saying that Blue Gene will be useless as far as
this endeavor is concerned. But, to resort to another analogy, it will
allow us to jump a bit higher than before, but by no means to fly.
In article <[EMAIL PROTECTED]>, "Mok-Kong Shen"
<[EMAIL PROTECTED]> wrote:
> JCA wrote:
>> "Mok-Kong Shen"<[EMAIL PROTECTED]> wrote:
>> > Computing power is ONE of the fundamental requirements. If everything
>> > else is solved in theory, without the computing power to do that is
>> > futile, like one understands perfectly how a rocket works but without
>> > the required fuel. With more computing power, one can try algorithms
>> > that would otherwise be impossible. (See e.g. simulation of nuclear
>> > explosions, which was why the ASCIs were built.) M. K. Shen
>>
>> Let me turn your analogy upside down - in order to actually
>> launch a
>> rocket one must be able to build a fuselage first. But just having this
>> skill without knowing the physical principles on which rockets are
>> based will take one nowhere fast.
>>
>> The same with raw computing power and the human brain.
>> Humongous
>> horsepower is probably a relatively minor part of the solution, and
>> hence my belief that ASCI and Blue Gene are not likely to change things
>> at all in this respect.
> If I understood you arguments correctly, your point is that one should
> first do good researches to understand the fundamental problem of how
> the brain works, for without that understanding mere computing power is
> of no use. But such researches are themselves dependent on computers!
> One has till this day yet only some plausible theories and speculations
> about the brain. One of the apparently promising ways of study is to try
> out some theories via computer simulations. The brain is an extremely
> huge and complex network of neurons with a large computing power
> potential. In order to carry out such work one needs correspondingly
> large computing resources. Isn't that logical? Note that I was not
> saying that with a big supercomputer a success is guaranteed but that
> without taking a first step of building such a machinery it is entirely
> hopeless of ever achieving the goal (of building a machine with high
> 'intelligence'). If you think that computing power is unessential, let
> me first remark that the design of modern computers itself is dependent
> on the availability of large computing power. What would the diverse
> fields of natural sciences of today have been, if we hadn't had a large
> number of fast and comparatively cheap processors? The first computer I
> used was very very slow compared to those of the current time. At a
> later time point I was fascinated, as I first used a PC of 16 MHz, for
> it was very fast compared to the old one. Do you think that there would
> have been space flight or results like the Human Genome Project or even
> the good (though not yet satisfactory) weather forcasting, etc. etc., if
> the availability of computing resources had stopped at that stage and
> all what one has today were a rather small number of computers
> comparable in power to the 16 MHz PC that I once had?
> M. K. Shen
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 14:46:34 GMT
"Joe H. Acker" wrote:
> John L. Allen <[EMAIL PROTECTED]> wrote:
>
> > I wanted to avoid having to hash the entire plaintext, which was why
> > I was limiting it to the first 64 bytes.
>
> How about
>
> IV, E(CRC32(H(CRC32(msg)))), E(msg)
>
> a checksum mechanism reduces bandwith. But maybe
>
> IV, E(CRC32(H(msg))), E(msg)
>
> isn't much slower. Perhaps a faster checksum mechanism like Adler would
> do as well. Of course, this check can sometimes fail, but that's usually
> not a big problem.
Remember, I want to avoid the slow H(msg), so this simpler version
of your first suggestion might be ok:
IV, E(H(CRC32(msg))), E(MSG)
But it still suffers from having to read the entire plaintext before being
able to start writing the encrypted result. So, why then not
IV, E(msg), E(H(CRC32(msg)))
? That would mean you'd have to read the entire encrypted stream
before being able to verify the password. And I guess Paul Rubin
is right in saying doing a hash _and_ a CRC is too complicated for
CS.
So, I go back to one of my first ideas:
IV, E(E(IV)), E(msg)
Does this obviously give too much away?
John.
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 14:54:40 GMT
Mike DeTuri wrote:
> I'm not sure if this is the best way to do it or not but it solves the
> problem of a hash function not being available.
>
> After generating and tossing out the 256 bytes needed to make arcfour
> secure, generate a few more throw-away bytes. Then attach these
> throw-away bytes to the ciphertext right after the 10 bytes of
> initialization vector. After the throw-away bytes start attaching the
> ciphertext. Using your examples below it would look like this:
>
> IV, throw-away bytes, E(msg)
>
> On decryption pull out the IV, generate the 256 bytes of keystream,
> and generate the desired number of throw-away bytes. Then compare the
> generated throw-away bytes with the throw-away bytes in the
> ciphertext, if they match start decrypting. If not, display an error
> message and ask for a different passphrase.
Now _that's_ interesting! Using the rc4 output itself as the "Hash" of
the passphrase. I think I like it. But is giving away some of the
rc4 stream to the attacker a good idea? Maybe
IV, E(throw-away bytes), E(msg)
would be better?
John.
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 14:58:14 GMT
Sorry, but I don't really follow what you were saying there.
I'll have read it again sometime. And in any event, it seems
_way_ too complicated to add to CS, however great it may be.
John.
"SCOTT19U.ZIP_GUY" wrote:
> [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.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Speed of factoring
Date: Thu, 22 Mar 2001 16:39:44 +0100
Soeren Gammelmark wrote:
> =
> Hi
> =
> Yeasterday I read in Applied Cryptography, that the time-estimate of th=
e
> fastest variants of the quadratic sieve was
> e^((1+0(1))ln(n)^(1/2)ln(ln(n))^(1/2))
> What I don't understand is the 0(1)? =
I think it means something like "some constant" (comes from Order
of(1)).
For example, O(n) for a search algorithm means that search time
increases with the length n linearly.
>Is it really zero multiplied with
> one (which seems stupid to write) or is it a function indicating the
> time it takes to factor som base number? I really do not understand how=
> to use the formula.
> =
> S=F8ren
------------------------------
From: "Kristopher Johnson" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Thu, 22 Mar 2001 15:26:01 GMT
I understand that the chance of failure is practically zero. But, is there
is some easy, inexpensive way to test for failure, and if so, what is it?
-- Kris
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:3u6u6.98761$[EMAIL PROTECTED]...
>
> "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
>
>
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Chinese Telegraph Code
Date: Thu, 22 Mar 2001 15:41:04 GMT
A generalized question/request, and an announcement:
1. I want to find out everything I can about the old 4 digit Chinese
Telegraph Code. What were the different editions and publishers, is
it still in print, can one buy copies? Is it still in use? To what
extent was it standardized? And if so, by whom, exactly?
2. What I know about the subject is posted on a web page,
http://www.research.att.com/~reeds/ctc.html
I'd be really grateful for any corrections or additions which occur to
you.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Multiple encryption, more secure ciphers
Date: Thu, 22 Mar 2001 16:41:06 +0100
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Joe H. Acker) wrote in
> >My assumption is that the subkey derivation is the most important factor
> >in such a single-cipher multiple encryption, so I'm looking for a better
> >way to derive subkeys than just hashing them. Any ideas?
> >
> >How about k2 = hash(xor(k1, ct_i)) where ct_i is the last ciphertext
> >block of the previous round...?
> >
I must have been mentally absent when I wrote the last passage.
> Not exactly sure what your saying or doing here remember you also
> have to decrypt it.
Yes, indeed. ;)
So apart from my mindless suggestion, is there a good way to combine one
and the same cipher using one key? I'm looking for a subkey schedule
that makes the different round keys as independant as possible, although
they are all derived from the same original key. (I cannot use different
keys because I don't have enough entropy.)
Regards,
Erich
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: FYI: trivia regarding DES terminology
Date: Thu, 22 Mar 2001 08:50:43 -0700
Panu H=E4m=E4l=E4inen wrote:
<snip>
> DEA (Data Encryption Algorithm) is just another name for DES (Data Encr=
yption
> Standard). I believe DEA is used by ANSI and DES by NIST.
It is true that DEA and DES are synonyms to practically
everyone (at least, those who have heard of DEA).
Strictly speaking, though, "DES" is not the algorithm at all,
but the document defining it, which belongs to NIST. The
document is also known as "FIPS 46-3", the third revision of
Federal Information Processing Standard 46. I don't know what
ANSI does, but I'd bet they stick with the "proper" terminology
and refer to DEA when they mean the algorithm.
Actually, the standard defines not just DEA, but TDEA, which
is better known as "triple DES". So the distinction between
DES (the standard) and DEA (the algorithm) is meaningful, but
I'm not sure even the NIST staffers care. In fact, anyone who
tried to enforce the distinction would be regarded as hopelessly
pedantic, or a member of a government standards board.
JM
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 16:57:36 +0100
John L. Allen <[EMAIL PROTECTED]> wrote:
> "Joe H. Acker" wrote:
> Remember, I want to avoid the slow H(msg), so this simpler version
> of your first suggestion might be ok:
>
> IV, E(H(CRC32(msg))), E(MSG)
>
> But it still suffers from having to read the entire plaintext before being
> able to start writing the encrypted result. So, why then not
>
> IV, E(msg), E(H(CRC32(msg)))
>
> ? That would mean you'd have to read the entire encrypted stream
> before being able to verify the password. And I guess Paul Rubin
> is right in saying doing a hash _and_ a CRC is too complicated for
> CS.
>
> So, I go back to one of my first ideas:
>
> IV, E(E(IV)), E(msg)
>
> Does this obviously give too much away?
Please note that I'm an amateur, so others please correct me if I claim
something wrong. I'd say that double-encrypting the IV does not add
significant security. How about
IV, E(salt+IV), E(msg)
where salt is a few pseudo-random bytes from a PRNG. You can use Arcfour
as the PRNG, and the actual entropy of the random seed will be
implementation depend. Even if the entropy source is not optimal, this
seems more secure to me than just encrypting IV (known plaintext).
Regards,
Erich
------------------------------
** 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
******************************
