Cryptography-Digest Digest #109, Volume #10 Wed, 25 Aug 99 14:13:03 EDT
Contents:
Re: What the hell good is a session key! (SCOTT19U.ZIP_GUY)
Re: Canadian Crypto Update!!! (W.G. Unruh)
Re: Canadian Crypto Update!!! (Tom St Denis)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: cryptographic DLL (SCOTT19U.ZIP_GUY)
Re: What the hell good is a session key! (Anton Stiglic)
Re: export legislation (W.G. Unruh)
Re: passphrases (Anton Stiglic)
Re: cryptographic DLL (John)
Re: cryptographic DLL (John)
Re: One-time pad encryption. (Mickey McInnis)
Re: cryptographic DLL (John)
Re: cryptographic DLL (Paul Koning)
# XXIV of a series (wtshaw)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What the hell good is a session key!
Date: Wed, 25 Aug 1999 14:13:27 GMT
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>>
>> cannot be solved. If you read, "Applied Cryptography",
>> there is a place where the author says the
>> mathematical base problems for the current asymmetric
>> schemes are very few and its scary because
>> advances in math could topple many of the
>> current schemes in one blow.
>
>Of cours, Bruce Schneier, author of Blowfish and great cryptanalyst
>of symmetric cipher, is going to have a point of view that gives
>positive arguments to symmetric encryption compared to asymmetric.
>(no disrespect to Mr. Schneier, I repsect him alot).
>
Well I have very little respect for MR BS but what you are calling
asymmetirc mehods (even though I cut off rest of page) are actaully
"zero knowledge" methods. All such methods where two unknown
users need to exchange keys are call that. Unless they know a
shared secret.
My the very nature of information theory. All the information is
there to break the code. That does not mean some one will find
a way but in therory all the info is there. And if the attacker stubles
on the soultion then he can tell exactly if he has the soultion.
For symmetric methods the key is "secret" so there is real
information to hide. And it takes a certain amount of code
to even be able to theoritically have enough info to break the
method. Though with the short key methods and chaining in
common use it takes very little but in theory it takes more
than a "zero knowledge" scheme. Also one could use what
you are calling asymmetric by not really having a secret key
but by keeping all the constants used as a sharded secret and
turn you asymmetric methods into symmetric methods. OF course
the block size would most like be very large anad it would be
slow But it would be as safe or safer used as a secret key method
than the public key methods are.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Canadian Crypto Update!!!
Date: 25 Aug 99 14:11:40 GMT
[EMAIL PROTECTED] writes:
>Just for you Tom, here's a link that I just found.
>http://securityportal.com/closet/closet19990825.html
>According to the article, any and all encryption products can be
>imported/exported from Canada. Woo-Hoo!!!
False. Canadian law ( The Export Control List) does include licensing
requirements for crypto. HOwever under the general software exemption,
Public Domain software is exempt from licensing. Public domain is
defined loosly as software which is available "over the counter" and
does not have any restrictions as to its subsequent use, or further
interaction with the manufacturer. (Copyright restrictions do not remove
it from being public domain). The status of such software which
originated in the USA is a bit unclear. There is a general licensing
requirement for anything reexported which originated in the USA ( unless
See the "Legal" section of
axion.physics.ubc.ca/pgp.html
the object has been significantly altered in Canada).
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Canadian Crypto Update!!!
Date: Wed, 25 Aug 1999 13:30:45 GMT
In article <7q0nt0$n8o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Just for you Tom, here's a link that I just found.
>
> http://securityportal.com/closet/closet19990825.html
>
> According to the article, any and all encryption products can be
> imported/exported from Canada. Woo-Hoo!!!
Isn't funny to note your US laws permit Canadians to have more freedom
with regard to crypgtographic 'munitions' :)
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Where to find
Date: Wed, 25 Aug 1999 15:27:05 GMT
In article <8NKw3.1$[EMAIL PROTECTED]>, Forrest Johnson
<[EMAIL PROTECTED]> wrote:
>In article <7prr6a$1m7g$[EMAIL PROTECTED]> SCOTT19U.ZIP_GUY,
>[EMAIL PROTECTED] writes:
>> It may be arrogance but I am sure many Navy Pilots owe me unknownly
>>for fixing many potentail dangerous errors introduced by the kind of
>>programers that some one of your limited back ground would respect.
>>
>Could you give us some idea of the places where you've done this kind of
>thing? I'm in the business of developing "airplanes and missiles" and I
>know several people who might be able to verify your claim of altering
>OFP code. (Please forgive the abbreviations and acronyms. Since they
>are all standard terms used in Navy weapons systems, I'm sure you know
>them, anyway.)
>
>What missiles and/or aircraft did you make changes on? Were you working
>with source code? If so, what was the contracting authority that gave
>you the source code? If you patched, what type of signature checks were
>running and how did you adjust for them? How did you reconcile the new
>version number with CM and the DD package? Who was the commanding
>authority that allowed your changes to be fielded?
>
>When did you make these changes? (Please give dates -- Navy regulations
>have banned the type of software modifications you're talking about for
>quite some time now.) Were you working as a contractor then or were you
>still in the Navy? If you were still in the Navy, where were you
>stationed at the time and what was your unit? What sort of equipment did
>you use to reprogram the changes you made? If you were a contractor,
>what company were you with? Where was it located?
>
>You mentioned fixing "potentail (sic) dangerous errors". If you were in
>the Navy when you discovered these errors, you had to have documented
>them so your fixes could be distributed throughout the fleet and we can
>look that up once you identify the weapons systems. Were these errors
>warhead related? If so, then your discoveries would have caused any
>affected weapon systems to be removed from carrier stores until the
>problem was resolved and we can look that up, too.
>
>What type of FQT did you run after your changes? Where did the OT&E of
>your new code take place? To what systems were your changes made?
>Avionics, GAC, Communications, FTE, FRE, Aero, ...? What type of changes
>did you make? Were you changing algorithms or data?
>
>Sorry about all the questions -- I'm just curious about these changes you
>made to these weapons systems and how you got them done.
Well look it up I wrote several papers in the 70's on quaterion
apporximations. These are Navy Papers and people at Ratheon
New York took copyes of these unclassified reports so can look
them up. As far as Y2K I did try to come out of retirement and
help fix the problems ( we use to complain to management about
it. But that is a waste of time). I taught UNIVAC assembly at CHINA
LAKE for a while. I was on call 24 hours aday in case the UNIVAC
crashed. I use to fix working programs the navy relied on that they
long ago lost the source code. The use of the product FLIT. I felt
that since my boss suggested I go back and help with Y2K that I
might as well look into it. I give my resume to the CSC office
in RIDGECREST. But I never heard back from them. But basically
if it FLEW or was related to FLYING I worked on it. One day bored
so even applied for a patent on some hardware stuff for the
Navy surely you can look that up.
But in the old days getting the job done was critical. Today that
is no longer true and CYA is the mode of today. It is much more
important to have a political correct working force that pretends to
be busy than to actually do anything. In the good old days getting
the job done was the key to everything. Then after work having a few
beers along with a burro roast would cap the day off.
If your buddies go to many DC meeting I was the guy in T-shirt
and shorts. Why wear anything else. Went to St. Paul with a young
lady engineer she asked on plane where is your suit. I said I am
wearing it. She thought I was joking until she saw me at meeting
and was shocked. When we got back she complained to boss.
He got a big laugh out of it and said she is new and a new way
of doing things is comming to the Navy. It is good we got to do
it our way when we could and know that it is tradition we really
don't have to change but new managers don't like it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: cryptographic DLL
Date: Wed, 25 Aug 1999 14:27:20 GMT
In article <[EMAIL PROTECTED]>, *@spam.ruud.org wrote:
>[EMAIL PROTECTED] (JPeschel) writes:
>
>> > David A Molnar <[EMAIL PROTECTED]> writes:
>>
>> >* but any crypto developed in Canada by Canadians (or other non-U.S.
>> >citizens outside the U.S.) _may_ be exported from Canada by Canadians (or
>> >other non-U.S. citizens) w/o license.
>> >
>> >So if none of your code was written in the U.S., you should be fine.
>>
>> I don't think so. Of the commercial Canadian crypto products I've looked at
>> each of the company's involved complied with US export regulations.
>> That Tom is giving away his code, I think, makes little difference.
>
>Another complication is that Tom is publishing his code from a web
>server which is physically located in the US, as far as I can tell.
>
I have taken Tommy off of my email reader kill list he was the only one
on it at the time. But if he has the balls to fight for what is right I for
one am greatful. I am not so brave. I think one gets more chicken as
one ages. But if one does not fight unjust and unfair laws then our
freedoms will dissapear. I think we should not tell him our fears. If
every one cowarded at the corruptness of new laws we would still
be paying tea tax to the evil british empire. Tommy do what you
think is right and you will sleep better at night. It may take many
years but if in your heart you know your doing the morally correct
thing do it. I feel crypto is vitial to the freedom of people every where
but am not yet willing to do all that it takes. I keep telling my self
some day I will take a more heroic stand against the current stream
of politicians turning our bill of rights into tiolet paper. But I don't
I fear I am like a smoker that says he can quit smoking and as
proof does so every night when he goes to sleep. But never
really gives it up till that long sleep at the end of life.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Wed, 25 Aug 1999 10:47:08 -0400
>
> My the very nature of information theory. All the information is
> there to break the code. That does not mean some one will find
> a way but in therory all the info is there. And if the attacker stubles
> on the soultion then he can tell exactly if he has the soultion.
> For symmetric methods the key is "secret" so there is real
> information to hide. And it takes a certain amount of code
> to even be able to theoritically have enough info to break the
> method.
Information theory tells as that an unconditionaly secure
crypto scheme is possible onely ifthe key lenght is as long as
the text lenght (note, I did not say if and only if).
Examples of this are the One Time Pad, and Quantum Crypto
(wich uses a One Time Pad...).
So _theoreticaly_, you do have alot of info about the message
hidden in a cipher, if you are enciphering a 1000 bit message
with a 128 bit key. If the message is in english, you have even
more info! Don't mixe zero-knowledge with this, the term
is used in a different context.
Anton
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: export legislation
Date: 25 Aug 99 14:09:22 GMT
[EMAIL PROTECTED] (Kurt Wismer) writes:
>could i inquire about the current state of affairs with regards to u.s.
>export restrictions on cryptographic software? (ie. is itar more or less
>still intact?)
Commercial, non-military crypto is no longer under ITAR but under the Dept of
commerce EAR.
See the end (LEGAL) of my page
axion.physics.ubc.ca/pgp.html
for a pointer to EAR.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: passphrases
Date: Wed, 25 Aug 1999 11:46:11 -0400
If your password is an 8 ASCII char password (like on Unix systems),
then brute force is possible. With a 16 ASCII char password, you are
pretty well (very well) safe do.
anton
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Wed, 25 Aug 1999 09:22:10 -0700
Since the days of empires, Roman, English, etc. Everyone has
imposed there will on others. So, what else is new?
http://www.aasp.net/~speechfb
* 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: John <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Wed, 25 Aug 1999 09:18:20 -0700
I agree, except, if we all start deciding what laws we like
and dislike, we have anarchy. I'll be happy to sign a
petition and push the congress to act.
http://www.aasp.net/~speechfb
* 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: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: One-time pad encryption.
Date: 25 Aug 1999 16:08:08 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony
L. Svanstrom) writes:
|> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
|>
|> > Claiming that reusing a use-once key is OK because the second use is
|> > indecipherable is like claiming that reusing a paper towel is sanitary.
|>
|> No, it's not; you are asuming that someone can get a copy of the text at
|> either end, that's a weakness in that end and not in the way that the
|> message was put together.
|> I'm sorry that I didn't state clearly enough that it was only the
|> security of the message as it's "traveling" thru non-secure channels
|> that I was interested in.
|>
Well, the top of this thread has fallen off the end of my news server,
so pardon me if I'm rehashing.
If you use a "one-time" pad, and the enemy gets the ciphertext of
both transactions, there is a weakness. The enemy doesn't have to
get either cleartext.
Assume you're using XOR OTP. Take two cleartexts A and B, and XOR OTP
encrypt both of them with OTP C. Your enemy gets both cyphertexts
A XOR C and B XOR C. XOR of these cyphertexts together gives you
A XOR B with A and B being cleartext. There are well known ways
to attack A XOR B where A and B are cleartext.
|>
|> /Tony
|> --
|> /\___/\ Who would you like to read your messages today? /\___/\
|> \_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
|> --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
|> DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
|> ---���---���-----------------------------------------------���---���---
|> \O/ \O/ �1999 <http://www.svanstrom.com/> \O/ \O/
--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Wed, 25 Aug 1999 09:24:23 -0700
I don't think you'll have to worry about Canada. Most of the
countries that have embargos, Iraq, Iran, etc. probably have
poor internet access as well. We don't only make laws, but
control the hardware, or blow up the cities to ensure
complience.
* 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: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Wed, 25 Aug 1999 12:25:29 -0400
JPeschel wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> >For the inquiring minds I am now a 'clueless-hacker' interested in
> >breaking the law or messing things up. I am quite lawful, xcept when
> >it comes to 'silly' laws made by crypto-clueless people. EAR is like
> >saying 'no car for you, you might hit someone' or 'no gun for you, you
> >might shoot someone' etc...
> >
> >Basically EAR rules are the wierdest most abstract useless laws I have
> >heard of. Make 'strong-crypto' illegal and we will all just become
> >criminals...
>
> Tom, you may be putting yourself in a difficult position, as the crypto
> export laws in Canada are quite similar to those in the US.
No, they are different in a crucial way. As I understand it,
freeware is NOT subject to any controls. That's why FreeS/WAN,
the Linux strong IPSEC implementation, was done in Canada.
Tom, you may want to change your answer to the question to
"EAR doesn't apply, I'm outside the US and not a US citizen".
paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: # XXIV of a series
Date: Wed, 25 Aug 1999 11:24:29 -0600
The previous application I did was Dabaka, which takes base 93 through
base 7 to base 26. The latest, Belfast, changes base 30 to base 26, also
through base 7. In fact, so much of the application between these two
programs is unchanged as 35 hepits are involved in transposition in both.
In considering base 30, I could have adapted it to a foreign character set
to follow up on another thread, I still could. Instead, I chose to handle
text as in base 27, normal text, JQX punctuation, and retained spaces.
In Belfast, the plaintext set actually includes 4 different
representations for a space. In effect, a single space character is
unloaded in the front end to make four of them each appear more like mere
frequent alphabetic characters. The result is to add some induction to
the ciphertext, so that with each encryption, random variations are
introduced into ciphertext. This minor, but noticable, effect is just
hinting at what other extended possibiities are available with this old
homophonic technique.
I could have made a substitution key for the base set, but to simplify
matters, don't. Here are the default keys:
Subs(Be): abcdefghijklmnopqrstuvwxyz
Trans(Be): abcdefghijklmnopqrstuvwxyz123456789
To show the inductive nature of Belfast, here are several equivalent Cts
using this sentence as Pts, and default keys.
skaju jgzkc ueerd ftdaj sejjy fxgsz nrovo rrqae cibaz ktmiw uhkuj xycbq
jukta jlxdg mglhx djehj hlvcg ukizl fnvgo avlen xbncf pnaqk oalie mabfn
ekleg g
sjuvy zguoc uaifm ftdaj sewco pggsz nrmhj hrqae cixbe ylriw ufshg jpcbo
xoqta jlxdg mcibg kwlxe dnagg ukscx fnvgo ayoxx ppncf pnaqs ikuae maaeg
ryweg g
sjuvy zgwzc ucwkw ftdaj septg zjgsx mbfhj hrqae cibaz ktiyl sdzuc vgcbo
xoqta jlxdg mcibg oafhj hlvcg uknoe fnvgo axnrm yoncf pnaqs ikuae macgt
psleg g
to show the inductive nature of belfastj here are several equivalent cts
using this sentence as ptsj and default keysxusto show the inductive
nature of belfastj here are several equivalent cts using this sentence as
ptsj and default keysxusto show the inductive nature of belfastj here are
several equivalent cts using this sentence as ptsj and default
keysxus...deductive recovered plaintexts
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Wed, 25 Aug 1999 20:10:36 +0200
[ Note: Because the discussion tree is again getting too deep, I am
attaching this follow-up to a node near the root of the tree.]
SCOTT19U.ZIP_GUY wrote:
>
> Well I told how the last huffman symbol is treated. Just like
> in IEEE floating point numbers not all the bits are there. In this
> case since not the start of the possible longest path through tree
> the all zero case and since at most there is alwasy a shortest
> path to a leaf of all ones being 8 or less. The compression program
> itself would not write out the excess ones to a new byte if it is the
> last symbol to by written and crossed a byte boudary.
I think that I know now more about your scheme than before, but I still
have difficulties:
Let's suppose that the code of a is 0101, the code of b is 100 and
the code of c is 0111. Then ab is encoded to
01011000
where the last bit is the filling 0. On the other hand, abc is first
encoded to
01011000 111
but finally becomes
01011000
due to your convention that an ending substring of all 1's that goes
into the last byte is omitted. Thus ab and abc would be encoded to
the same. Would you please tell what's wrong with my argument above?
M. K. Shen
------------------------------
** 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
******************************
