Cryptography-Digest Digest #180, Volume #11 Tue, 22 Feb 00 10:13:01 EST
Contents:
Re: How Useful is Encryption as Long as NSA Exists? (Dave Hazelwood)
Re: Keys & Passwords. ("r.e.s.")
Re: EOF in cipher??? (Runu Knips)
Velvet Sweat Shop in Excel (Pavel Semjanov)
Re: NIST publishes AES source code on web (Mok-Kong Shen)
Re: US secret agents work at Microsoft claims French intelligence report (jungle)
Re: role of Prime Numbers in cryptography (DJohn37050)
Large Int Lib for Delphi ("ink")
[OT] Re: NIST publishes AES source code on web (Paul Crowley)
Re: I will bring PGP to the masses h15 (Richard Herring)
Re: How Useful is Encryption as Long as NSA Exists? (Jeff Williams)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 06:02:05 GMT
A further indication that the NSA/Microsoft rumor may hold truth is
the fact that the Chinese government has recently outlawed the use of
Windows/2000 in all its offices.
Now there are probably good commercial reasons for weaning itself off
MS products since huge amounts of money are spent on it but I doubt
that with a trade surplus in their favor that is already an
embarrassment that is the real reason.
Fear of espionage is a much more likely one and maybe they know
something we don't?
[EMAIL PROTECTED] wrote:
>As you all know there are rumors that Microsoft Windows products have
>an NSA backdoor. Why not, if throught history the NSA has always
>convinced foreign crypto companies to have one too. Check out an
>interesting article on:
>
>http://mediafilter.org/caq/cryptogate/
>
>Currently, U.S. companies can export strong crypto but the product must
>continuously go through government "review," whatever that means. Many
>argue that these domestic requirements are useless because someone
>could buy strong crypto from Israel, Ireland, etc., that has not
>been "touched" by the U.S. government. But can we say for sure that the
>NSA's fingers have not been all over these products as well, especially
>when there is plenty of evidence to the contrary?
>
>Maybe a drug dealer living in Costa Rica, who has fled the U.S. years
>before, is using encryption software from a non-U.S. country in some of
>his daily operations, thinking that nobody is listening, when the U.S.
>actually has the key. What protection is a safe with an infinite number
>of combinations if your enemy has the secret code? Code breaking ceases
>to become an issue.
>
>Furthermore, even if the drug dealer in question is lucky enough to be
>using crypto from a country that has not been pursuaded by the U.S. to
>cough up the key, he is probably still using Windows, and might still
>have some of his data vulnerable.
>
>Even though all this is a big "what if" scenario, can someone (say,
>living outside of the U.S.) using a Windows operating system be
>positively sure that the U.S. cannot decrypt his encrypted
>communication or the encrypted information inside his computer, except
>by guessing the password (which is the most difficult way)? how about
>access his/her files through Microsoft?
>
>Thanks.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
Date: Mon, 21 Feb 2000 23:12:51 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote ...
[...]
: I have a system
: limiting the length of password input to 8 characters (key strokes).
: If I use a hashing program to hash a long parsepharse (that
: presumably has more than 8*256 bits of entropy) and get an
: appropriate sequence of hexs, how should I 'optimally' turn that hex
: sequence to the 8 characters that I am going to type in. I could
: convert each pair of hexs (together 8 bits) to a symbol of the
: (8-bit) ASCII, but not everyone of these could be conveniently
: keyed in. Suppose I want to limit the input characters to the set
: {A-Z, a-z, 0-9), consisting of 62 allowable characters, what should
: I 'best' do to the hex sequence obtained from my hashing program
: for the purpose? (If mapping, how is that mapping to be done?)
: I must admit that I don't yet quite understand the last part of
: your paragraph above. If I map each hex to one character of my set
: (an obvious choice is the 'identiy' mapping), then I'll get
: only 8*4 bits of entropy in my password, don't I? Thanks for
: your help in advance.
A simple way to do this would be to use a 64-symbol alphabet,
say {A-Z, a-z, 0-9, /, .}. If a random "hex value" X is
uniformly distributed in the range 0..255, then X mod 64 is
uniformly distributed in the range 0..63. So to convert your
string of hex values to the 64-symbol alphabet with maximum
entropy, you could just write some code to return "A" if X
mod 64 is 0, "B" if X mod 64 is 1, ..., "." if X mod 64 is 63.
If the string of hex values are iid uniform, then 8 of them
will produce a string of 8 chars in the 64-character alphabet,
having entropy of 8*log2(64) = 48 bits. (I think that if you
use an alphabet with 62 characters instead of 64, then the
solution will be somewhat less straightforward.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
Date: Tue, 22 Feb 2000 09:09:11 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" schrieb:
>
> Mok-Kong Shen wrote:
> > ... Imagine the case I am going to have a major surgical operation
> > and I hear the surgeons disputing about which knifes should
> > properly be used!
>
> If that were an Internet newsgroup dispute, you would be a fool
> to think that it was an argument among surgeons. It would be an
> argument among perhaps a surgeon or two (who would agree on the
> main points) and a bunch of people who would not be allowed
> anywhere near a real operating room (except as patients).
I do not think that many of the people which argued here aren't
experienced in programming. Too, as long as you just write (for
text files):
_____________________________________
int ch;
FILE *f;
f = fopen (name, "r");
while ((ch = getc (f)) != EOF) {
...
}
_____________________________________
you're safe according to (AFAIK) ANYONE which posted here.
My version for binary files would be either:
_____________________________________
int ch;
FILE *f;
! f = fopen (name, "r"
! #ifndef __unix__ /* many unices can't handle the "b" */
! "b" /* even if its ISO C - for example, */
! #endif /* OSF1/DEC UNIX/True64 Unix barks. */
! );
while ((ch = getc (f)) != EOF) {
...
}
_____________________________________
OR:
_____________________________________
! char ch;
FILE *f;
f = fopen (name, "r");
! while (fread (&ch, 1, 1, f) == 1) {
...
}
_____________________________________
Btw, I've never checked the later code on Windows...
argl, I fear it would lead to problems.
------------------------------
From: Pavel Semjanov <[EMAIL PROTECTED]>
Subject: Velvet Sweat Shop in Excel
Date: Tue, 22 Feb 2000 12:36:05 +0300
Hello!
When you save .xls file (Excel 97 & 2000) with password
'VelvetSweatshop' and next try to open this file, the password will not
be asked. It's not a serious bug, I think, but the question is: WHY???
--
SY / C4acT/\uBo Pavel Semjanov
_ _ _ http://www.ssl.stu.neva.ru/psw/
| | |-| |_|_| |-| 2:5030/145.17@fidonet
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Tue, 22 Feb 2000 11:28:29 +0100
Brian Gladman wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
>
> > Brian Gladman wrote:
>
> [snip]
>
> > First, you didn't seem to have answered my point about 'informal'.
>
> What I meant by informal is that the WA does not come into effect like a
> Treaty does, dependent on whether national legislatures vote it into effect.
> The WA simply is intended as a guide to promote consistent national
> legislation on the part of participant nations but they are under no legal
> obligation to do anything to implement its provisions.
I am afraid your definition of 'informal' is not what most people
understand under that term. A lecture delivered at a conference
is a 'formal' presentation, while discussions at coffee breaks
are 'informal' exchanges of opinions, no matter how important these
are scientifically.
>
> > Second, your paper argued with the help of the statement of purpose
> > of WA that it 'will not impede bona fide civil transactions' to
> > establish your claim that ANY software used for civil purposes is
> > exempted from control. Am I right?
>
> No, thats just one of many reasons given in the paper. The argument does not
> rely on just one point.
What else? Could you cite one sentence of the 'many' that concerns
one another essential point establishing your claim that cryptos
for commercial purposes are generally exempted from control? I
can't see any such point at all. And the one point is simply
entirely insufficient to support your claim, as I have argued.
>
> > the general statement doesn't apply. Now from the document entitled
> > 'List of Dual-Use Goods and Technologies and Munitions List',
> > Category 5, Part 1, 5.D.1, Software, and Category 5, Part 2, Note 3,
> > isn't very clear that crypto software in symmetric algorithms with
> > key length greater than 56 bits is under control? If you think it
> > is not, please kindly show your arguments through quoting the
>
> Whether something is controlled is determined by your national laws not by
> the WA. I am completely free to export commodity crypto products of any
> strength to anyone provided they are not in a short list of 'nasty'
> countries because this is what UK national law says.
We are discussing the content of WA, don't we? As you also said,
a country may incorporate the WA into its laws or not. What control
would take place, if WA is implemented? That's the very topic that
we are currently discussing, isn't it? Certainly, as long as the
content of WA is not yet in the current law of your country, the
current law governs and the WA has no effect. If the possibility
of WA being implemented sometime in the future doesn't interest you,
I must question why you have taken part in the current discussion at
all (since WA doesn't affect you anyway). Why didn't you show that
the paragraphes I cited do not contradict you claim that cryptos
for commercial purposed are exempted? In a scientific debate
one attempts to 'clearly' show with counter-arguments that the
arguments of the partner are logically invalid or else must frankly
concede.
> > relelvant text (or exact position) from that document together with
> > your reasoning (the logic establishing your claim). May I stress
> > once again that your argument based on 'impediment' only is not
> > sufficient for an exemption in my conviction. If there are exemptions
> > than in any legal documents such exemptions, being exceptions, should
> > be clearly stated as exemptions and not left to the reader to
> > excercise his reasoning of what should be included within the scope
> > of the meaing of a word in a statement of general nature and what
> > should be excluded. (In other words, the reader is not permitted
> > to be a 'philosopher'.)
>
> You can choose to debate the detail if you wish but not with me since I
> reject your terms for the debate. I prefer to base my argument on the
> principles involved since if these principles can be shown not to apply to
> commerial crypto then the details are of no importance since they are not
> going to be applied nationally in many countries.
>
> The huge differences in the national interpretations of the WA do not depend
> on a different reading of the details. They are there because different
> nations have looked at the principles involved and drawn very different
> conclusions about any WA obligations they might have to restrict commercial
> crypto.
You have entirely ignored the general conventions of documentations.
Everything has exceptions but see how these are handled in any
documents or books. Look for example in science. A (general) bird
is said in biology to have wings and can fly. But penguins cannot
fly. You can't say that because penguins are classified as birds
it follows that they can fly. (In AI, dealing with such matters is
known to require a bit of care and work.) Or consider laws. Any
person in a democratic country has freedom of speech. But you
can't arbitrarily say bad words to other persons and consider that
to be within your freedom of speech. (At least in Germany doing
that to a policeman would have immediate consequences.) Do you see
the point? Yes, you can with good concrete arguments point out that
certain part of WA does not conform to certain general principles
that it proclaims. But this would be the same as the case in which
you discover that certain specific law does not conform to the
constitutions. Even in that case, as long as that (in your opinon
defective) specific law has not been revised, that specific law rules!
In the present context, the paragraphs I cited from WA explcitly
and clearly show that symmetric algorithms with more than 56 key bits
are under control. As long as these paragraphs are there in black
and white, nothing, whether through citing WA's general principles
or citing any other documents (including your own country's
consitutions or the bible) can change the fact that the WA puts these
algorithms under control. Whether any country actually implements WA
is, of course, evidently an entirely another matter.
I like to invite readers of this thread to access you web page
http://www.brian.gladman.btinternet.co.uk/papers/index.html
and the WA documents at
http://www.wassenaar.org
and see whether what I said is true.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: US secret agents work at Microsoft claims French intelligence report
Date: Tue, 22 Feb 2000 13:02:32 GMT
do you have link for this source ?
Dave Hazelwood wrote:
>
> An intelligence report out of France has accused US secret agents of
> collaborating with computer giant Microsoft in developing a software
> that would allow Washington to spy on communications around the world.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: role of Prime Numbers in cryptography
Date: 22 Feb 2000 13:48:09 GMT
There are many subtleties, see IEEE P1363.
Don Johnson
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Large Int Lib for Delphi
Date: Tue, 22 Feb 2000 14:59:56 +0100
Does anyone know of a large integer library for
Borland/Inprise Delphi, Version 3 or higher? A
Turbo Pascal ;-) version would also be welcome,
as the language/compiler is essentially the same.
Thanks a lot in advance, kind regards
Kurt
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: [OT] Re: NIST publishes AES source code on web
Date: 22 Feb 2000 08:03:25 -0000
[EMAIL PROTECTED] (John Savard) writes:
> >The drug problem
> >is a social and psychological problem, not something that can
> >be solved by any amount of law enforcement. The US should
> >know better, from its previous dalliance with nationwide
> >alcohol prohibition, but people don't learn from history and
> >they seek easy solutions to problems that don't have easy
> >solutions.
>
> Since this isn't even talk.politics.crypto, I comment with
> trepidation.
Probably best not to - it's just too far off topic for a "sci"
newsgroup. I disagree with you fairly thoroughly, but I'll do that in
private email.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: I will bring PGP to the masses h15
Date: 22 Feb 2000 14:10:59 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, wtshaw
([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
> <[EMAIL PROTECTED]> wrote:
> > PGP_for_ALL wrote:
> > > I will bring PGP to the masses
> >
> > The only way the typical PC user is going to use PGP is for it to
> > be the *default* mode of his e-mail interface *as bundled* with his
> > computer or ISP package when he purchases it.
> Or, have AOL add it to their package, a kinda remote possibility, don't
> you think?
Well, Demon have done it in the UK. Turnpike 5 (now in beta)
has a pretty seamless interface to PGP. Unfortunately
although Demon own one of the best news/mail packages around,
they don't seem interested in marketing it.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Jeff Williams <[EMAIL PROTECTED]>
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 07:59:46 -0600
==============A4B20D82F0097AB223FBA866
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What you point out is a fair enough question: who can I trust?
At some point you have to decide to trust someone. Otherwise, you
might as well build yourself a dinky little cabin out in Montana (or
perhaps Wyoming) and keep to yourself until the Feds raid you.
As far as drug dealers, given the funding they have, I suspect that
they could have their own encryption software made to spec.
Paranoia is our friend.
[EMAIL PROTECTED] wrote:
> As you all know there are rumors that Microsoft Windows products have
> an NSA backdoor. Why not, if throught history the NSA has always
> convinced foreign crypto companies to have one too. Check out an
> interesting article on:
>
> http://mediafilter.org/caq/cryptogate/
>
> Currently, U.S. companies can export strong crypto but the product must
> continuously go through government "review," whatever that means. Many
> argue that these domestic requirements are useless because someone
> could buy strong crypto from Israel, Ireland, etc., that has not
> been "touched" by the U.S. government. But can we say for sure that the
> NSA's fingers have not been all over these products as well, especially
> when there is plenty of evidence to the contrary?
>
> Maybe a drug dealer living in Costa Rica, who has fled the U.S. years
> before, is using encryption software from a non-U.S. country in some of
> his daily operations, thinking that nobody is listening, when the U.S.
> actually has the key. What protection is a safe with an infinite number
> of combinations if your enemy has the secret code? Code breaking ceases
> to become an issue.
>
> Furthermore, even if the drug dealer in question is lucky enough to be
> using crypto from a country that has not been pursuaded by the U.S. to
> cough up the key, he is probably still using Windows, and might still
> have some of his data vulnerable.
>
> Even though all this is a big "what if" scenario, can someone (say,
> living outside of the U.S.) using a Windows operating system be
> positively sure that the U.S. cannot decrypt his encrypted
> communication or the encrypted information inside his computer, except
> by guessing the password (which is the most difficult way)? how about
> access his/her files through Microsoft?
>
> Thanks.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?
==============A4B20D82F0097AB223FBA866
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
What you point out is a fair enough question: who can I trust?
<p>At some point you have to decide to trust someone. Otherwise,
you
<br>might as well build yourself a dinky little cabin out in Montana (or
<br>perhaps Wyoming) and keep to yourself until the Feds raid you.
<p>As far as drug dealers, given the funding they have, I suspect that
<br>they could have their own encryption software made to spec.
<p>Paranoia is our friend.
<br>
<p>[EMAIL PROTECTED] wrote:
<blockquote TYPE=CITE>As you all know there are rumors that Microsoft Windows
products have
<br>an NSA backdoor. Why not, if throught history the NSA has always
<br>convinced foreign crypto companies to have one too. Check out an
<br>interesting article on:
<p><a
href="http://mediafilter.org/caq/cryptogate/">http://mediafilter.org/caq/cryptogate/</a>
<p>Currently, U.S. companies can export strong crypto but the product must
<br>continuously go through government "review," whatever that means. Many
<br>argue that these domestic requirements are useless because someone
<br>could buy strong crypto from Israel, Ireland, etc., that has not
<br>been "touched" by the U.S. government. But can we say for sure that
the
<br>NSA's fingers have not been all over these products as well, especially
<br>when there is plenty of evidence to the contrary?
<p>Maybe a drug dealer living in Costa Rica, who has fled the U.S. years
<br>before, is using encryption software from a non-U.S. country in some
of
<br>his daily operations, thinking that nobody is listening, when the U.S.
<br>actually has the key. What protection is a safe with an infinite number
<br>of combinations if your enemy has the secret code? Code breaking ceases
<br>to become an issue.
<p>Furthermore, even if the drug dealer in question is lucky enough to
be
<br>using crypto from a country that has not been pursuaded by the U.S.
to
<br>cough up the key, he is probably still using Windows, and might still
<br>have some of his data vulnerable.
<p>Even though all this is a big "what if" scenario, can someone (say,
<br>living outside of the U.S.) using a Windows operating system be
<br>positively sure that the U.S. cannot decrypt his encrypted
<br>communication or the encrypted information inside his computer, except
<br>by guessing the password (which is the most difficult way)? how about
<br>access his/her files through Microsoft?
<p>Thanks.
<p>Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a>
<br>Before you buy.</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>
==============A4B20D82F0097AB223FBA866==
------------------------------
** 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
******************************
