Cryptography-Digest Digest #117, Volume #13 Tue, 7 Nov 00 20:13:00 EST
Contents:
Re: XOR Software Utility (freeware) available from Ciphile Software (Andre van
Straaten)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: Help Needed with Public Key Cryptography (JCA)
Re: DMCA bans fair use ("Seeker")
Re: Help Needed with Public Key Cryptography ([EMAIL PROTECTED])
Purported "new" BXA Encryption software export restrictions (Anthony Stephen Szopa)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Anthony
Stephen Szopa)
Re: A question about RSA (Bob Silverman)
Re: MORE THAN FULLY BIJECTIVE ! ("Matt Timmermans")
Re: rijndael and public/private key encryption ("Matt Timmermans")
----------------------------------------------------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Date: Tue, 07 Nov 2000 23:21:34 GMT
In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <YH_N5.3261$[EMAIL PROTECTED]>,
> Andre van Straaten <[EMAIL PROTECTED]> wrote:
>> If you own a Microsoft OS you might have indeed to be very careful.
>>
>> I have only a Windows 95 on a dual-boot notebook which I use very
> rarely
>> and only for test purposes.
>>
>> I use at home FreeBSD where even the kernel is Open Source (motto:
> Don't
>> trust an OS which you don't have sources for).
>> [My NGs I read from 2 different Solaris servers.]
> Not that this isn't already OT, but do you honestly understand every
> component of <insert your fav open source OS>? I keep hearing about
> how wonderfull Linux is just because it's open source. Frankly you're
> all missing the point. The reason Linux is suppose to be better is not
> because it's open source, but because "real people" are making it.
> Unfortunately I have yet to ever get Linux to recognize my video/sound
> card so it's perfectly lame for my purposes... that's offtopic though...
> Tom
Well, the Open Source code discussion itself is not "sci" nor
"crypt".
And the same it is with promoting "xor freeware".
But with an OS it's the same as with a crypto program.
Even if someone doesn't understand the Open Source code, he/she
can show the source code someone else to check it for him/her.
In case that something smells suspicious.
(And on my notebook, the sound card works, plays MP3 and RealPlayer,
and silly Macromedia stuff in Linux emulation.
Generally, I don't need that, 'cause I'm concentrated to understand
the source code.)
;-)
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 07 Nov 2000 23:29:37 GMT
In article <1__N5.3304$[EMAIL PROTECTED]>,
Andre van Straaten <[EMAIL PROTECTED]> wrote:
> In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (those who know me have no need of my
> > name) wrote:
> >> <8u58vu$bpe$[EMAIL PROTECTED]> divulged:
> >> >How on earth did you make such a simple program take 155kb?
> >>
> >> ms windows + borland windowing and gui crapolla.
>
> > Well using CYGWIN or LCCWIN32 a similar program would take about
5kb...
>
> > Tom
>
> gcc or g++ produce code of similar size, but I found a simple xor
program for MS-DOS,
> which I compiled over a year ago with Borland using the default
switches, and it has
> .. 68 kB.
> A command line program with about 25 lines of code.
>
> (Where is the source code of that Borland compiler ?? \&/+@* ...
rant ...)
> ;-)
That's insane... learn how to trim executable sizes...
At http://www.geocities.com/tomstdenis/files/xor.c is a copy of the
same program that does most common error handling (read/write errors,
invalid file opens, etc...)... except for forgetting a "return 0;" at
the end of main()I think it's a complete application.
It's only 9kb when compiled with Turbo C 2.01...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Help Needed with Public Key Cryptography
Date: Tue, 07 Nov 2000 15:23:58 -0800
RSA-encrypting an 8 byte long number is easy; you only have
to pad as appropriate. However, the ciphertext will not in general
be 8 bytes long. This is all true for the usual RSA keylengths.
Your main problem is that a 512-bit key is too long for you.
This makes me think that RSA is not what you are looking for. You
can conceivably resort to a barebones RSA encryption/decryption
using 64 bit moduli. This would meet your length requirements all
right, but the result encryption encryption/decryption scheme would
be trivial to break with the current computing power: a 64 bit integer
is about 20 digits long in decimal, and factorizing integers that long
is a piece of cake for modern processors.
Maybe you'd like to look into elliptic curve crypto instead, although
I am afraid that the typical keylengths will still be somewhat bigger
than you would like.
Lee Hasiuk wrote:
> Is there a way to use a public key crypto system to encrypt an 8 byte
> long number, producing an 8 byte long result, while still maintaining
> any degree of security (i.e. approximately what a symmetric cipher
> would give with an 64-bit key)?
>
> The application is trailware registration numbers, where a user pays
> the vendor and supplies their 64-bit serial number (randomly generated
> at install time), and they get back a 64-bit registration key. The
> goal is to make it so that the registration key can't be generated
> using only information on the end-user's system. I realize that
> there are lots of other attacks possible on trialware applications,
> and that this is just one small facet of the problem.
>
> I've looked at RSA, but it appears that the encryted data is typically
> the same length as the modulus. For a reasonable modulus size, say
> 512 bits, that would make the registration keys too long. Is there a
> way to use RSA but to only send a portion of the encrypted data, but
> still be able to check that portion using the public key? Perhaps
> there's something better suited to my application.
>
> It's somewhat important that the algorithm be cheap or free and that
> the code used to check the registration numbers be small. Again, RSA
> is perfect, because it is free and since the largest part of the code
> is the key generation, and that isn't necessary in the code which
> checks the numbers.
>
> Thanks for your help!
>
> Lee Hasiuk
> [EMAIL PROTECTED]
------------------------------
From: "Seeker" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DMCA bans fair use
Date: Wed, 08 Nov 2000 00:04:46 GMT
What does this mean to the providers of password recovery software and
services?
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The Digital Millennium Copyright Act (DMCA) is a US law that
> attempts to ban fair use of copyrighted materials if it involves
> the circumvention of snake-oil crypto. This is the law that banned
> links to DeCSS, the DVD circumvention code. The criminal aspect
> of the law is about to kick in, with the Copyright Office
> authorized to list some exemptions. There was some hope that there
> would be a number of exemptions, such as crypto research.
>
> The Copyright Office just declared that only two classes
> of works are exempted from prohibition against circumvention.
> They are:
>
> (1) Compilations consisting of lists of websites blocked by
> filtering software applications; and
> (2) Literary works, including computer programs and databases,
> protected by access control mechanisms that fail to permit access
> because of malfunction, damage or obsoleteness.
>
> For full details, see:
> http://www.loc.gov/copyright/1201/anticirc.html
>
> (Please restrict political follow-ups to talk.politics.crypto.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help Needed with Public Key Cryptography
Date: Wed, 08 Nov 2000 00:08:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Lee Hasiuk) wrote:
> Is there a way to use a public key crypto system to encrypt an 8 byte
> long number, producing an 8 byte long result, while still maintaining
> any degree of security (i.e. approximately what a symmetric cipher
> would give with an 64-bit key)?
First let's ask the obvious question. Why are you set on 64-bits? It
appears that you are depending on the user to type this number in, to
avoid it being copied. Instead how about, the trialware program
generates a computer statement (things like CPU ID, HDD ID, MAC
address, etc), it sends that statement to the server along with a proof
of payment coupon (which the user may very well have to enter
him/herself, but is one time). The root server takes that information,
verifies the freshness and authenticity of the payment coupon, signs
the computer statement, and sends the signature back. When the
trialware needs to verify the correctness of the computer, it retrieves
the information, and checks the signature. The user won't even be
forced to type in an excessively large number, just the coupon size,
which 64-bits should be sufficient. It's far from perfect but if it
fits what you need feel free to use it (I am not aware of any issues,
however I take no responsibility, if you are concerned consult a very
good lawyer).
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto,alt.hacker
Subject: Purported "new" BXA Encryption software export restrictions
Date: Tue, 07 Nov 2000 16:17:49 -0800
Purported "new" BXA Encryption software export restrictions
I have had time to look up these purported new BXA regs.
But first let me digress.
The OAR-L3 random number generation software is exactly the same
software as OAP-L3: Original Absolute Privacy - Level3 encryption
software except there is absolutely NO encryption or decryption
capability.
Not only have the encryption and decryption GUI forms, menus,
buttons, etc. been deleted, but also, the encryption and decryption
source code has been deleted, then the entire package recompiled.
So there is no way to enable any encryption or decryption methods
or capabilities using OAR-L3.
You can download OAR-L3 Random Number Generation Software by
going to http://www.ciphile.com
Go to the Downloads Currently Available web page.
Scroll to the bottom of the page.
Click on the blue anchor tag: OARL3_41.zip and ReadMe_R.zip to
download.
There is a new XOR Software Utility (freeware) available at
http://www.ciphile.com
Go to the Downloads Currently Available web page.
Scroll to the bottom of the page.
Click on the blue anchor tag: CiphileXOR_11.zip to download.
OAP-L3 encryption software uses the XOR process to encrypt messages.
Now my comments and decision regarding these purported new BXA regs:
Except for (I think) there are no longer any restrictions on key
length and that the software can be exported immediately, there is
one major proviso in any case:
The exporter needs to file an encryption classification request by
the time the encryption software is exported. Here is what the
exporter must do:
"For all classification requests of encryption items provide
brochures or other documentation or specifications related to the
technology, commodity or software, relevant product descriptions,
architecture specifications, and as necessary for the technical
review, source code. Also, indicate any prior reviews and
classifications of the product, if applicable to the current
submission. Provide the following information in a cover letter
with the classification request:
(a) State the name of the encryption item being submitted for
review.
(b) State that a duplicate copy has been sent to the ENC
Encryption Request Coordinator.
(c)For classification request for a commodity or software,
provide the following information:
(1) Description of all the symmetric and asymmetric encryption
algorithms and key lengths and how the algorithms are used. Specify
which encryption modes are supported (e.g., cipher feedback mode or
cipher block chaining mode).
(2) State the key management algorithms, including modulus
sizes, that are supported.
(3) For products with proprietary algorithms, include a textual
description and the source code of the algorithm.
(4) Describe the pre-processing methods (e.g., data compression
or data interleaving) that are applied to the plaintext data prior
to encryption.
(5) Describe the post-processing methods (e.g., packetization,
encapsulation) that are applied to the cipher text data after
encryption.
(6) State the communication protocols (e.g., X.25, Telnet or
TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS standards)
that are supported.
(7) Describe the encryption-related Application Programming
Interfaces (APIs) that are implemented and/or supported. Explain
which interfaces are for internal (private) and/or external (public)
use.
(8) Describe whether the cryptographic routines are statically
or dynamically linked, and the routines (if any) that are provided
by third-party modules or libraries. Identify the third-party
manufacturers of the modules or toolkits.
(9) For commodities or software using Java byte code, describe
the techniques (including obfuscation, private access modifiers or
final classes) that are used to protect against decompilation and
misuse.
(10) State how the product is written to preclude user
modification of the encryption algorithms, key management and key
space.
(11) For products that qualify as ``retail'', explain how the
product meets the listed criteria in Sec. 740.17(b)(3) of the EAR.
(12) For products which incorporate an open cryptographic
interface as defined in part 772 of the EAR, describe the Open
Cryptographic Interface.
(d) For classification requests regarding components, provide
the following additional information:
(1) Reference the application for which the components are used
in, if known;
(2) State if there is a general programming interface to the
component;
(3) State whether the component is constrained by function; and
(4) the encryption component and include the name of the
manufacturer, component model number or other identifier.
(e) For classification requests for source code, provide the
following information:
(1) If applicable, reference the executable (object code)
product that was previously reviewed;
(2) Include whether the source code has been modified, and the
technical details on how the source code was modified; and
(3) Include a copy of the sections of the source code that
contain the encryption algorithm, key management routines and their
related calls."
IN EFFECT NOTHING HAS CHANGED.
I am not able to go through all this hassle.
I am sorry.
AS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Wed, 08 Nov 2000 00:23:39 GMT
In article <280O5.729$[EMAIL PROTECTED]>,
Andre van Straaten <[EMAIL PROTECTED]> wrote:
> In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <YH_N5.3261$[EMAIL PROTECTED]>,
> > Andre van Straaten <[EMAIL PROTECTED]> wrote:
> >> If you own a Microsoft OS you might have indeed to be very careful.
> >>
> >> I have only a Windows 95 on a dual-boot notebook which I use very
> > rarely
> >> and only for test purposes.
> >>
> >> I use at home FreeBSD where even the kernel is Open Source (motto:
> > Don't
> >> trust an OS which you don't have sources for).
> >> [My NGs I read from 2 different Solaris servers.]
>
> > Not that this isn't already OT, but do you honestly understand every
> > component of <insert your fav open source OS>? I keep hearing
about
> > how wonderfull Linux is just because it's open source. Frankly
you're
> > all missing the point. The reason Linux is suppose to be better is
not
> > because it's open source, but because "real people" are making it.
> > Unfortunately I have yet to ever get Linux to recognize my
video/sound
> > card so it's perfectly lame for my purposes... that's offtopic
though...
>
> > Tom
>
> Well, the Open Source code discussion itself is not "sci" nor
> "crypt".
> And the same it is with promoting "xor freeware".
>
> But with an OS it's the same as with a crypto program.
> Even if someone doesn't understand the Open Source code, he/she
> can show the source code someone else to check it for him/her.
> In case that something smells suspicious.
>
> (And on my notebook, the sound card works, plays MP3 and RealPlayer,
> and silly Macromedia stuff in Linux emulation.
> Generally, I don't need that, 'cause I'm concentrated to understand
> the source code.)
> ;-)
>
Problems with my drivers I complain until they are fixed. About the
same speed as in OS.
OS is only relevant when security is concerned. Personally I don't
care how the mouse works, only that it does. But I do want to be able
to ensure that my crypto is ok...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: Tue, 07 Nov 2000 16:32:40 -0800
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Hawke <[EMAIL PROTECTED]> wrote:
> > sorry for the massive crosspost...
> >
> > too bad this software is winblows only.
> > it'd be nice to have an app like this in linux...
>
> You are kidding right?
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
The software does what it says it does and this fellow seems to
think he has need or feels he may have need for such a program.
So you feel you have the right and need to ridicule him?
Can you stoop any lower?
Show this fellow some respect and write him a similar program for
Linux.
Here are the specs: the ability to select any two files from any
two drives/directories and logically XOR them outputting the
resulting file to any drive/directory. Stopping the XOR process
upon reaching the end of file of the shortest file selected. And
allow for any file length to be processed.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: A question about RSA
Date: Wed, 08 Nov 2000 00:29:32 GMT
In article <[EMAIL PROTECTED]>,
Chenghuai Lu <[EMAIL PROTECTED]> wrote:
> Suppose we know n (= p * q), which is a multiple of two large primes,
> and phi(n) where phi(x) is the Euler function. Can anybody give the
> algorithm to find p and q in polynomial time?
Hint: You have two equations in two unknowns. Try high school
algebra.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: MORE THAN FULLY BIJECTIVE !
Date: Wed, 08 Nov 2000 01:06:24 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8u9gcr$q6o$[EMAIL PROTECTED]...
> Using CBC with a fixed IV is not particularly a good idea.
>
> Tom
>
Not particularly useful, you mean -- a fixed IV doesn't preserve all the
nice properties of CBC mode. CBC after whitening is almost as good as CBC,
though, except that an attacker can detect repeated messages sent with the
same key -- and there's nothing you can do about that if you have a strange
requirement for injective encryption.
David, in this message, says simply that a surjection would serve his
purposes just as well, and so an IV can be supplied.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: rijndael and public/private key encryption
Date: Wed, 08 Nov 2000 01:09:14 GMT
Since you're wrote that post as an implementor, you should probably know
that symmetric block ciphers _are_ used in public key encryption. You
encrypt the message using, say, Rijndael, with a random key, and you encrypt
only the random key using a public key algorithm. Then you send both. This
is benefitial, because symmetric ciphers are _much_ faster than public key
algorithms.
------------------------------
** 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
******************************
