Cryptography-Digest Digest #107, Volume #10 Tue, 24 Aug 99 23:13:02 EDT
Contents:
Re: cryptographic DLL (David A Molnar)
Re: What the hell good is a session key!
Re: cryptographic DLL (Greg)
Re: cryptographic DLL (JPeschel)
Re: crypto RNG and permutations (Tom St Denis)
Re: cryptographic DLL (Tom St Denis)
Re: cryptographic DLL (Tom St Denis)
Re: Help: DES Encryption -> ASCII ([EMAIL PROTECTED])
Re: Where to find (Tim Redburn)
Re: Help: DES Encryption -> ASCII (Tom St Denis)
Re: US export laws re Canada (Robert Guerra)
Clear things up about PeekBoo/CDLL (Tom St Denis)
passphrases ([EMAIL PROTECTED])
Re: passphrases (Tom McCune)
Re: cryptographic DLL (JPeschel)
What the hell good is a session key! (Anonymous)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: cryptographic DLL
Date: 24 Aug 1999 22:28:37 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Pardon my ignorance of EAR and crypto-law but what does being Canadian
> have anything todo with this? I though the US (i.e Bush) made sure
> that the reach of 'crypto-laws' extended well to Canada....????
As I understand it,
* it is legal for a U.S. citizen to export crypto to Canada
* A Canadian can not "re-export" any U.S. crypto outside of Canada and
the United States without a license
* 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 do remember reading a rumor that the regulations had changed; if anyone
can confirm or deny that would be appreciated (note crosspost). Or just
tell me I'm wrong from the start.
-David
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: What the hell good is a session key!
Date: 24 Aug 99 22:08:47 GMT
Anton Stiglic ([EMAIL PROTECTED]) wrote:
: > [...] used to transfer session keys for a
: > symmetric
: > algorithm, symetric encryption being much harder to crack and
: > mathematically more secure than asymetric algorithm for any given key
: > length, meaning shorter keys (more performance) can be used for the
: > actual grunt work of the session, and meaning less ciphertext exposed
: > for analysis for any given key.
: symetric schemes much harder to crack? I might mention that alot of cryptologues
: beleive strongly that asymmetric encryption is much harder to break.
It is known - not conjectured - that a 128-bit long number, which is the
product of two primes, can be factored with today's technology.
Many symmetric encryption methods with 128-bit keys have not been broken,
and if a symmetric encryption method is good enough that brute-force is
the best way to break it, an attack with 2^128 steps takes much longer
than factoring a 128-bit number.
So in that sense, the statement you quoted is quite accurate. Perhaps a
better way to phrase it is that public-key cipher systems (but this is
less true of elliptic curve cryptography) require longer keys for security
than symmetric-key cipher systems.
Doubtless there are cryptologists who believe that symmetric-key
algorithms are not as secure as commonly believed, and that we can rely on
the mathematical basis of public-key systems to tell us that they are
secure if any problem, including solving the other kind of cipher system,
the symmetric-key one, is actually hard.
However, the other view is also widely held: that symmetric-key
cryptography is inherently safer, since a symmetric-key cipher can have
one complication after another piled on it, while public-key cryptography
is limited to resting on a limited number of definite problems, such as
discrete log and factoring, for which specific solutions may be found in
the future because they are related to much of concern in mathematics for
other than cryptographic reasons.
Characterizing symmetric-key encryption as being _potentially_ more secure
for any given key length is quite reasonable. For sufficiently large keys,
however, it may be true that we don't yet know how to design a
symmetric-key cipher whose true security matches what its key length would
make theoretically possible, such as one with a 4096-bit key that could
not be solved faster than by brute force.
John Savard
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:15:18 GMT
> > Also, you're Canadian, aren't you ?
>
> Pardon my ignorance of EAR and crypto-law but what does being Canadian
> have anything todo with this? I though the US (i.e Bush) made sure
> that the reach of 'crypto-laws' extended well to Canada....????
I don't see how that can really be enforceable from a US point of
view. Canada can take any position it wants to no matter how rabid the
Commerce department gets.
--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: cryptographic DLL
Date: 24 Aug 1999 22:40:45 GMT
> 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.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: crypto RNG and permutations
Date: Tue, 24 Aug 1999 22:38:52 GMT
In article <7pt7q2$9nc$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I programmed a crypto RNG that works like this
>
> i = cycle length (between key swaps)
> b = number of blocks in a key
Duh!!! I can answer this myself (hehehe)
If you know 'i' blocks and there are 2^w possible blocks.... you get a
equation like
Ke = 1
for n = 0 to (b - 1)
ke = ke * (2^w - i - n)
... duh!!!
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:35:48 GMT
In article <7pv6fa$ktr$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> He wants to make a statement- he wants to go to jail.
>
> And such a waste of a youthful life. So much tyranny to fight, so
> little time.
I most certainly do not. Besides I am a crypto-nobody. Ask Eli Biham
or Ron Rivest who 'Tom St Denis' is ...
I am not trying to make a stmt or anything else. I am trying to
release crypto code (in a usefull form). If the govt' things I am an
ennemy let them go... it might prove interesting.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:42:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> 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.
Hmm... it will give me something todo.
Not to be rude, but have you (or Greg) actually looked at the code? I
want suggestions on what to add/fix/change/update. That's why I
released it.
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]
Subject: Re: Help: DES Encryption -> ASCII
Date: Tue, 24 Aug 1999 23:25:42 GMT
Hi,
Thanks for the reply. I want to use DES in an Embedded System to store
some access information and I want this file to be in Human readable
form. I don't have uuencode on it and porting all this may not be
feasible and costly to peform.
I am using 56 bit DES as someone suggested me that this algorithm is
exportable outside US.
Can I use PGP for this purpose?. Mine is a new application, so I have
the liberty to chose one. Is PGP exportable ( I guess so as many people
use it on the net)?. Can I use PGP without any restrictions.
Thanks and regards,
Mohan.
In article <7put7p$dgr$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7puoov$a5s$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > Can I use the DES encryption to generate an ASCII encrypted string
so
> > that I can save it in a text file?.
> >
> > Or do I have store the most significat bits of all bytes and append
> > some more ASCII bytes containing these bits to the encrypted buffer
so
> > as to make the whole string ASCII?.
> >
> > I would appreciate if someone can point me to some links.
>
> Well you could simply uuencode the binary data to the text file. But
> as you might have already noted DON'T USE DES. If this is a new
> application seek out another algorithm. If it's an older/compliant
> application use uuencode (on the DES output).
>
> 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.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Where to find
Date: Tue, 24 Aug 1999 22:56:58 GMT
On Mon, 23 Aug 1999 06:25:54 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
>Redburn) wrote:
<snip>
> But is still was over one million bytes. There is a patch
>for this.
<snip>
The point I was making is that there ARE suggestions that the
algorithm might not be a strong as claimed. Yes they are only
suggestions - no-one has yet demonstrated a concrete weakness.
** Fact **
You have performed only a nominal *analysis* of the algorithm. Simply
running randomness tests on the output does NOT constitute analysis.
** Fact **
The nominal analysis that you did perform was shown to be inaccurate.
** Fact **
The main security claim for the algorithm is in the impractical key
size. The other security claim is about the chaining mode used.
The claim being, not that there is some provable mathematical reason
why it makes cryptanalysis harder, but simply that it forces the whole
file to be decrypted before you can know if youre decryption was
successful.
>The new version will use a diffeent form of the key file.
New version ? But I thought the existing versions were supposed
to be the most amazing algorithms around ? Why do you need
to write a new version if there are no problems with the existing
ones ? In fact why is there more than 1 version already ?
<snip>
>>and many others managed to spot the error and I am only
>>a beginner in cryptography (I can't speak for the others)).
> Interesting attack I think your slam will carry great weight with
>those to lazy to look at the method. You did not show any real
>weakness.
A real weakness in the algorithm ? No.
A weakness in the ability of the designer ? Yes.
All I am trying to do is backup the claim that there **are clues**
that there **might** be weaknesses in the program.
>You pointed out that if some use a uniform random
>raw key file. that instead of 1.2 million byte of entropy you get
>about 1 million bytes. How does this compare to a 128 bit key
>which has ony 16 bytes of entropy. Yes I can see you are just
>a begnner becasue you think they are close. I guess I overated
>you ability. Sorry!!
What I find interesting is that you are unconcerned by the fact that
a brute force attack is around 2^1600000 times easier than you
originally believed. (using the figures you list above).
<snip>
>. I posted the patch to fix this error.
>I suppose you think all software is bug free on the first relase.
So now you're saying that even the source code isn't a reliable
reference of your algorithm (because it is likely to have mistakes
in it). How do we know what are quirks or your algorithm and what are
bugs (see later). You keep referring people to the source for a
description of the algorithm, but now you tell us that even that might
not be accurate !!
>>there are and whether things are intentional or not. (was accessing
>>unallocated memory used to obtain a weak random number ? It
>>could have been .....not likely but without the algorithm how can we
>>be sure ?)
> Well since your just a beginner like you stated you can't be
>sure. I guess we will have to wait for some more advanced to
>let us know the anwser to that one.
Only you can answer that one with certainty. It doesn't matter
how advanced a programmer, unless you tell them, they wont
know for sure whether accessing unallocated memory was intentional
or not. Most OS's wouldn't let you, but scott19u.zip only works
on MSDOS, and accessing unallocated memory on MSDOS is
permitted - is this the reason why it only works on MSDOS ??
<snip>
> IN november the next level comes out with all patches. At least
>that is my plan
Patches ? But I thought scott19u.zip was perfect and to be used
for a reference of your amazing encryption routine ?
<snip>
> I design as I code.
In other words ..... You made it up as you went along.
> Which is the way I have coded the last 30 years
>and airplanes and missles count on my ability to do this.
How many cruise missiles went astray in Serbia ?
<snip>
> Yes I have run many tests. MYSELF
>but mostly various test to check on diffusion and various correlations
>to see how it stand up to differiantal attacks.
OK, Maybe somebody could explain to me if it is possible to check
resistance to differential cryptanalysis simply by running tests ...
I was under the impression it required an analysis of the algorithm
to be performed. I must have misunderstood. Could you please explain
in general terms how this is achieved.
> A lot of thought went
>in to the design but I did it all myself. So it that pisses you off to
>bad. Either test it your self or don't use it.
>
Would you care to give an overview of the design considerations ?
What circumstances you expected it to be used, and how the design
desicions help this ......
-Tim.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Help: DES Encryption -> ASCII
Date: Wed, 25 Aug 1999 00:16:11 GMT
In article <7pv9l9$neb$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
>
> Thanks for the reply. I want to use DES in an Embedded System to store
> some access information and I want this file to be in Human readable
> form. I don't have uuencode on it and porting all this may not be
> feasible and costly to peform.
>
> I am using 56 bit DES as someone suggested me that this algorithm is
> exportable outside US.
>
> Can I use PGP for this purpose?. Mine is a new application, so I have
> the liberty to chose one. Is PGP exportable ( I guess so as many
people
> use it on the net)?. Can I use PGP without any restrictions.
You don't make any sense (Or I missed something). You said you are
doing an embedded system (smartcard type cpu?) where DES would be
usefull
a) look at the AES ciphers regarding 6805 cpus... They are better then
DES and work well (rijndael is a good bet).
b) What does PGP have todo with this? PGP is a desktop platform
program, not terribly usefull for cards with 2KB ram and 1KB rom ...
I would suggest doing more research.
Simple 3 to 4 schemes (i.e read 6-bits of binary, and use a LUT to
output ascii) are not hard to code at all.
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: Robert Guerra <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: US export laws re Canada
Date: Mon, 23 Aug 1999 19:23:06 -0400
In article <[EMAIL PROTECTED]>, dave
<[EMAIL PROTECTED]> wrote:
> According to two articles in "Canadian Machinery and Metalworking", the
> USA passed amendments to the InternationalTraffic in Arms Regulations
> in April of this year that revoked Canada's exemption from this
> regulation.
the government agencies which control arms and software are different.
Although restrictions have been placed on arms, i haven't read anything
about restrictions being placed on software.
The topic was discussed on the pgp-user's list a while back, and it's
archives are available at http://pgp.rivertown.net
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Clear things up about PeekBoo/CDLL
Date: Wed, 25 Aug 1999 00:12:21 GMT
Ok well I am from Canada, so if the crypto-rules don't apply to us
canucks, enjoy.
I really just wanted to release software that people can use, no fuss.
http://people.goplay.com/tomstdenis/pb.html
or
http://people.goplay.com/tomstdenis/cdll.zip
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]
Subject: passphrases
Date: Tue, 24 Aug 1999 20:33:09 -0700
It has been said that it's wise to change your passphrase often to stay
secure.
However, consider this:
Lets assume you pick a very good passphrase that has sufficient entropy
(i.e. many random characters, numbers, and punct.) that you can easily
remember. Since this passphrase cant be guessed or brute forced in a
resonable time, your data will remain secure for a long time.
But, if there is a hole in your implementation such that the key can be
recovered (like a key logger, swapfile, slack disk, EMI, etc.), then it
doesn't matter how often you change your passphrase, you're screwed!!
Therefore, as long as you have no holes and a very good passphrase, you
don't have to change it.
Any opinions?
------------------------------
From: [EMAIL PROTECTED] (Tom McCune)
Subject: Re: passphrases
Date: Wed, 25 Aug 1999 02:16:31 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>It has been said that it's wise to change your passphrase often to stay
>secure.
>However, consider this:
>
>Lets assume you pick a very good passphrase that has sufficient entropy
>(i.e. many random characters, numbers, and punct.) that you can easily
>remember. Since this passphrase cant be guessed or brute forced in a
>resonable time, your data will remain secure for a long time.
>
>But, if there is a hole in your implementation such that the key can be
>recovered (like a key logger, swapfile, slack disk, EMI, etc.), then it
>doesn't matter how often you change your passphrase, you're screwed!!
>
>Therefore, as long as you have no holes and a very good passphrase, you
>don't have to change it.
I'm just an amateur, but pretty much agree with you. I have a good
passphrase for my PGP key - good enough that I have some fear of the
possibility of forgetting it. If I had to frequently change it, such as I
do at work, it would have to be a much weaker passphrase so that I could
remember the new one all the time (my work passphrase is therefore weak).
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: Tom McCune's PGP Pages: http://www.borg.com/~tmccune/PGP.htm
iQCVAwUBN8NR+cMxrQ5/VTwtAQF+oQP8DKiu1EPJO/zcLYnHpFxat88VIB5AbmYi
K8gk3Kah1IrfhDoYDHub/lmfuUKr6Ox2Xqlj8e4fK39igXcEORWjlqKF7cz/won+
05cJ8cIn3Rq7WpkXem9JEyLRwyrmq5ib7rkQLisE/CYTOwenlxMwprpLHVsj4pNO
U1pV4LN0oJ8=
=RLIM
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: cryptographic DLL
Date: 25 Aug 1999 02:39:52 GMT
>Tom St Denis <[EMAIL PROTECTED]> writes:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (JPeschel) wrote:
>> 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.
>
>Hmm... it will give me something todo.
>
It certainly may give you something to do if you are exporting
strong crypto. PRZ was prosecuted (or persecuted) for several years by the
US before the government finally dropped its case.
>Not to be rude, but have you (or Greg) actually looked at the code? I
>want suggestions on what to add/fix/change/update. That's why I
>released it.
No, I haven't looked at the code and likely won't have the time or
a reason to.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
Date: Tue, 24 Aug 1999 16:18:55 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: What the hell good is a session key!
Using only conventional encryption (like PGP if you check the conventional
box) if an attacker can brute-force your session key in a month, then they
can certainly subsequently brute-force your master key, if it is the same
length. So it takes two months rather than one, big deal! If someone got
your session key by other than brute-force (a valid advantage of using a
session key) then you have problems anyway; the attacker could probably get
whatever they want. Even if they only got lucky, and brute-forced just ONE
session key, if that information could put you in jail, you go to jail
anyway, without the exposure of any other keys. As for public-key master
keys, if an attacker can brute-force a 128+ bit session key in the first
place, you better worry a bit about your public keys too.
In addition, someone might suggest using double encryption or multipass
compression, or some other such thing. But consider the fact that those
methods would not affect the number of possible keys, just the work factor
of testing each one. Most e-mail messages are fairly short, so it should not
make the search much more difficult. And on a related issue, remember that
theory tells us that we don't even need known plaintext to do a brute-force,
just a few blocks of language TEXT will do fine. If you send graphics, a
speadsheet, etc as an attachment, there will be known plaintext blocks
anyway. (Headers, signatures, etc)
Conclusion: if an attacker can do a brute-force for one key, if your only
protection is that they would need to brute-force two keys, or need more
than one block, you need to worry some.
Just some things to consider.
George Gordon
------------------------------
** 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
******************************
