Cryptography-Digest Digest #21, Volume #14 Tue, 27 Mar 01 07:13:00 EST
Contents:
Re: Best encryption program for laptop? (David Formosa (aka ? the Platypus))
Re: Valid condition for multiplicative generator? ("Yaniv Sapir")
The creation of the DES s-boxes. ("Yaniv Sapir")
Re: Large numbers in C ( 512 bits or more) (David Schwartz)
Re: Open Source Implementations of PGP (Peter Harrison)
Re: Best encryption program for laptop? ("Henrick Hellström")
Re: Open Source Implementations of PGP (Peter Harrison)
Re: The creation of the DES s-boxes. (Frank Gerlach)
Re: Kill-filter expression for script weenie (Jerry Ennis)
Re: The creation of the DES s-boxes. (Mok-Kong Shen)
Re: Valid condition for multiplicative generator? (Mok-Kong Shen)
Re: The creation of the DES s-boxes. (Frank Gerlach)
Re: The creation of the DES s-boxes. (Frank Gerlach)
Re: Kill-file entries for TRN to nuke the weenie! (was Re: Kill-filter expression
for script weenie) ([EMAIL PROTECTED])
Re: The creation of the DES s-boxes. ("Yaniv Sapir")
Re: The creation of the DES s-boxes - thanks ("Yaniv Sapir")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Best encryption program for laptop?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Mar 2001 09:26:56 GMT
On Mon, 26 Mar 2001 09:56:14 +0200, Henrick Hellström
<[EMAIL PROTECTED]> wrote:
>"David Formosa (aka ? the Platypus)" <[EMAIL PROTECTED]> skrev i
>meddelandet news:[EMAIL PROTECTED]...
[...]
>> Arn't there hardware based authentication methods?
>
>
>Would they protect your secrets if the laptop was stolen?
I'm thinking of dongle that fits onto you keychain and plugs into a
Firewire or PCMA card based thing.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: Re: Valid condition for multiplicative generator?
Date: Tue, 27 Mar 2001 11:38:12 +0200
Just a newbie question: if, as claimed, "We can't distinguish a
physically-random generator from a pseudorandom generator by statistical
tests on the output stream", why bother making physical devices?
Yaniv.
Terry Ritter <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> On Tue, 27 Mar 2001 04:59:15 -0000, in
> <[EMAIL PROTECTED]>, in sci.crypt
> [EMAIL PROTECTED] (those who know me have no need of my name)
> wrote:
>
> ><[EMAIL PROTECTED]> divulged:
> >
> >>Where would any fundamental randomness come from? How could it be
> >>detected on a stock PC?
> >
> >how does the presence of an i810 (or later) chipset in a substantial
> >number of stock pc's affect your views?
>
> That is a completely different issue.
>
> Clearly, if one has such hardware, and one considers the Intel RNG to
> be acceptable, and the interface to it also acceptable, then one does
> have a hardware source of random values.
>
> Personally, I have problems with the Intel design. Clearly, the
> intent is to have a physically-random device based on thermal resistor
> noise (Johnson noise). One problem is that the generator would
> produce the same sort of apparently-random result even without the
> noise. Consequently, we are unable to show by experiment that the
> generator really does use unknowable quantum noise, which means that
> our only basis for such belief is the Intel design assertion that it
> must be so. I have been an engineer for too long, and deceived by
> claims too often, to take such assertions at face value.
>
> There is a fundamental security problem with complex systems in
> silicon chips, which is that ordinary people are unable to validate
> precisely what circuit is present. Especially in the case of a
> physically-random generator, an essentially pseudorandom design would
> produce just about the same results. We can't distinguish a
> physically-random generator from a pseudorandom generator by
> statistical tests on the output stream. So without the ability to
> validate the design in some experimental or physical way, we only have
> someone's assurance that the actual circuit we have really is
> performing the way we want it to. That is not enough for me.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 11:54:07 +0200
Hi all.
A few days ago I asked the NG for details on the values selection in the
S-boxes of the DES (DEA). What I'm looking for is an analytic way for
determining these values in the 8 S-boxes defined in the standard.
Following the answers I received (which were of not enough help), I went to
the library and searched a few books. All the texts refer to the S-boxes as
given, listing their tables. At most, the requirements from these were given
(such as non-linearity, change of at least 2 bits of output for 1 input bit
change, etc.).
Then I talked to Eli Biham (I'm from Israel, so it was easy...), who again
insisted on the look-up method for implementation. But he also mentioned
that for the standard, they checked around 15M possibilities and chose the
best one they had.
I also tried forming the boolean functions for each bit of S0, as a function
of the six input bits, to see if anything can be learned from that, but came
out with nothing.
Now, I can guess that LUT's are the easiest method. But I'm pretty sure that
it was not just the blind check of all possibilities of numbers, but rather
a reduced set of possibilities coming from some sort of calculation. And
this is what I'm looking for - how these numbers were calculated/chosen for
this standard!
So, if anybody has an answer, or can point me to a reference, this will be
most appreciated.
TIA,
Yaniv.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Large numbers in C ( 512 bits or more)
Date: Tue, 27 Mar 2001 02:06:44 -0800
Dobs wrote:
> Can somebody who has ever used big numbers from OPENSSL could tel me what
> should I do. I found such a structre, but what more should I copy to my
> program?????????????????
You shouldn't copy anything, you should use the library exactly the way
it is.
DS
------------------------------
From: [EMAIL PROTECTED] (Peter Harrison)
Subject: Re: Open Source Implementations of PGP
Date: Tue, 27 Mar 2001 10:12:12 GMT
On 24 Mar 2001 18:03:56 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>A prime example of someone unclear on the concept. Crypto is different
>from other programs. Usually the user can look at the output and tell if
>the program has done what it claims to do. In crypto this is most
>definitely not the case. There is now way from the output (unless the
>implimenter is totally incompetent) whether the implimentation is good
>or incompetent and weak. This requires two things-- that the implimenter
>be very well versed in the intricacies and potential attacks on a crypto
>system (see for example the recent breaking of the OpenPGP standards
>done by good people who should have known better), and that the
>implimentation be open so it can be checked. To have you, who self
>admittedly knows nothing of cryptography, writing a program which he
>expects others to use should strike fear in the heart of any potential
>user. It is like buying a car from someone who admits to knowing nothing
>about stearing and tires, and strength of materials, and saying that the
>whole field is much to complicated for someone who just wants to build a
>car.
Okay, there are a few points I should mention. First is that I am not
writing any of the algorithms. I am using AES and RSA, both of which
have been implemented by other developers, and have been tested using
the published test vectors. The source for these is freely available
if you wish to test for yourself.
Second, I have in fact a reasonable education in encryption. I know
of the potential hazzards, and have published the specification for
the file format used for public comment. The entire source code is
also available off SourceForge. I did in fact get a number of
comments back from the published spec already - and have addressed
them in the latest version.
http://idtrans.sourceforge.net
Your analogy to the car is useful. I am not saying that people who
build cars can be ignorant of car building. I am saying that a car
maker (designer) doesn't need to know every detail of how tyres are
made - he just needs to know their properties. The same is true for
crypto - if you have a an implementation of RSA that has been checked
and tested against test vectors there is little need for a developer
to understand RSA in depth in order to implement it. They obviously
need to know *something* about tyres - but a designer of a car
generally picks the tyres from a 'book' - they don't go designing the
tyre.
Im doing the same - taking crypto libraries from people who know
crypto well, testing them against test vectors - and then implementing
those libraries in a solution based on well known other methods - such
as PGP.
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Best encryption program for laptop?
Date: Tue, 27 Mar 2001 12:14:08 +0200
"David Formosa (aka ? the Platypus)" <[EMAIL PROTECTED]> skrev i
meddelandet news:[EMAIL PROTECTED]...
> On Mon, 26 Mar 2001 09:56:14 +0200, Henrick Hellström
> <[EMAIL PROTECTED]> wrote:
> >"David Formosa (aka ? the Platypus)" <[EMAIL PROTECTED]> skrev i
> >meddelandet news:[EMAIL PROTECTED]...
>
> [...]
>
> >> Arn't there hardware based authentication methods?
> >
> >
> >Would they protect your secrets if the laptop was stolen?
>
> I'm thinking of dongle that fits onto you keychain and plugs into a
> Firewire or PCMA card based thing.
I don't know how you suppose that would work. I searched for "+dongle
+keychain +firewire" but all I could find was methods for network
authentication. Such measures will not make your laptop burglar proof. On
the contrary, I suspect that your network security might be seriously
compromised if the laptop was stolen while the PCMA card was still mounted.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Peter Harrison)
Subject: Re: Open Source Implementations of PGP
Date: Tue, 27 Mar 2001 10:19:56 GMT
On 24 Mar 2001 18:32:25 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>There is no
>reason that the various components can be put together in a way
>that makes it easyer to test the various components in a way one
>does not need to get the source to totally check it.
One way is test units which run test vectors against the
implementations of the algoritms used. I did this to the code I have
used prior to using it.
> I think
>it should have options. Maybe call them debug options. Where
>if one wants it will spit out the individual fields used in
>the format. As well as files representing the file at various
>states such as before and after compression. This would allow
>for more types if dynamic checking. At least this is what
>should be done in OPEN PGP type of products.
The implementations I use often have debug code in compiler
conditionals so you can track the encryption in progress for
comparision to reference implementations publically published.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 13:12:35 +0200
Bruce Schneier wrote something about sbox design in "Applied
Cryptography". Get hold of that book.
Essentially, IBM applied its test algorithms to the sboxes and then sent
them to NSA. They applied *their* tests and came up with a new version.
Now we know that the NSA knew some more techniques than the public at
that point.
I think NSA used differential cryptanalysis, not publicly known at that
time.
------------------------------
From: Jerry Ennis <[EMAIL PROTECTED]>
Subject: Re: Kill-filter expression for script weenie
Date: Tue, 27 Mar 2001 11:13:49 GMT
>On 26 Mar 2001 10:02:37 GMT, in alt.security.pgp [EMAIL PROTECTED]
>(filterguy) wrote:
>
>>A filter expression that kills the Script Kiddie posts:
>>
>>for (Forte) Agent:
>>
>>subject: (love*|need*|ask*|require*|uses*|want*|used) and from:
>>(anonymous|melon|frog2|remailer|steeleye|nescio)
>>
Thanks! 450-some-odd pieces of his garbage promptly bit the dust.
*****************************************************
From: Jerry Ennis ([EMAIL PROTECTED])
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 13:28:23 +0200
Yaniv Sapir wrote:
>
> Now, I can guess that LUT's are the easiest method. But I'm pretty sure that
> it was not just the blind check of all possibilities of numbers, but rather
> a reduced set of possibilities coming from some sort of calculation. And
> this is what I'm looking for - how these numbers were calculated/chosen for
> this standard!
The design principles of DES have never been fully officially
disclosed. Highly probably the S-boxes were not obtained
from evaluating some mathematical formulae in the ordinary
sense but were results of trial and error, i.e. generate
these somehow according to certain heuristics and then
examine their properties to see if they are good enough
to satisfy a number of criteria. There are lots of papers
written concerning the properties of DES S-boxes in the
proceedings of crypto conferences.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Valid condition for multiplicative generator?
Date: Tue, 27 Mar 2001 13:28:33 +0200
Yaniv Sapir wrote:
>
> Just a newbie question: if, as claimed, "We can't distinguish a
> physically-random generator from a pseudorandom generator by statistical
> tests on the output stream", why bother making physical devices?
I think that the quote means that, if a generator passes
all your statistical tests, you yet don't know with that
result alone whether the generator is based on physical
randomness or software algorithm. A PRNG could have good
statistical properties to pass all your tests and also be
sufficiently complex to resist potential analysis in the
context of your environment, yet it is believed by many
people that physical randomness (if properly generated)
is much better or entirely unpredictable. I don't know
on the other hand of a rigorous way of proving any
available physical random source to be absolutely
unpredictable (excepting resorting eventually to quantum
theory, which is yet a 'theory'). To prove that the bit
sequence thus obtained is absolutely unpredictable is
presumably much more difficult, since, anyway, the appatus
tapping that source cannot be absolutely perfect from
manufacturing point of view, I believe. On the other hand,
if utilizing physical randomness as such is not a problem
for your applications, then it can usually be a good idea
to combine a physical random sequence with a statistically
very good pseudo-random sequence with xor-ing. That way
one reaps the benefit of both sources.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 13:29:47 +0200
Yaniv Sapir wrote:
>
> Hi all.
>
> A few days ago I asked the NG for details on the values selection in the
> S-boxes of the DES (DEA). What I'm looking for is an analytic way for
> determining these values in the 8 S-boxes defined in the standard.
There is no single analytic way, but only heuristics (which might use
some analytic techniques).
As the only provably secure crypto (to this date) is OTP, this should
not be surprising.
I personally *believe* that all cryptosystems, except OTP, can be broken
with dramatically less
than O(2^n) effort, if significantly more than n bits of encrypted
information is available.
This "believe" (not only of mine) is the reason that
-good symmetric communication systems are rekeyed every x bits, with x
typically in the 10^9 range.
-"black chambers", although nowadays staffed with large numbers of
mathematicians, are still funded
-OTP is still viable. Think of a hub-and-spoke system, and CDROMs as
keymat. You only need one CDROM to communicate with everyone in your
"domain", as you go through the hub, where your message is rekeyed. All
the big black chambers (GCHQ,NSA etc) will offically rant that OTP is
unsafe, because they have no chance if OTP is properly applied. My
assessment is that they still have it as a backup. Search for SIGSALY on
the web.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 13:39:15 +0200
Frank Gerlach wrote:
>
> Yaniv Sapir wrote:
> >
> > Hi all.
> >
> > A few days ago I asked the NG for details on the values selection in the
> > S-boxes of the DES (DEA). What I'm looking for is an analytic way for
> > determining these values in the 8 S-boxes defined in the standard.
> There is no single analytic way, but only heuristics (which might use
> some analytic techniques).
> As the only provably secure crypto (to this date) is OTP, this should
> not be surprising.
> I personally *believe* that all cryptosystems, except OTP, can be broken
> with dramatically less
> than O(2^n) effort, if significantly more than n bits of encrypted
> information is available.
With n being the length of the key.
> This "believe" (not only of mine) is the reason that
> -good symmetric communication systems are rekeyed every x bits, with x
> typically in the 10^9 range.
> -"black chambers", although nowadays staffed with large numbers of
> mathematicians, are still funded
> -OTP is still viable. Think of a hub-and-spoke system, and CDROMs as
> keymat. You only need one CDROM to communicate with everyone in your
> "domain", as you go through the hub, where your message is rekeyed. All
> the big black chambers (GCHQ,NSA etc) will offically rant that OTP is
> unsafe, because they have no chance if OTP is properly applied. My
> assessment is that they still have it as a backup. Search for SIGSALY on
> the web.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: Kill-file entries for TRN to nuke the weenie! (was Re: Kill-filter
expression for script weenie)
Date: Tue, 27 Mar 2001 11:39:24 GMT
I can't figure out how to use it! :(
On 26 Mar 2001 13:04:34 -0700, [EMAIL PROTECTED] (Ben Cantrick)
wrote:
>In article <[EMAIL PROTECTED]>,
>filterguy <[EMAIL PROTECTED]> wrote:
>>A filter expression that kills the Script Kiddie posts:
>>
>>for (Forte) Agent:
>>
>>subject: (love*|need*|ask*|require*|uses*|want*|used) and from:
>>(anonymous|melon|frog2|remailer|steeleye|nescio)
>>
>>
>>For Xnews (and slrn?):
>>
>> Score: -9999
>> Expires: 4/25/2001
>> Subject: (love|need|ask|require|use(s|d)|want)
>> From: (anonymous|melon|frog2|remailer|steeleye|nescio)
>
> Excellent kill expressions!
>
> In killfiles, as in crypto, the key is finding exploitable patterns.
>Our ph33r-less script kiddy has been quite stupid in his choice of posting
>material; all his posts contain dead giveaways. Here are some trn killfile
>entries that I'm using to nuke him...
>
> - He always has either "X-DumbAss: Arnold Boschloo" or "X-AirHead: Arnold
>Boschloo" in his posts. These two killfile entires auto-kill posts with
>"X-AirHead" pr "X-Dumbass" header lines:
>
>/^X-DumbAss/h:j
>/^X-AirHead/h:j
>
> These two lines alone seem to nuke 99% of his crap, and are probably
>sufficient by themselves. However, there are additional patterns we can
>exploit to shut him down too...
>
> - He seems to like to cross-post his junk to three specific newsgroups,
>soc.men, alt.security.pgp and sci.crypt. I consider the chances of someone
>legitimately cross-posting to all three of these newgroups vanishingly
>small. Hence I kill any post that goes to all three of them:
>
>/^Newsgroups:.*soc.men,alt.security.pgp,sci.crypt/h:j
>
> (Note: This killfile entry is order-sensitive to the order of the
>newsgroups. So if he starts randomizing the order of the groups in this
>line, you'll have to type in all six permutations, like so:
>
>/^Newsgroups:.*alt.security.pgp,soc.men,sci.crypt/h:j
>/^Newsgroups:.*alt.security.pgp,sci.crypt,soc.men/h:j
>/^Newsgroups:.*sci.crypt,alt.security.pgp,soc.men/h:j
>/^Newsgroups:.*sci.crypt,soc.men,alt.security.pgp/h:j
>/^Newsgroups:.*soc.men,alt.security.pgp,sci.crypt/h:j
>/^Newsgroups:.*soc.men,sci.crypt,alt.security.pgp/h:j
>
> It's a little annoying, but not too bad.)
>
> - Lastly, he seems to have some kind of fanatic hard-on for Arnold
>Boschloo, as mentioned above. He likes to CC his posts to Arnold and
>Arnold's ISP. I consider the chances of anyone legitimately CC'ing
>something to Arnold small, so I kill any posts that has a CC to Arnold's
>e-mail address:
>
>/^CC:.*[EMAIL PROTECTED]/h:j
>
>
> If you use the trn newsreader, then, well, you probably don't need me
>telling you how to make kilfile entries! But if you're a newbie using trn,
>here's how to use these: First, start reading sci.crypt. Then, start reading
>an article - any article will do. Read it through to the end so you get to
>the "end of" article prompt. This is the one that says "Article #xxxxx", not
>the one that says "More".
>
> Once you get to that prompt, hit ^K to directly edit the killfile for
>the newsgroup. You should be punted into an editor (maybe vi) and allowed
>to enter killfile entries. Type in the above killfile entries and off you
>go! Now every time you start reading sci.crypt, the newsreader will use
>the above entries to auto-junk posts from our ever-so-l33t s/<ript kiddie.
>
>
> -Ben
>--
>Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
>BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
>The Spamdogs: http://www.dim.com/~mackys/spamdogs
>"Of COURSE I'm on topic. (Which group is this again?)" -Scott Hagie
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes.
Date: Tue, 27 Mar 2001 13:48:43 +0200
Thanks.
I already looked in Schneier but found no help there. The text does not
supply the required details and the implementation software there uses LUT's
for the S-boxes.
Yaniv.
Frank Gerlach <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bruce Schneier wrote something about sbox design in "Applied
> Cryptography". Get hold of that book.
> Essentially, IBM applied its test algorithms to the sboxes and then sent
> them to NSA. They applied *their* tests and came up with a new version.
> Now we know that the NSA knew some more techniques than the public at
> that point.
> I think NSA used differential cryptanalysis, not publicly known at that
> time.
------------------------------
From: "Yaniv Sapir" <[EMAIL PROTECTED]>
Subject: Re: The creation of the DES s-boxes - thanks
Date: Tue, 27 Mar 2001 13:49:21 +0200
Thanks, guys.
>From the answers and the readings I learn that there is probably no
(unclassified) answer to my question. So, although this doesn't help in the
implementation process, this knowing is better than nothing!
Cheers,
Yaniv.
Yaniv Sapir <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi all.
>
> A few days ago I asked the NG for details on the values selection in the
> S-boxes of the DES (DEA). What I'm looking for is an analytic way for
> determining these values in the 8 S-boxes defined in the standard.
>
> Following the answers I received (which were of not enough help), I went
to
> the library and searched a few books. All the texts refer to the S-boxes
as
> given, listing their tables. At most, the requirements from these were
given
> (such as non-linearity, change of at least 2 bits of output for 1 input
bit
> change, etc.).
>
> Then I talked to Eli Biham (I'm from Israel, so it was easy...), who again
> insisted on the look-up method for implementation. But he also mentioned
> that for the standard, they checked around 15M possibilities and chose the
> best one they had.
>
> I also tried forming the boolean functions for each bit of S0, as a
function
> of the six input bits, to see if anything can be learned from that, but
came
> out with nothing.
>
> Now, I can guess that LUT's are the easiest method. But I'm pretty sure
that
> it was not just the blind check of all possibilities of numbers, but
rather
> a reduced set of possibilities coming from some sort of calculation. And
> this is what I'm looking for - how these numbers were calculated/chosen
for
> this standard!
>
> So, if anybody has an answer, or can point me to a reference, this will be
> most appreciated.
>
> TIA,
> Yaniv.
>
>
>
------------------------------
** 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
******************************
