Cryptography-Digest Digest #983, Volume #9 Wed, 4 Aug 99 03:13:04 EDT
Contents:
Re: Americans abroad/Encryption rules? (David A Molnar)
Books on cryptography/security at discounted rates... (Anuj Seth)
Re: [Q] Why is pub key cert. secure & free from spoofing? (David A Molnar)
Help with caculation ([EMAIL PROTECTED])
Re: What the hell is XOR? (John M. Gamble)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(John M. Gamble)
Re: What the hell is XOR? (John M. Gamble)
Re: What the hell is XOR? (John M. Gamble)
Re: The security of TEA ("Rick Braddam")
Is this procedure sound ? (Anonymous)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Jerry Coffin)
Question about Information Theory (Coms 1003)
Re: Is the output of 3DES really pseudorandom??? (Michelle Davis)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Americans abroad/Encryption rules?
Date: 4 Aug 1999 04:24:42 GMT
W.G. Unruh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Dmitri Alperovitch) writes:
>>I understand that, but once you are out of the States, you are no longer bound
>>by the the country's laws and, therefore, I don't think they would have the
> Oh yes you are. A US citizen is bound by the laws of the USA wherever in the
> world that person is located.
indeed. and we pay taxes for the privilege, too. plus experience the
wonders of double taxation in some jurisdictions.
At least the definition of "export" for cryptographic software no longer
includes 'releasing to a foreign national', or else I might be in jail
now.
-former Saudi expat
------------------------------
From: Anuj Seth <[EMAIL PROTECTED]>
Subject: Books on cryptography/security at discounted rates...
Date: Tue, 03 Aug 1999 20:02:18 -0800
Hi,
The "Online Bookstore" at the Data Encryption Page has been
updated. There is a huge collection of books on
cryptography/security up for grabs at discounted rates from
Amazon.com.
Visit the site today and place your order....
The URL is:
http://www.geocities.com/SiliconValley/Network/2811/
With Regards,
Anuj Seth
Webmaster, The Data Encryption Page
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: 4 Aug 1999 04:55:53 GMT
Greg <[EMAIL PROTECTED]> wrote:
> Let me make it really simple: The accuracy of a certificate is
> inversely related to your ability to bribe an individual within the
> CA. Now all of the sudden, security flies out the window, but CA are
> pushed along anyway BECAUSE E-COMMERCE MEANS $$$!
With all the tres chic secret sharing protocols out there, perhaps some CA
might take steps to ensure that you would have to bribe a coalition of ppl
instead of a single person. Maybe make sure you bribe the right people and
not the wrong ones.
Let's say we have a secret sharing scheme with an "access structure" with
the following properties :
* Consists of "access groupings" whose union covers all employees
of the CA; each grouping contains a subset of employees. Groupings
may or may not be disjoint.
* Each grouping is divided into a "good subset" and a "bad
subset." These are disjoint.
* To reconstruct the secret, the shares of everyone in the
good subset of a grouping are required.
* If a single share from a member of the "bad subset" is
present, reconstruction fails.
so far, this is doable -- refs in Applied Cryptography.
now add :
* After each attempted reconstruction, the access
groupings are randomly rearranged before another
reconstruction may be tried.
* Membership in a good or bad subset cannot be
determined without attempting to reconstruct the
secret.
Seems like this may be doable, don't know how it would be efficient,
should probably see if it's already been done.
Now you need to corrupt a specific (but unknown) subset of the ppl at the
CA to get the secret and sign your key. One problem, of course, is making
sure that legitimate users don't get trapped as well, but maybe there's
some way around that by allowing the honest users not directly involved to
help with a reconstruction somehow.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Help with caculation
Date: Wed, 04 Aug 1999 04:41:20 GMT
Hi,
How should I select the values of e and d if I want to encrypt a message
m of 64 bits, so that a hacker using a 300Mb/s PC can't crack the code
by brute force attack in a month?
RSA Algorithm
n=pq
ed=1 mod (p-1)(q-1)
c=m^e mod n
m=c^d mod n
Thanks,
John
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John M. Gamble)
Subject: Re: What the hell is XOR?
Date: 4 Aug 1999 04:49:01 GMT
In article <7npr8b$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <7nplva$s4o$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>>/*
>>** Swap via the three-xor method, contained in a single line.
>>*/
>>#define swap(a, b) (a ^= (b ^= (a ^= b)))
>>
>>And you'll note that i commented my code, which no one else
>>seems to have bothered. Frankly, if a programmer didn't know
>>the exchange by XOR method (hell, i knew it before i became a
>>programmer), and didn't bother to comment his/her code (but
>>it's obviouse, right? - no, nothing is obvious, espacially at
>>2AM), then i'd have serious doubts about hiring this person.
>>
>> -john
>>
>
>If a programmer didn't know of this hack, I wouldn't hire them.
>Because it's the standard example of why you can't do everything
>in the pre-processor, why C++ templates solve some real problems
>and why clever hacks usually aren't.
>
>If a programmer used this hack as a macro as you do, I'd be very
>unlikely to hire them. It's actually in my old CS lecture notes
>under the title "Don't do this".
>
>swap(i,i).
*Sigh*. As i've noted before, this wasn't the question that i
was addressing. The three-xor-swap was part of the original
message.
>
>Oops.
>
>Even if *you* don't do it, someone else will.
No, no one that i've worked with ever has. I know, hubris,
but still, this comes under the level-of-safety question.
Should programmers know that strcpy() should not be passed
NULL pointers? Should the NULL pointer check have been
built into the function itself? Under current theory i
suspect the answer would be Yes, but there were reasons
to not do this.
>
>If a programmer ever used a hack like that without profiling the
>code and proving it was a performance win ditto.
But that's true of all coding, not just the clever hacks. And,
once again, i'll point out that that wasn't the question that
i was addressing.
>
>And, in a modern OOO processor three chained XORs are likely to
>be slower than a simple temp=a;a=b;b=temp.
>
>The only exception might be in a hand-crafted inner loop where you
>were hellishly short of registers (and then... if you're not doing it
>conditionally you can dupe the code and inline two copies. If you are
>doing it conditionally then you can dupe the code and conditionally
>branch to one or the other. L1 ICache pollution is an issue, but if
>you're optimising to that level, use assembly.)
>
>Clever hacks are interesting to know, but when they run slower,
>are less maintainable and more prone to error than the normal
>way of doing it it's not useful.
>
>Why's this relevant in sci.crypt? Because I see more examples of
>'clever' 'optimised' code in cryptography kernels than anywhere
>else. Some of it is truly elegant, but most of it is mere obfuscation
>which seems to confuse the compilers optimisation phase as much as
>it does the maintainers. Removing the crud actually speeds up the
>code when using a decent optimising compiler.
>
>1) Don't optimise
>2) Don't optimise
>3) Profile before optimising.
>4) Profile *after* 'optimising' too.
>
>Cheers,
> Steve
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
--
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, '227,
any and all unsolicited commercial E-mail sent to this address
is subject to a download and archival fee in the amount of $500
US. E-mailing denotes acceptance of these terms.
------------------------------
From: [EMAIL PROTECTED] (John M. Gamble)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 4 Aug 1999 05:21:43 GMT
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Mr. Leo Yanki wrote:
>>
>> [EMAIL PROTECTED] (Guenther Brunthaler) wrote:
>>
>> >... "byte" ... can have ANY number of bits
>>
>> A byte has exactly eight bits and can have 256 different values. A general
>> term for any size collection of bits is "binary number". Please don't
>> attempt to confuse people by trying to spread your personal redefinitions
>> of commonly used technical terms.
>
>Oh really. I'm using 5-bit baudot code on a 12-bit CPU with 6-bit
>characters. An 8-bit byte is useless to me. _*YOUR*_ definition of a
>byte is not, and never will be definitive. It is probably based on your
>lack of experience with CPU architectures.
>
Wow. How old is this machine anyway?
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
--
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, '227,
any and all unsolicited commercial E-mail sent to this address
is subject to a download and archival fee in the amount of $500
US. E-mailing denotes acceptance of these terms.
------------------------------
From: [EMAIL PROTECTED] (John M. Gamble)
Subject: Re: What the hell is XOR?
Date: 4 Aug 1999 04:17:33 GMT
In article <[EMAIL PROTECTED]>,
Alan J Rosenthal <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (John M. Gamble) writes:
>>fungus <[EMAIL PROTECTED]> wrote:
>>>void swap(int *a, int *b)
>>>{
>>> *a ^= *b;
>>> *b ^= *a;
>>> *a ^= *b;
>>>}
>>>
>>>Will fail if a and b both point to the same int. Watch out
>>>for hard-to-find bugs if you ever do anything like this.
>>>
>>But good heavens, why would you do it like that?
>>
>>/*
>>** Swap via the three-xor method, contained in a single line.
>>*/
>>#define swap(a, b) (a ^= (b ^= (a ^= b)))
>
>This has the identical defect. "swap(x,x)" sets x to 0.
I wasn't answering swap(x,x). Yes, that would have the same
effect, and i note that many people who've responded think
that this is a major defect. I don't agree, on the theory
that an algorithm (or programmer) that would do that has
a major defect.
But, another person sent me e-mail stating that according to
the C (and C++) standard, i can't depend upon the order of
operations, parantheses notwithstanding. So the macro is
not good after all.
Although in "real life" this would have been an inline function
anyway...
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
--
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, '227,
any and all unsolicited commercial E-mail sent to this address
is subject to a download and archival fee in the amount of $500
US. E-mailing denotes acceptance of these terms.
------------------------------
From: [EMAIL PROTECTED] (John M. Gamble)
Subject: Re: What the hell is XOR?
Date: 4 Aug 1999 04:33:25 GMT
In article <[EMAIL PROTECTED]>,
david thompson <[EMAIL PROTECTED]> wrote:
>(mostly OT -- except to the extent that C is suitable
>and popular for implementation of crypto operations)
>
>29 Jul 1999 13:46:18 GMT,
>[EMAIL PROTECTED] (John M. Gamble) responded:
>> In article <[EMAIL PROTECTED]>,
>> fungus <[EMAIL PROTECTED]> wrote:
>... [re swapping object contents by back-and-forth XOR]
>> >And don't forget that doing this via pointers is
>> >dangerous, eg. (in C)
>> >
>> >void swap(int *a, int *b)
>> >{
>> > *a ^= *b;
>> > *b ^= *a;
>> > *a ^= *b;
>> >}
>> >
>> >Will fail if a and b both point to the same int. Watch out
>> >for hard-to-find bugs if you ever do anything like this.
>> >
>> But good heavens, why would you do it like that?
>>
>> /*
>> ** Swap via the three-xor method, contained in a single line.
>> */
>> #define swap(a, b) (a ^= (b ^= (a ^= b)))
>>
>> And you'll note that i commented my code, which no one else
>> seems to have bothered. Frankly, if a programmer didn't know
>> the exchange by XOR method (hell, i knew it before i became a
>> programmer), and didn't bother to comment his/her code (but
>> it's obviouse, right? - no, nothing is obvious, espacially at
>> 2AM), then i'd have serious doubts about hiring this person.
>
>1) Like many other C macros, this will malfunction,
>probably silently, if an argument includes a
>non-idempotent side-effect. It would also
>malfunction if an argument contained an exposed
>operator with precedence below assignment, but
>in this case there is none such (, can't occur).
>
True, and i could argue in return that we don't do
that with our macros, but nevermind.
>2) This single-statement method is technically
>undefined behavior according the the C (or C++) standard,
>which means an implementation is *not* required to
>give the "obviously correct" result *or* diagnose
>the error, and is even permitted to crash or go nuts.
>In the real world, on a machine where XOR (and especially
>XOR with a memory destination) is a single instruction,
>any sensible implementation will execute it as intended;
>and on a machine where XOR has to be synthesized,
>*very likely* it will do nothing worse than storing a
>wrong result, but you probably don't want to use it on
>such a machine anyway because it wouldn't give you the
>performance gain you are presumably seeking.
>
>Before you point to the parentheses, they are only used
>(and are not necessary) for parsing, they do *not*
>completely control the actual sequence of store and fetch.
>See the comp.lang.c FAQ section 3 especially 3.3b, the
>referenced portions of the standard(s), or search c.l.c
>for "sequence point[s]" and you will find thousands
>of threads by other people making this same mistake.
>
This of course is the killer argument, and wipes out
any reason for using the macro. Thank you for noting this.
>fungus' function, which a good compiler can inline,
>avoids these problems, and has only the problem he noted
>and you did nothing to fix -- it doesn't work for
>swapping an object with itself, which no sensible
>programmer does intentionally but sometimes falls out
>as an edge case in more complex algorithms.
I did nothing to "fix" this because that was not what
i was addressing. Furthermore, any algorithm that
displayed such edge case behavior has a bug in it.
(This may be considered to be a unreasonable belief.)
>DScott's original post suggested this (only) in
>(PDP-11) assembler for registers -- which (as
>on most computer architectures) *cannot* alias.
>
>Or in GNU C, you could "force" inlining in a typesafe
>and fully defined manner using a statement expression.
>
>Personally, in C I would declare the pointers
>(not their targets!) const, to document that
>I *want* elision of the pointers when possible,
>although the dataflow analysis here is trivial
>and will almost certainly be done automatically.
>In C++ I would use a reference for the same reason.
>
>3) the comment you claim such pride in adds no information
"...you claim such pride in"? Please, you're reading
in a lot there. I was merely referring to the fact
that the comment was *there*. I grant you that the
comment was simple, but given that i was writing a
simple example, not an essay, it was appropriate to
the situation. I'm sorry, but this is a little petty.
>at all to the code -- we can see it's a single line
>and has three XORs just by glancing at it. I agree
>I wouldn't hire someone who didn't know or at least
>immediately figure out why this method works -- when
>correctly implemented and used -- but neither would I
>hire someone who normally writes comments like that.
>Now a comment like *this* might be useful:
>
> /* this is the only way to persuade the obsolete
> Defecto Mark III.7 compiler to generate optimal
> code for the MIL-BLETCH 1066 processor.
> ** It must be used only for simple 16-bit or 32-bit
> unsigned objects, and be re-checked when porting */
>
>(CCed) david.thompson at but not for trintech.com
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
--
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, '227,
any and all unsolicited commercial E-mail sent to this address
is subject to a download and archival fee in the amount of $500
US. E-mailing denotes acceptance of these terms.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: The security of TEA
Date: Tue, 3 Aug 1999 23:13:27 -0500
JPeschel <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] writes:
>
> >BTW the reason I said the above is because everyone talks about how
> >strong algorithm X is but never on how to use the algorithm. People
> >should ask 'is this application of algorithm X' secure ...
> >
> People sometimes do ask about a particular
> application. Most of the folks here,
> however, don't, for one reason or another,
> reverse-engineer programs. So, instead,
> respondents here will usually ask the
> poster if the source code is available.
>
> Joe
I think what Tom is saying is that people don't post code and ask if their own use of
algorithm X is secure, and if so, I agree with
him. You also don't see any examples of good or bad use of an algorithm in an
application. Occasionally, you see a remark about a
certain application being weak because it doesn't wipe the password or phrase as soon
as possible after it is entered, exposing the
password unnecessarily.
You also don't read much from anyone who has found ways to work around some of the
weaknesses in Windows. Maybe the problems with
Windows are too tough, or maybe it's just that no one is interested because there are
easier operating systems to work with, from a
security point of view.
Just one person's 2 cents worth, and probably overvalued at that. I've got to go study
the Windows keyboard driver... I may have
thought of a way to prevent password snooping, or at least make it very difficult.
Back to lurking...
Rick
------------------------------
Date: Wed, 4 Aug 1999 08:16:21 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Is this procedure sound ?
Hello All,
I would like to know if the following procedure is a sound one, if this is
stupid please tell me.
Encrypt the plaintext with something like Blowfish.
Use PGP to encrypt the Blowfish output so that it may be transmitted by
e-mail etc.
The Blowfish key is personally handed to the proposed recipient.
The PGP key would be a public one as normal.
I know that this is a belt and braces approach, but I am interested to know
if this is a cryptographically weak approach or not
Steganography is next on the list :-)
Thanks.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Tue, 3 Aug 1999 23:52:38 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> IIRC, it was "Dr. Dobb's Journal of Computer Calisthenics"
"Dr. Dobb's Journal of Computer Calisthenics and Orthodontia", though
that's not technically the original name -- at the very beginning it
was just "The Tiny Basic Journal" unless memory serves me ill.
Also note that contrary to an implication of an earlier post,
orthodontia is NOT particularly related to orthodontics.
------------------------------
From: Coms 1003 <[EMAIL PROTECTED]>
Subject: Question about Information Theory
Date: Tue, 3 Aug 1999 15:14:02 -0400
Right...I actually meant "on average". But in that case, the statement
does follow directly from Information Theory, correct?
=====================================================
>The question is this: does it follow directly from information theory
>that, given any encoding of the symbols of the sources into binary,
>transmission of one bit cannot reduce the entropy by more than one?
No, you can choose a coding that will on occasion - but not on average
- break this rule.
For example:
Say I have letters, chosen at random from A to Z, to transmit. All
these letters are equally probable.
But I code them so that 0 stands for the letter Q, and six-bit codes
starting with 1 stand for all the other letters.
If Q happens to come up, and I transmit a 0, the uncertainty has been
reduced by a full letter for the price of a bit.
John Savard ( teneerf<- )
------------------------------
From: [EMAIL PROTECTED] (Michelle Davis)
Subject: Re: Is the output of 3DES really pseudorandom???
Date: Wed, 04 Aug 1999 06:56:45 GMT
On Tue, 03 Aug 1999 18:48:45 GMT, [EMAIL PROTECTED] wrote:
>Generally you can use an encryption method as a PRNG but not for long.
>The basic method is to:
>
>I = 0
>
>1. K = H(M)
>2. output = Ek(I)
>3. I = I + 1
>4. if (need more outputs) and (I < threshold) goto 2
>5. if (need more outputs) goto 1
>
>Where I is a global counter, and M is some unpredictable input (mouse,
>keyboard and disk activity for example). If you run the counter to
>long with the same key it won't be random since the previous outputs
>will not appear again (it's a function rememeber). Generally if your
>threshold is small enough (say 1024) out of 2^64 possible outputs it
>will be good enough.
>
>For example after 512 outputs you have a 1 in (2^64 - 512) chance of
>guessing the next output ...
Okay, but I suppose that if nobody knows my previous 2000 outputs, it
wouldn't really help them to guess the next one. Am I right? So in
this scenario, effectively, it is pseudorandom?
>BTW 3des was used in Yarrow by www.counterpane.com
Thanks, I'll check this out.
------------------------------
** 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
******************************
