Cryptography-Digest Digest #907, Volume #10 Fri, 14 Jan 00 18:13:01 EST
Contents:
Re: New Crypto Regulations (JPeschel)
Re: New Crypto Regulations (wtshaw)
Re: Little "o" in "Big-O" notation (Mike McCarty)
Re: About DES algorithm. (Paul Koning)
Re: Cryptography Exporting? (Paul Koning)
Re: Encryption Keys (David Hopwood)
Does this internet encryption item transfer scenario make sense? (ray gaudia)
Re: New Crypto Regulations (wtshaw)
Re: Blum, Blum, Shub generator (Kent Briggs)
Re: New Crypto Regulations ("John E. Kuslich")
Re: Cryptography Exporting? (Jeff Williams)
Re: Cryptography Exporting? (Eric Lee Green)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) ("Douglas A. Gwyn")
Re: Blum, Blum, Shub generator (lcs Mixmaster Remailer)
Re: Blum, Blum, Shub generator (lcs Mixmaster Remailer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: New Crypto Regulations
Date: 14 Jan 2000 19:41:26 GMT
John E. Kuslich [EMAIL PROTECTED] writes, in part:
>What kind of government can get away with making laws the meaning of
>which are not clear until such time as one is prosecuted for violating
>such laws?
then rants, in part:
>Perhaps the answer is a government led by a man who can lie under oath,
>violate his marriage vows with a post pubescent bimbo in the Oval
>Office, and keep a Cabinet together after using them to lie to the
>public and assist in the cover-up of his immoral acts.
>
Put a lid on it, John. You only embarrass yourself.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 14:21:49 -0600
In article <[EMAIL PROTECTED]>, "John E. Kuslich"
<[EMAIL PROTECTED]> wrote:
> I hereby dare anyone to tell me that he/she has read and understood the
> new crypto regulations. They are simply beyond comprehension and
> deliberately so. These regs will make many a lawyer rich!
>
Remember the old shell game: the goal is to keep the victim so busy
watching the wrong things that he does not see what is happening. Of
course, I will read the *stuff* in detail, but the bureaucratic trick is
much like it is elsewhere to so discourage, saddle, overwhelm the
individual that they beg to be handfed, if you like to learn to swallow
crap, and say "More."
The most important fact regarding any of these regulations is that the
source retains the tendency to be capricious, arbitrary, and independent
of logic, ready to change them as they see fit, remolding them at will for
contemporary advantage. The objection we have, have had, and will have is
that it is not so responsible, patently not legal, to be so damn flakey in
spelling out what you want for fear of being discovered unconstitutional.
And, I am being nice.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Little "o" in "Big-O" notation
Date: 14 Jan 2000 20:17:12 GMT
Interesting. I am a mathematician, and have had a few brushes with
computer scientists here and in other spots on the use of 'o' and 'O'.
It's important to keep in mind that notation is just that, and different
people use different dialects, I suppose.
Mike
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
)Most algorithmics books will use the set defintion, most
)
)math books will use the limit definition.
)
)The bible of algorithms book (Introduction to Algorithms,
)
)from Cormen Leiserson and Rivest) have the set notation,
)
)see also Algorithmics, from Brassard and Bratley (another
)
)excellent alogorithmics book).
)
)Anton
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: About DES algorithm.
Date: Fri, 14 Jan 2000 16:03:16 -0500
Rick Braddam wrote:
>
> Katsamakas Kostas <[EMAIL PROTECTED]> wrote, in part:
>
> > I know that unix systems use the crypt function to encrypt a
> >password.
> >According to the man page, this function uses a variation of the DES
> >algorithm
> >using two extra characters as salt.
>
> >Where can i find the description of the algorithm the crypt function
> >uses, so i could implement it?
>
> >I would like also the DES algorithm.I have searched, but i have found
> >general descriptions of it.
>
> It contains a lot more than just the DES algorithm, but you may want to
> download the source for OpenSSL from http://www.openssl.org/ . It is
> based on Eric Young's SSLeay library.
You'll find some great, efficient, implementations there. In particular
the DES implementation is quite impressive. But it is also quite
incomprehensible unless you (a) understand DES well, and (b) spend a
*lot*
of time analyzing what he's doing.
If you want to learn how DES works, reading Eric's code is not the way
to go. That would be similar to reading a compiler as a way to learn
a new programming language... :-) Instead, read the DES standard, or
a textbook such as Applied Cryptography.
The DES standard (FIPS 46-3) is quite short, so why not start there?
http://csrc.nist.gov/fips/fips46-3.pdf And yes, rev 3 is approved
according to that document, October 25 1999.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Cryptography Exporting?
Date: Fri, 14 Jan 2000 15:54:39 -0500
"NFN NMI L." wrote:
>
> Hi. I read:
> http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> And was quite confused. So, what the heck are the rules now? I'm curious
> because I have a 1024-bit RSA program I'll be releasing soon.
What you read are DRAFT rules. You should wait a few days to see
the real rules as published by the feds.
If you're going over 512 bits RSA you might as well go up to 2048 or
better, no sense in stopping halfway.
Chances are you'll have to get your software reviewed first, unless
you're
going to release the source code as open source or the like.
paul
------------------------------
Date: Fri, 14 Jan 2000 20:58:03 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encryption Keys
=====BEGIN PGP SIGNED MESSAGE=====
Paul Roy wrote:
>
> Hello All ---
> I found this on Hacker News. Rather disturbing? Comments?
>
[...]
> Researchers at nCipher in Cambridge, England have found a way to
> easily find encryption keys on target systems. The technology centers
> on this: There is a general assumption that encryption keys will be
> impossible to find because they are buried in servers crowded with
> similar strings of code.
I don't know of anyone with a clue about the subject who made that
assumption.
> What the researchers discovered, however, is that encryption keys
> are more random than other data stored in servers. To find the
> encryption key, one need only search for abnormally random data.
This was also known before the nCipher research (although it is not
just a matter of "only search[ing] for abnormally random data";
there may be a lot of false matches that have to be filtered out).
However, if the media fuss about nCipher's work causes more people
to insist on their server applications being run on a separate physical
machine to anyone else's, it will have been useful.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOH+NpjkCAxeYt5gVAQGAyQf9EElOFseX3SIkZNYSViAJ8ZZAcrfvX7aG
KFhJDip8HGE57MU81j5eyltsQJtRADVNT6Jk0PwrjMxdmb4rb3rRKWaOUblm9ql7
4sYdhBrGbF+JyIb0nPoHSgnos4iCX6EYxzFJFu9ZmW9Fwr51qKn/XqBGaijGt3Kf
wos1RMoMGots3QGo2BRorv2uBVn3h7050dVHw7Gcoq+X8mc6w27gLb4PkPdIgEgN
pPIFBNAnQW1fqQJ6l46Knt4aKBhsBQmz92P0P3nvzTwaxBHkpqVOVPzCCa5xxAle
Rwz8jeGy7eO/c3t6m9Y+HOBhbhweZcQVIPxWl2wPoUEaVqZSz8pZqw==
=vxsl
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (ray gaudia)
Subject: Does this internet encryption item transfer scenario make sense?
Date: Fri, 14 Jan 2000 21:07:33 GMT
Does this appear to be uncrackable?
Internet transaction:
Initiator creates a single key of a random 128 bits.
Initiator creates a transaction number, separate from the key.
Initiator emails via SSL the transaction number to a third party,
store and forward site, that waits for the document to arrive.
Initiator faxes the transaction number to the sender and the
recipient.
Initiator faxes that single encryption/decryption key in separate
emails to the sender and the receiver (who are part of the
transaction.)
The sender encrypts with the 128 bit key.
(We don't know if software is out there to cause the encryption to
occur with ease. Any suggestion will be helpful.
The sender transmits the encrypted item to a third party store and
forward server via ssl, together with the transaction number in the
clear.
The 3rd party store and forward will then transmit the encrypted file
to the recipient when the recipient presents the transaction number
via an email to the store and forward, requesting release of the item.
Our presumption. Because the encrypt/decrypt key is sent via fax, the
document after encryption cannot be opened other than by the recipient
and by the initiator. No sniffer or thief can access the key over the
internet. The transaction number alone will not decrypt the item.
The item can be "stolen" off of the internet, but it cannot be
decrypted without the key. The key never crosses over the internet.
If the initiator were to email the key to the sender or the receiver,
this secrecy chain would be exposed and therefore, an aggressive
sniffer could camp on the sender's or recipient's/ISP's flow, and
collect all the keys, and then just try each transfer with all the
keys the sniffer has collected.
If the key is not sent over the internet, and if it is random to the
sender and the recipient, who are also random, and if the encrypted
item is sent to a 3rd party bearing only a transaction number, is this
sufficient to protect the transaction?
Is there an alternative that would be more elegant?
This may be puerile, but this is the scenario we think can combine the
best of both worlds, the efficiency of the internet, and the privacy
of the point to point POTS.
You are invited to rip this apart, constructively if you don't mind
:-).
TIA, GAUDIA
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 15:41:53 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Fri, 14 Jan 2000 10:27:17 -0700, "John E. Kuslich" <[EMAIL PROTECTED]> wrote:
>
> >These regulations are an abomination and should be completely removed by
> >an act of Congress.
> >
> >After all, we do have the best Congress money can buy. Perhaps we
> >should tell BXA to stick it in their EAR.
>
> Quite. How much does it cost to buy a congressman these days?
>
Probably less that it takes to buy a Presidency.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Date: Fri, 14 Jan 2000 21:50:53 GMT
John Savard wrote:
> Kent Briggs <[EMAIL PROTECTED]> wrote, in part:
>
> >But based on the
> >comments here, the period is not easy to calculate so that kills that idea.
>
> There is a way to do a quadratic congruential generator modulo 2^n
> guaranteed to have maximal period
How?
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 15:03:59 -0700
I am embarrassed all right. As should every citizen of this land who has
to see that mendacious laughing stock stand up for a great nation. We
should all be embarrassed.
And as for you...Why the heck the Virgin Islands? How in the heck can
they stay virgin for so long. Sounds like a pretty stern place for a
vacation?
You...you DEMOCRAT! :-)
Or take Extra Virgin olive oil. How can anything be EXTRA virgin?
That's all, I promise. I have had my little rant. Now back to cracking
passwords.
...Sound of the lid coming down..."clank"
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
JPeschel wrote:
>
> John E. Kuslich [EMAIL PROTECTED] writes, in part:
>
> >What kind of government can get away with making laws the meaning of
> >which are not clear until such time as one is prosecuted for violating
> >such laws?
>
> then rants, in part:
>
> >Perhaps the answer is a government led by a man who can lie under oath,
> >violate his marriage vows with a post pubescent bimbo in the Oval
> >Office, and keep a Cabinet together after using them to lie to the
> >public and assist in the cover-up of his immoral acts.
> >
>
> Put a lid on it, John. You only embarrass yourself.
>
> Joe
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
------------------------------
From: Jeff Williams <[EMAIL PROTECTED]>
Subject: Re: Cryptography Exporting?
Date: Fri, 14 Jan 2000 15:58:45 -0600
==============4D358A05789531ADC7EC9AFF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
It's nearly the end of the week. I'm tired. Was this meant to be funny?
Specifically, how do I make certain that a Cuban, Iraqi, etc, cannot
download the source? How much effort, on my part, to prevent such
an occurrance is considered to be legally adequate? If this requirement
is thoroughly unreasonable (and bureaucrats are frequently
unreasonable) how does this improve things?
Jeff
Mike Rosing wrote:
> NFN NMI L. wrote:
> >
> > Hi. I read:
> > http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> > And was quite confused. So, what the heck are the rules now? I'm curious
> > because I have a 1024-bit RSA program I'll be releasing soon.
>
> Is it open source? Then all you have to do is tell BXA the URL.
> No reviews required! If it's for sale, then you have to file
> once, and make sure Cuba, Iraq, etc. can't download it. I'm
> pretty amazed, but it looks like they actually figured out there's
> no stopping bits over the net.
>
> Patience, persistence, truth,
> Dr. mike
--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?
==============4D358A05789531ADC7EC9AFF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
It's nearly the end of the week. I'm tired. Was this meant
to be funny?
<br>Specifically, how do I make certain that a Cuban, Iraqi, etc, cannot
<br>download the source? How much effort, on my part, to prevent
such
<br>an occurrance is considered to be legally adequate? If this requirement
<br>is thoroughly unreasonable (and bureaucrats are frequently
<br>unreasonable) how does this improve things?
<p>Jeff
<br>
<p>Mike Rosing wrote:
<blockquote TYPE=CITE>NFN NMI L. wrote:
<br>>
<br>> Hi. I read:
<br>> <a
href="http://www.cdt.org/crypto/admin/000110cryptoregs.shtml">http://www.cdt.org/crypto/admin/000110cryptoregs.shtml</a>
<br>> And was quite confused. So, what the heck are the rules now? I'm
curious
<br>> because I have a 1024-bit RSA program I'll be releasing soon.
<p>Is it open source? Then all you have to do is tell BXA the URL.
<br>No reviews required! If it's for sale, then you have to file
<br>once, and make sure Cuba, Iraq, etc. can't download it. I'm
<br>pretty amazed, but it looks like they actually figured out there's
<br>no stopping bits over the net.
<p>Patience, persistence, truth,
<br>Dr. mike</blockquote>
<pre>--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?</pre>
</html>
==============4D358A05789531ADC7EC9AFF==
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Cryptography Exporting?
Date: Fri, 14 Jan 2000 15:34:59 -0700
Paul Koning wrote:
>
> "NFN NMI L." wrote:
> >
> > Hi. I read:
> > http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> > And was quite confused. So, what the heck are the rules now? I'm curious
> > because I have a 1024-bit RSA program I'll be releasing soon.
>
> What you read are DRAFT rules. You should wait a few days to see
> the real rules as published by the feds.
The real rules were published today (and are valid as of today), and as far as
I can tell, they are identical to those draft rules. See
http://www.bxa.doc.gov/Encryption/regs.htm for the real rules.
--
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Fri, 14 Jan 2000 20:57:34 GMT
Mike McCarty wrote:
> Actually, you misstate the situation. The state is such that poor
> translations *always* occur. Good machine translation has yet to be
> demonstrated, ever.
*Sometimes* the better MT programs actually translate a limited
sample correctly, it's just that they can't be counted on to always
do so.
> You show your bias by using the word "yet". Why not just say "Machines
> cannot do that at present"?
Because the importance of the task is evident, and people continue
to work on the problem.
> Good machine translation, like profitable fusion power, seems always 20
> years away. It was 20 years away in the 50s. It is still 20 years away.
> For all I know, it will always be 20 years away.
The same may be said for other "AI" claims. This has been due
more to optimistic, wishful thinking by AI researchers, who
extrapolated their limited success on toy problems to the general
problem, without taking into account the fact that the general
problem would require some new, undiscovered approach.
------------------------------
Date: 14 Jan 2000 23:00:03 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Terry Ritter writes:
> On 13 Jan 2000 21:40:16 -0000, in
> <[EMAIL PROTECTED]>, in sci.crypt lcs Mixmaster
> Remailer <[EMAIL PROTECTED]> wrote:
> >The advice to choose moduli with guaranteed long cycles, and to choose
> >seeds that way, is completely useless. It is like the advice you
> >used to hear to choose "strong" RSA moduli by careful choice of p and q.
> >No one does this any more, because it has been proven to be pointless.
> >The attacks this was meant to protect against are not effective against
> >moduli of the sizes in use today.
> >
> >The same thing is true of concern about cycle lengths.
>
> On the contrary: Worry about cycle lengths is fundamental to security
> in (conventional) stream cipher usage: If we use a cycle which repeats
> quickly, the system is insecure, no matter how impossible it may be to
> factor N.
>
> As far as I know, the current thinking is that the *probability* that
> a random x0 will be on a short cycle is very low. Fine so far.
>
> But an admitted *possibility* of weakness -- no matter how small --
> shows there is no *proof* of strength, unless "proof" no longer
> carries an absolute assurance.
No, there is still a proof of strength, and it is the same proof you
have always had with BBS. The BBS RNG is as strong as the resistance of
the RSA modulus to factoring. That is all you have ever had with BBS.
The proof of strength is conditional, as all such proofs must be today.
It is a proof by reduction, where the strength of BBS is reduced to
the strength of the modulus. If RSA moduli turn out to be factorable,
BBS will not be secure.
So, yes, there is a possibility of weakness. Factoring may turn out to
be easy. No amount of care in picking long cycles will avoid this.
And there is no worse weakness. Short cycles are not a threat to
RSA moduli. If they were, the RSA assumption would be violated.
The earlier message included a simple proof that if random elements
with short cycles can be found, the modulus can be factored. In fact
this follows from the BBS result itself, because if such short cycles
exist then the prover has an advantage in predicting bits of the RNG,
which they show allows the modulus to be factored.
> The whole point in using BB&S is to have a *proof* of strength. Maybe
> that proof ultimately will be shown to be flawed; I don't know. But
> whatever assurance that proof does carry comes from the *real* BB&S
> design. Not following the whole recipe in BB&S means that we do not
> have BB&S, we have something else. Maybe that something else is just
> as good, in which case it should have its own construction, name, and
> proof. But using the term "BB&S" when we do not follow the BB&S
> recipe seems little more than an appalling deception.
BBS proves that with randomly chosen x and an RSA modulus (with
p=q=3 mod 4) then if anyone can predict the next bit with even an
epsilon advantage, the modulus can be factored. This is the proof
of strength. If you assume that RSA is secure, BBS with a random x
is secure. Cycle-counting can gain you no more strength than that.
It is a pointless and counter-productive effort.
------------------------------
Date: 14 Jan 2000 22:40:11 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Blum, Blum, Shub generator
Tim Tyler writes:
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> : Concerns about cycle lengths are misplaced. [...]
> : Therefore, it follows from the RSA assumption that finding short cycles
> : is impossible, for moduli large enough that factorization is intractable.
>
> Without this it appears that you don't get the "proven" security discussed
> in the original work. You wind up with a finite change of getting a rather
> weak stream of data.
>
> I thought the "proven security" was a BBS selling point. Should your
> algorithm still be described as BBS if it uses a different set of
> constraints on the primes?
No, you still have proven security.
Consider: what security is proven with BBS? Is the RNG proven
unpredictable? Not at all! After all, P may be equal to NP in which
case any deterministic RNG can be predicted in polynomial time.
What is proven, in fact, is that if the RSA modulus is unfactorable,
then the RNG is unpredictable. In other words, the security of the RNG
reduces to the security of RSA.
And this proof is done in the context of a RANDOM choice of seeds.
There is no need to choose a special seed, or to try to factor phi(n), in
order to determine that BBS is secure. All you have to do is to choose an
RSA modulus which has an adequate safety factor (see www.cryptosavvy.com
for advice). Then choose a random seed, and go.
The earlier message provided a proof that if you can find short cycles
with random seeds, then you can factor the RSA modulus. It follows,
therefore, that if you are not concerned about your RSA modulus being
factored, you should not be concerned about short cycles. The thrust of
the proof was based on the BBS paper, although those authors prove the
more difficult result that even a slight edge in predicting the next
bit of the RNG allows you to factor. Of course, this result implies
the simpler one, because if a cycle exists then you can predict the next
bit with perfect accuracy.
------------------------------
** 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
******************************
