Cryptography-Digest Digest #306, Volume #11 Sat, 11 Mar 00 16:13:01 EST
Contents:
Re: why xor?(look out,newbie question! :) (Mok-Kong Shen)
NSA Polygraph Screening Exposed (Frog)
Sending secure mail ("Seeker")
Re: sci.crypt Cipher Contest Web Site (antirez)
Re: Sending secure mail (Tom McCune)
Re: Free-MAC mode (David A. Wagner)
Re: NIST, AES at RSA conference (David A. Wagner)
Re: SSLeay application (Paul Schlyter)
Re: why xor?(look out,newbie question! :) ("r.e.s.")
Re: Linking Time-Stamping Servers (Terje Mathisen)
Re: Free-MAC mode (antirez)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sat, 11 Mar 2000 18:08:56 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > I am afraid that so much words of you don't really help me at all.
> > Given two bit sequences x_i and y_i, please kindly write down
> > the 'test statistic' for independence, i.e. an expression in terms
> > of x_i and y_i, so that I can actually compute that and look into the
> > statistics tables to see if my results are satisfactory at a
> > given confidence level. And please exlain how you come to that
> > particular test statistic, i.e. why it 'tests' the property
> > 'independence'. Please also list your assumptions, if any.
>
> You were already directed to Pearson's chi-square statistic as one
> standard test. The "so much words" were an essential caveat: if
> you blindly follow a recipe and don't understand how to interpret
> the results, you will draw erroneous conclusions from the test.
> I don't see much point in my trying to write a whole essay about
> it here, when you can learn about Pearson's chi-square statistic
> from any decent introductory college statistics textbook. The
> formula itself is very simple, and you can find C code for it and
> also for my preference for such tests (Kullback's � statistic),
> including the associated significance functions, in various
> places on the Internet, e.g. URL
> http://the.wiretapped.net/security/cryptography/literature/applied-crypto/i-hat.zip
> (The above URL may have been broken into multiple lines by the
> time you see it.) The included documentation is in the form of
> UNIX manual page sources (eqn|troff -man), which can be read in
> the raw source form if you have no way to format them.
>
> Note that these tests will compare bit-by-bit in parallel, not
> looking for correlations at offsets other than 0, nor for
> patterns within a stream. But they are a good place to start.#
Please note that 'uncorrelatedness' is not identical to 'independence'.
(Perhaps you should re-read a bit in your 'better textbooks', which
you seemed to intend to recommend to me in a previous post, to
verify that.) So please now tell me how am I going to apply the
Peason chi-square test to test the independence of two bit sources.
(I have applied the chi-square test in other applications. It wasn't
necessary to give me pointer to or explain the chi-square test.)
Let me assure you that (though you might not yet believe it) testing
for independence is a rather tough topic in statistics. I am not
very sure that you are in possession of books in which more than
two pages are devoted to discussing that, not to mention giving
concrete algorithms to test independence. (cf. the last sentence in
my reply to ivanhoe.)
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Frog <[EMAIL PROTECTED]>
Date: 11 Mar 2000 17:09:41 -0000
Subject: NSA Polygraph Screening Exposed
Crossposted-To: alt.politics.org.nsa
NSA Polygraph Screening Exposed
*******************************
If you are assigned to NSA or pending assignment, you need to know about the deception
behind the DoD polygraph test. The test has no scientific validity whatsoever, and it
depends on the polygrapher tricking the subject (you) into making damaging admissions.
See "The Lying Game: National Security and the Test for Espionage and Sabotage" on the
Federation of American Scientists website:
http://www.fas.org/sgp/othergov/polygraph/maschke.html
While the article discusses the use of this test by the Department of Energy, it's the
same test used by NSA and other DoD agencies.
------------------------------
From: "Seeker" <[EMAIL PROTECTED]>
Subject: Sending secure mail
Date: Sat, 11 Mar 2000 17:52:32 GMT
How can I send secure mail to people who might not have PGP, et al on their
end? I'm looking for a seamless solution where they don't have to do
anything (or very little) to read the mail, but I want to know the mail is
generally safe from sniffing. Thanks.
------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Sat, 11 Mar 2000 17:46:41 GMT
In article <8admtq$2hca$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> becasue speed is an issure with live connections. It does not mean
that the
> encryption used for such connections needs to be the same encryption
one uses
> to keep files and certain types of data secure. High speed encryption
has its
> place. But it is not the anwser to the keeping of ones special files
and email
> secure from the meddlings of the NSA. To use such high speed
encryption
> dor ones personnel files is foolish.
Agreed, to select an algorithm with in mind the most critical speed
usage seems strange. I think that the main use of the AES finalist
will be file encryption, email encryption and so on. For all this
uses maybe that even an algorithm ten times more slow than 3DES
isn't a problem and, since the speed of personal computers will be
higher in the near future, will be every day less a problem.
Sure, we need even an algorithm that is good for very fast links.
For this there are a lot of good algorithm, like blowfish or some
vertical algorithm tought only for fast link encryption.
Somebody can reply that the security of the algorithm isn't related
with the speed, but seems is a truth that for example a feistel
network with a lot of rounds is more resistant to some attack.
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Sending secure mail
Date: Sat, 11 Mar 2000 18:01:34 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <AJvy4.17073$[EMAIL PROTECTED]>, "Seeker"
<[EMAIL PROTECTED]> wrote:
>How can I send secure mail to people who might not have PGP, et al on
>their end? I'm looking for a seamless solution where they don't have to
>do
>anything (or very little) to read the mail, but I want to know the mail is
>generally safe from sniffing. Thanks.
Use a Self Decrypting Archive such as included with PGP 6.5.x. The email
has to then go to someone using the same operating system, but does not
require the recipient to have anything but the passphrase that you have to
somehow get to them (you could always use the same passphrase for the same
person).
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.3
Comment: WHY? http://Tom.McCune.net/PGPpage2.htm#Privacy&Authenticity
iQA/AwUBOMqK6w2jfaGYDC35EQJHlQCfULDgN7l39l486qu1DR7mwCDa1pgAn3pM
/0z0LHGB1eqUAx+wJlzgfZOC
=IEAh
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Free-MAC mode
Date: 11 Mar 2000 09:35:19 -0800
In article <8adftu$7c5$[EMAIL PROTECTED]>, antirez <[EMAIL PROTECTED]> wrote:
> Sorry, but I cant understand how the truncation attack works against
> my scheme. For a given message M the MACed ciphertext C is obtained
> as C = Ek(M||RANDOM||SHA1(M,RANDOM)) so there isn't a fixed block.
> How can I set M' to forge M if this scheme avoid a fixed block?
Choose M = M'||RANDOM'||SHA1(M',RANDOM')||ANYTHING, where RANDOM' and
ANYTHING may be chosen arbitrarily. Request the encryption of M. Wait
to see the ciphertext, call it C; it will satisfy
C = Ek(M||RANDOM||SHA1(M,RANDOM))
= Ek(M'||RANDOM'||SHA1(M',RANDOM')||ANYTHING||RANDOM||SHA1(M'||..||RANDOM))
Now truncate C just before the encrypted occurrence of ANYTHING.
Call the result C'. Note that, if you split it at the right spot,
C' = Ek(M'||RANDOM'||SHA1(M',RANDOM'))
so C' is a valid encryption of M'. But you never requested the
encryption of M, so you've forged the MAC on a message you've never
seen. This is an integrity failure.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 11 Mar 2000 09:58:42 -0800
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> The assumption was that FH is readily crackable, but FG and G'H
> are not. For example, suppose F, G, G', and H each uses 32 bits
> of key and that FH can be cracked using radically less work than
> a brute-force key search, but FG and G'H cannot. 2^-32 of the
> time, the composite system cracks immediately; that is much worse
> than either separate system FG or G'H.
How on earth can that be? Let Break(E) be the cost of the best attack
to break E; let's define cost as (say) workfactor / success prob. We have
Break(FG) <= 2^32 Break(F) (by guessing the key to G)
<= 2^32 Break(FH) (because FH is at least as strong as F)
You note that 2^-32 of the time, FGG'H breaks with workfactor Break(FH).
If we assume this is the best attack on FGG'H, then
Break(FGG'H) = Break(FH) / 2^-32
>= Break(FG) (see above)
You claimed that FGG'H is worse than FG, but the above argument suggests
otherwise (namely, that, unless there is some other better attack on FGG'H,
FGG'H will be at least as strong as FG).
There's an alternate way to view it. We can start from the assumption
that the best attack on FGG'H is to hope that GG' = identity (happens with
prob. 2^-32) and to optimistically apply the attack on FH to the data
from FGG'H. Then we can create -- just from these black box attacks --
an attack on FG that works with the same success probability as the above
attack on FGG'H. Namely, we pick keys for G'H randomly (independently
of everything else), and run the FGG'H-attack above (i.e., hope that GG'
= identity and run the FH-attack). Note that, e.g., chosen-plaintext
queries to the FGG'H cipher may be simulated using chosen-plaintext
queries to the FG cipher, since we know the G'H keys (we chose them);
similarly for chosen-ciphertext and known-plaintext attacks. Finally,
note that the attack on FG works with the same success probability and
about the same workfactor as the attack on FGG'H. So (under our assumption)
it cannot be the case that FGG'H is radically stronger than FG.
Thus, I think your stated assumptions are impossible (and provably so).
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: SSLeay application
Date: 11 Mar 2000 17:43:38 +0100
In article <8acdt7$ec5$[EMAIL PROTECTED]>, ����ö <[EMAIL PROTECTED]> wrote:
> I would like to develope cryptographic application using SSLeay.
>
> That will does not use the full function of SSLeay.
>
> I would like to only cryptographic modules(crypto algorithms).
>
> Is it possible? Thanks in advance
Yes it's possible, but be prepared to have to spend some time
learning to navigate through SSLeay, or its descendant OpenSSL. But
there are cryptographic primitives there you can use without having
to use the SSL stuff.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Sat, 11 Mar 2000 11:16:48 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote ...
[...]
| Let me assure you that (though you might not yet believe it) testing=20
| for independence is a rather tough topic in statistics.=20
That's quite true. One problem in the present case is that neither the =
chi-square nor the Kullback test-statistic mentioned is going to be of =
much use if the bits *within* in each separate stream are mutually =
dependent. =20
Suppose your bit streams are a_i and b_i (i=3D1..n). You're asking =
about independence "between streams" (a_i)(i=3D1..n) and =
(b_i)(i=3D1..n). But to address that, it happens that the tests =
mentioned require an assumption that (a_i, b_i)(i=3D1..n) are mutually =
independent. I.e., (a_1, b_1) must be *assumed* independent of (a2, b2) =
etc in order to test whethe a_1 is independent of b_1 etc. I believe =
this is a real "wrench in the machinery".
--r.e.s.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Linking Time-Stamping Servers
Date: Sat, 11 Mar 2000 20:46:23 +0100
Ron Skoog wrote:
>
> Terje Mathisen wrote:
> >
> > Paul Koning wrote:
> > >
> > > Terje Mathisen wrote:
> > > > NTP is definitely the 'Right Way' to sync servers, ...
> > >
> .
> .
> .
> >
> > And how would you attach those clocks to your servers?
>
> From what I've worked with there are GPS time receivers that will
> connect via ethernet, VME, ISA, or PCI. I'm sure there are others.
Today time servers are basically limited to either be of the 'black box'
GPS+NTP type, or you will have a PPS interface which must be connected
to some interrupt-capable input pin on the computer.
The easiest (and default) method is to use a single serial port, where
the serial stream deliver the ascii time stamps, and the PPS signal is
connected to the DCD pin.
According to Poul-Henning Kemp, some embedded serial ports, which are
part of an integerated PC chip set, have pretty bad interrupt latency
variation, due to synchronous handling of the interrupt pins, on these
machines he's gotten better performance from the parallel ports.
> > NTP is _the_ best piece of sw available to sync a system clock to an
> > external source, preferably using a Pulse Per Second (PPS) signal to
> > slave the kernel clock directly to the exterbak reference.
>
> It all depends on what you need the time precision to be. I found out
> recently that setting the system clock on a Wintel box would give upto
> 100 milliseconds error from the time base it was being set against even
> though that was good to a few microseconds. This problem was inherent
> in the design of the O/S and onboard clock.
This is one of the reasons why NTP never syncs a clock by setting it, to
work NTP requires as an absolute minimum a kernel clock API which allows
gradual tuning.
This way the monitoring process can note that the kernel clock at the
time when the last PPS pulse was received, was off by N microseconds,
and then use the clock tuning api to request that the clock should be
speeded up or slowed down by just enough to correct this error over the
next minute or so.
>
> That time base was a PCI card. Trying to set a system against a network
> time base could be worse depending on the network traffic. However, if
> you don't have a need for sub-second accuracy the NTP is certainly
> better.
As I stated on my initial post, NTP without any cpu-attached local
reference clocks, but multiple good servers on a good network, have
managed to keep our servers within a millisecond or so of true time.
I actually ran a full survey of all NTP using servers in our corporate
WAN last week:
The monitoring machine was the FreeBSD server with sub-microsecond
precision.
I found 420 servers, mostly inside Norway, but many of them on the other
side of fairly low-bandwidth links (128 or 256 kbits/s).
400 of the servers were at that time less than 2 ms away from UTC, among
the remaining 20 servers, the single worst system (located on a west
coast island) indicated a 32 ms offset.
>
> >
> > One of my reference servers, currently sitting in my office with the
> > antenna on an outside ledge, is a FreeBSD machine using a $400 Motorola
> > Oncore GPS receiver which is capable of 30 ns RMS precision.
> >
> > That particular box uses the standard (bad) motherboard crystal, so when
> > I measured the error, I got something like 0.4 us of RMS jitter.
>
> How did you measure that? I've been running across problems related to
> PCI bus latencies of almost 100 ns and (for NT) time slices of around 80 ms.
As I said originally, this is one of the totally unneccesary problem on
NT:
The NT GetSystemTimeAsFileTime() api, which returns a 64-bit time stamp,
giving the number of 100 ns periods since 1601, will not even try to use
any of the high-resolution clocks available (like QueryPerformanceTimer)
to interpolate between timer ticks, so you get a time stamp that is only
accurate to about 10 ms.
FreeBSD used the NANO kernel, which uses nanoseconds for the sam kind of
timestamps, and which tries to deliver the maximum precision the
hardware (usually RDTSC) is capable of.
> The combination of the two tent to make sub-millisecond measurements
> difficult without using interrupts and those have shown ~3us variation
> around a 10K PPS interrupt.
To get rid of most of the interrupt jitter, NTP uses a median filter on
the PPS timestamps: This gets rid of almost all the really bad/spurious
time stamps.
After doing this, it employs a very sophisticated mixed-mode FLL/PLL
regulator to slave the kernel clock to these median-filtered PPS pulses.
> > Poul-Henning Kemp, who wrote the Oncore driver, have also replaced the
> > motherboard crystal with an OCXO, he got significantly better than 0.1
> > us precision.
>
> Is there a webpage on this trick?
No trick, just replacing the $0.XX crystal by something costing quite a
bit more, but which is at least two orders of magnitude more stable:
http://phk.freebsd.dk/ntp/
If you take a look at the raw and filtered performance of this setup,
with and without a stable crystal, you'll see that this is indeed the
'Right Way'. :-)
Terje
PS. Make suer you also visit the link on the raw performance of the
oncore:
http://phk.freebsd.dk/oncore/
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: antirez <[EMAIL PROTECTED]>
Subject: Re: Free-MAC mode
Date: Sat, 11 Mar 2000 19:55:28 GMT
In article <8ae04n$j0s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
> In article <8adftu$7c5$[EMAIL PROTECTED]>, antirez
<[EMAIL PROTECTED]> wrote:
> > Sorry, but I cant understand how the truncation attack works against
> > my scheme. For a given message M the MACed ciphertext C is obtained
> > as C = Ek(M||RANDOM||SHA1(M,RANDOM)) so there isn't a fixed block.
> > How can I set M' to forge M if this scheme avoid a fixed block?
>
> Choose M = M'||RANDOM'||SHA1(M',RANDOM')||ANYTHING, where RANDOM' and
> ANYTHING may be chosen arbitrarily. Request the encryption of M.
Wait
> to see the ciphertext, call it C; it will satisfy
> C = Ek(M||RANDOM||SHA1(M,RANDOM))
> =
Ek(M'||RANDOM'||SHA1(M',RANDOM')||ANYTHING||RANDOM||SHA1(M'||..||RANDOM))
> Now truncate C just before the encrypted occurrence of ANYTHING.
Yes, after your explaination I understand how it's impossible to
build a Free-MAC if the attacker is able to choose a plaintext and
get the MAC. Even if this attack doesn't work in my application, that
uses the FREE-MAC just to check that the ciphertext of an ftp-like
protocol wasn't modified, I want use a safe scheme, So I read the
Prenell's paper found at
http://www.esat.kuleuven.ac.be/~preneel/publications.html
about MDx-MAC. this paper is impressive! (at least for a crypto-ignorant
as me). It shows how a lot of applications use an insecure HMAC and
allows newbie as me to think at one-way hash function like MD[45] and
SHA1 in a better way: considering that are iterated.
Really thanks!
--
antirez
email: antirez@linuxcare dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
