Cryptography-Digest Digest #929, Volume #12 Sat, 14 Oct 00 22:13:01 EDT
Contents:
Re: Is it trivial for NSA to crack these ciphers? (SCOTT19U.ZIP_GUY)
Re: Why trust root CAs ? ([EMAIL PROTECTED])
Re: Why trust root CAs ? (David Schwartz)
Re: Using square roots for a secret code? ([EMAIL PROTECTED])
Re: Is it trivial for NSA to crack these ciphers? (Jim Gillogly)
Re: block-cipher silly question? (N. Weicher)
Re: Why trust root CAs ? ([EMAIL PROTECTED])
Re: Optimisation of SHA-256 (Daniel =?iso-8859-1?Q?L=E9onard?=)
Re: Why trust root CAs ? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: 15 Oct 2000 00:28:19 GMT
[EMAIL PROTECTED] (Stephen M. Gardner) wrote in
<[EMAIL PROTECTED]>:
>> Bletchley Park in England during World War II (cryptanalysis of
>> state-of-the-art crypto systems, some of the first programmable
>> computers) is another example.
>
> These WWII era analogies are suspect because of the entirely
> different
>conditions today.
>
>> I won't argue the morality of the innovations, only the fact that
>> these significant bursts in applied mathematics and applied physics
>> and engineering fit your billing. Significant strides without
>> significant peer review, publication or openness.
>
> All took place in special circumstances with people *temporarily*
> brought
>together out of the open scientific community. To compare the
>Manhattan Project to the NSA is to neglect the stultifying role of huge
>self-perpetuating bureacraties and the invigorating effect of having a
>world menacing evil to work against in a relatively short term and
>exciting project.
>
>
Actually the inbreeding is what is happening in the socalled open
society, It is unlikely that the socalled open communtiy which controlls
what gets published really is doing very much creative work in crypto.
Take my method scott16u. The open community crypto gods are to fuckin
lazy to look at it becasue its different. They are very narrow focused
and only want there stuff to be recognized. I am sure the NSA has
studied my method, Its there job, But the open crypto community still
belives the crap wagner spouted about it being dead by his slide attack
but the asshoke was dead wrong and full of shit. People are foolish
if they think the so called open crypto society is really doing all that
much useful stuff. They only want there stuff published and recognized
anyone not in the club is there enemy and they will lie to keep it
closed. They can't stand open honest competition.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 01:41:15 GMT
On Sat, 14 Oct 2000 16:46:53 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>
>> > Then how will the bank know that your id is associated with you? It
>> >must store that information somewhere -- and the logical format to store
>> >it in is a certificate.
>
>> Sorry, when I said central repository, I meant there is no need for a
>> *third party* central repository outside the bank (a la Verisign or
>> Thawte), let alone such third party PKI across a number of banks. The
>> bank's systems are the repository for the ids used by its customers.
>
> There is no distinction in this case between a third and a second
>party.
There is from a privacy and data linkage point of view. Perforce, your
bank has to know who you are and what payments you receive/make. But
as things stand at the moment, they do not know that you may have
accounts with 6 other banks. How do you maintain this separation of
information about youself, if there is a common 3rd party CA involved
in authenticating your one and only electronic id across all 7 banks?
>In any arrangement, who does what can be changed. If banks want
>to be CAs, they can be. It is, however, logical for banks to specialize
>in banking. On the other hand, it's not necessarily logical for a CA to
>specialize in certifying _financial_ transactions.
Banks are their own Certifying Authority now, in the non-electronic
world.
> Somebody must vouch for the fact that your key belongs to you. Someone
>must have you physically present your key and some form of
>identification and vouch that the person who proferred the key and the
>person who proferred the ID are one and the same. If you and your bank
>are in the same geogrpahical region, it is sensible for you to go to
>your bank and do this. If not, not.
This is true where the other party needs to know who you are. But lets
take the example of a pathology test. One could associate an
electronic patient id (public key) with the test order at time of
ordering, without any requirement to actually identify the patient on
whose sample the test is being run. The electronic id could be used
to ensure that subsequent access to the test result only occurs when
the authorised by the anonymous patient (by signing the request with
their corresponding private key). Lets suppose the patient is a well
known politician, and it is a test for HIV. The pathology lab need
never know the id of the patient.
>> This also gets around the problem of Joe's Discount Browser Session
>> Hijacking, since if someone impersonates your bank's server, they can
>> verify that it is you by sending a session id and receiving it back
>> signed by your private key, but that doesn't compromise your private
>> key, as would be the case if they hijacked a password based session.
>
> What you really need are different levels of trust in keys. If I choose
>to use a bank, I may choose to trust their keys at a very high level. On
>the other hand, I'd rather accept a self-signed cert than send data in
>the clear -- but I like to know that I have no protection against MITM
>attacks.
>
> The problem with PKI is not that's defective in principle, it's that
>it's defective as implemented. The defects are not easy to fix either.
My particualr concern as expressed elswhere in this thread is that if
PKI requires the association of actual identity with electronic
identity in every instance, and this information is centralised in a
specialised CA, then the capacity for traffic analysis of the use of
the electronic id presents a significant reduction in individuals'
privacy as compared with the current non-electronic situation.
PB
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sat, 14 Oct 2000 17:55:13 -0700
[EMAIL PROTECTED] wrote:
> This is true where the other party needs to know who you are. But lets
> take the example of a pathology test. One could associate an
> electronic patient id (public key) with the test order at time of
> ordering, without any requirement to actually identify the patient on
> whose sample the test is being run. The electronic id could be used
> to ensure that subsequent access to the test result only occurs when
> the authorised by the anonymous patient (by signing the request with
> their corresponding private key). Lets suppose the patient is a well
> known politician, and it is a test for HIV. The pathology lab need
> never know the id of the patient.
Except that you have no protection from a MITM attack. It's all well
and good if you can make a prior face-to-face arrangement, but if you
can't, you need someone to vouch for identity or you have no protection.
> > The problem with PKI is not that's defective in principle, it's that
> >it's defective as implemented. The defects are not easy to fix either.
>
> My particular concern as expressed elswhere in this thread is that if
> PKI requires the association of actual identity with electronic
> identity in every instance, and this information is centralised in a
> specialised CA, then the capacity for traffic analysis of the use of
> the electronic id presents a significant reduction in individuals'
> privacy as compared with the current non-electronic situation.
If you don't know who you are talking to, how do you know you can trust
them?
DS
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Using square roots for a secret code?
Date: Sun, 15 Oct 2000 01:04:59 GMT
In article <8saere$6o1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> You suggested to encrypt plaintext by taking a short key K (an
integer)
> and expanding it into a long, pseudo-random keystream by using the
decimal
> expansion of sqrt(K).
>
> But this is insecure, because with a short stretch of known keystream,
> you can recover K using continued fractions and thus deduce the rest
of
> the unknown keystream.
>
> Thus, your proposed scheme is insecure against known-plaintext
attacks,
> or against attacks where the cryptanalyst guesses a short crib and
slides
> it against the ciphertext.
>
> You can generalize to algebraic numbers, but then there are attacks
using
> the theory of lattice reduction. See
>
> R. Kannan, A. K. Lenstra and L. Lovász, Polynomial factorization and
> non-randomness of bits of algebraic and some transcendental numbers,
> Proc. ACM STOC 84, pp 191-200 (1984).
>
> By the way, you might have received better luck had you asked on
sci.crypt.
>
===============================
Eriko-chan heard that, and the new plan she has in mind
Is kana, nigori, handakuten, space together are forty-nine
Her new variation on that old scheme uses a couple of tricks
The digits in her kana code are nought, one, two, three, four, five, six
For extracting the square root, decimal, she says, is great
But she carefully discards each and every seven, nine, and eight
She non-carry adds the digit-strings, modulo seven this time
Can one "continued-fraction" recover the code key for the scheme in this
rhyme?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 01:12:54 +0000
"SCOTT19U.ZIP_GUY" wrote:
> Actually the inbreeding is what is happening in the socalled open
> society, It is unlikely that the socalled open communtiy which controlls
> what gets published really is doing very much creative work in crypto.
> Take my method scott16u. ... fuckin ... crap ... asshoke ... shit...
> They only want there stuff published and recognized
> anyone not in the club is there enemy and they will lie to keep it
> closed. They can't stand open honest competition.
Is someone keeping you from publishing your work? Did you submit it
to a refereed journal or conference and get it turned down? If so,
did you understand the reviewer's comments and fix your paper before
resubmitting it? Communication skills are important: if nobody
understands your work, the fault is with your explanations rather
than with the readers.
There are a lot of ideas out there, and everybody has to implement
some kind of bozo filter to optimize their use of time. We're well
past the era when an educated person could know everything important.
The refereeing system, while imperfect, is an important mechanism for
helping improve your chances of reading something that will be useful
to you rather than wasting your time with something that has a good
chance of being garbage. While there may be pearls in any stinky,
disgusting swamp, you have a much better chance of finding pearls
in an oyster bed.
--
Jim Gillogly
24 Winterfilth S.R. 2000, 01:01
12.19.7.11.8, 11 Lamat 11 Yax, Third Lord of Night
------------------------------
From: N. Weicher <[EMAIL PROTECTED]>
Subject: Re: block-cipher silly question?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Oct 2000 01:44:26 GMT
<< If the user can prevent certain attacks such as chosen plain text
attacks. And if the files are prewhittened and compressed with 1-1
compressors. IN a secret way. Like using my compressor with a secret
condition file. He could then encrypt the resultant file with a normal
8 bit block cipher and it would not be trival to break. >>
Thanks for the reply. Can you elaborate? Are you referring to your
scott16u?
Thanks.
Neil
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 02:50:31 GMT
On Sat, 14 Oct 2000 17:55:13 -0700, David Schwartz
<[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>
>> This is true where the other party needs to know who you are. But lets
>> take the example of a pathology test. One could associate an
>> electronic patient id (public key) with the test order at time of
>> ordering, without any requirement to actually identify the patient on
>> whose sample the test is being run. The electronic id could be used
>> to ensure that subsequent access to the test result only occurs when
>> the authorised by the anonymous patient (by signing the request with
>> their corresponding private key). Lets suppose the patient is a well
>> known politician, and it is a test for HIV. The pathology lab need
>> never know the id of the patient.
>
> Except that you have no protection from a MITM attack. It's all well
>and good if you can make a prior face-to-face arrangement, but if you
>can't, you need someone to vouch for identity or you have no protection.
How is it subject to MITM? the MITM doesn't know whose public key it
is (ie that it is the politician's), nor which test order/result
relates to the politician. The MITM could impersonate the path lab,
but unless they already have the test results in some other way, where
does that get them? If the MITM wants to impersonate the politician
in order to receive the test result, they don't have the politician's
private key, and so cannot impersonate him.
Which bit am I missing?
>> > The problem with PKI is not that's defective in principle, it's that
>> >it's defective as implemented. The defects are not easy to fix either.
>>
>> My particular concern as expressed elswhere in this thread is that if
>> PKI requires the association of actual identity with electronic
>> identity in every instance, and this information is centralised in a
>> specialised CA, then the capacity for traffic analysis of the use of
>> the electronic id presents a significant reduction in individuals'
>> privacy as compared with the current non-electronic situation.
>
> If you don't know who you are talking to, how do you know you can trust
>them?
In this case, there is no need to know who they are, only to
authenticate that they are the same person requesting the result as
the person for whom it was ordered. If they want to represent
themselves as Mr Donald Duck, that's fine as long as the public key,
digital signing protocol ensures it is the same Mr D. Duck for whom
the test was ordered. Ands as far as I can see it does. Indeed they
dont even have to associate a spurious id (such as D Duck) with the
pubkic key, as no identity other than the key itself is required.
cheers
PB
------------------------------
From: Daniel =?iso-8859-1?Q?L=E9onard?= <[EMAIL PROTECTED]>
Subject: Re: Optimisation of SHA-256
Date: Sat, 14 Oct 2000 21:54:44 -0400
lcs Mixmaster Remailer wrote:
>
> Try something like this, a modification of the PGP SHA implementation:
>
> /* Key expansion
> * The expandx() version doesn't write the result back, which can be
> * used for the last two rounds since those outputs are never used.
> */
> #define expandx(W,i) (W[i&15] + sig0(W[(i-15)&15]) + \
> W[(i-7)&15] + sig1(W[(i-2)&15]))
> #define expand(W,i) (W[i&15] = expandx(W,i))
>
> /* Round updating */
> #define subRound(a, b, c, d, e, f, g, h, k, data) \
> ( t1 = h + SIG1(e) + Ch(e,f,g) + k + data, d += t1, \
> h = t1 + SIG0(a) + Maj(a,b,c) )
>
> /* Excerpt from SHA-256 compression function */
> subRound( A, B, C, D, E, F, G, H, K[ 0], key[ 0] );
> subRound( H, A, B, C, D, E, F, G, K[ 1], key[ 1] );
<snip>
I have a big interrogation, why comma in the macro "subRound" ? Why not
';' ?
Also, what I have written is very similar to what you wrote, except in
different order:
me:
(1) T1 = h + SIGMA1(e) + Ch(e, f, g) + K[0] + W[0]; T2 = SIGMA0(a) +
Maj(a, b, c); h = T1 + T2; d += T1;
|
V
(2) T1 = h + SIGMA1(e) + Ch(e, f, g) + K[0] + W[0]; h = T1 + SIGMA0(a) +
Maj(a, b, c); d += T1;
|
V
(3) T1 = h + SIGMA1(e) + Ch(e, f, g) + K[0] + W[0]; d += T1; h = T1 +
SIGMA0(a) + Maj(a, b, c);
you:
( t1 = h + SIG1(e) + Ch(e,f,g) + k + data, d += t1, h = t1 + SIG0(a) +
Maj(a,b,c) )
do the comma operator play a role ?
Also, why the "d+=t1" before calculating t2 ? Does that affect anything
? In java, if I execute (1), I get different result from (3). That I
find weird since 'd' does not play any role in any equation (it does
after, but that is another story).
here are some results (top group -> sha256("abc"), low group is the
other test - top value -> my result, low value -> canonical solution)
T1 = ...; d += T1; h = T1 + ...
$ java fork.debug.md.SHA256
0x8da0ce7d110a3454b708ebc67a06d99ff68ac8ecd739bfc54b8d2b53518d2759
0xba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
================
0x0871448a6da0648a879197df0e31fbab0d39e16246726fa8b71e932883361fa3
0x248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1
T1 = ...; h = T1 + ...; d += T1;
$ java fork.debug.md.SHA256
0xa21319a3edaa4b094ed334262f8e05e972dd7fcaabd063e63dcb9293d1d38689
0xba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
================
0x1eb980dbb94e8d9ad8b8bb6683fea768b6097a91b2f36134d4c0f26bb3a17271
0x248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1
Hope I fin my wau through this mess.
=================
Daniel Léonard (aka fork)
Computer Science Student
Université de Montréal
"The nuclear warhead is one of the Humans' most efficient weapons. They
first tested it on themselves, obliterating several entire cities. The
intervening centuries since the weapon's first use had not dimmed its
effectiveness, as the Black Star proved when it blew apart. It was, from
all accounts, a most impressive display and took - by the standart of
such thing - quite some time as one section after another after another
of the ship erupted."
- Emperor Londo Mollari, Babylon 5 : In the Beginning
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why trust root CAs ?
Date: Sun, 15 Oct 2000 02:58:21 GMT
On Sun, 15 Oct 2000 02:50:31 GMT, [EMAIL PROTECTED]
wrote:
>On Sat, 14 Oct 2000 17:55:13 -0700, David Schwartz
><[EMAIL PROTECTED]> wrote:
>
>>
>>[EMAIL PROTECTED] wrote:
>>
>>> This is true where the other party needs to know who you are. But lets
>>> take the example of a pathology test. One could associate an
>>> electronic patient id (public key) with the test order at time of
>>> ordering, without any requirement to actually identify the patient on
>>> whose sample the test is being run. The electronic id could be used
>>> to ensure that subsequent access to the test result only occurs when
>>> the authorised by the anonymous patient (by signing the request with
>>> their corresponding private key). Lets suppose the patient is a well
>>> known politician, and it is a test for HIV. The pathology lab need
>>> never know the id of the patient.
>>
>> Except that you have no protection from a MITM attack. It's all well
>>and good if you can make a prior face-to-face arrangement, but if you
>>can't, you need someone to vouch for identity or you have no protection.
>
>How is it subject to MITM? the MITM doesn't know whose public key it
>is (ie that it is the politician's), nor which test order/result
>relates to the politician. The MITM could impersonate the path lab,
>but unless they already have the test results in some other way, where
>does that get them? If the MITM wants to impersonate the politician
>in order to receive the test result, they don't have the politician's
>private key, and so cannot impersonate him.
>
>Which bit am I missing?
On further thought, i take it you are proposing that a MITM's would
impersonate the path lab at ordering time, and then replace the
politician's public key with his own before forwarding it on to the
real path lab so that the MITM;s key is associated with the original
test order, rather than the politician's, thus diverting access to the
test result to the MITM, when it comes back. I think this can be
averted in usuals ways by having the session with the path lab
secured, eg using SSL. This may require the path lab's server to be
authenticated by a CA, but not, as far as I can see, the politician.
>>> > The problem with PKI is not that's defective in principle, it's that
>>> >it's defective as implemented. The defects are not easy to fix either.
>>>
>>> My particular concern as expressed elswhere in this thread is that if
>>> PKI requires the association of actual identity with electronic
>>> identity in every instance, and this information is centralised in a
>>> specialised CA, then the capacity for traffic analysis of the use of
>>> the electronic id presents a significant reduction in individuals'
>>> privacy as compared with the current non-electronic situation.
>>
>> If you don't know who you are talking to, how do you know you can trust
>>them?
>
>In this case, there is no need to know who they are, only to
>authenticate that they are the same person requesting the result as
>the person for whom it was ordered. If they want to represent
>themselves as Mr Donald Duck, that's fine as long as the public key,
>digital signing protocol ensures it is the same Mr D. Duck for whom
>the test was ordered. Ands as far as I can see it does. Indeed they
>dont even have to associate a spurious id (such as D Duck) with the
>pubkic key, as no identity other than the key itself is required.
>
>cheers
>
>PB
------------------------------
** 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
******************************
