Cryptography-Digest Digest #130, Volume #13 Thu, 9 Nov 00 13:13:00 EST
Contents:
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware ("Trevor L. Jackson,
III")
Re: Purported "new" BXA Encryption software export restrictions (Kent Briggs)
Re: Purported "new" BXA Encryption software export restrictions ("CMan")
Re: Rijndael Key Schedule (John Myre)
Re: RSA security (Francois Grieu)
Re: RSA security (Bob Silverman)
Re: hardware RNG's (Dan Oetting)
new gchq challenge... ([EMAIL PROTECTED])
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software (Tom
St Denis)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Paul Schlyter)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Richard
Heathfield)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
----------------------------------------------------------------------------
Date: Thu, 09 Nov 2000 10:27:40 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> Dido Sevilla <[EMAIL PROTECTED]> wrote:
> >Tom St Denis wrote:
> >>
> >> Perhaps you missed the boat, OTP's are not practical solutions!
> >>
> >
> >There are applications for which OTP's can be useful. The only reason
> >why OTP's are not practical is the extremely onerous key distribution
> >problem involved in their use. But some applications where, for
> >instance, data gets protected statically, e.g. files on your hard disk
> >with keys kept on removable media (kept in a secure location of course),
> >and for applications where only short messages need to be infrequently
> >transmitted, thus the key distribution operation is not so hard, e.g. by
> >exchanging removable media physically for example.
>
> If you use a OTP, the key will be as large as the data you want to
> protect. Now, if you want to protect data on your disk using OTP,
> storing the keys on "removable media kept in a secure location", then
> you might as well transfer your sensitive data to that removable media
> instead and store it in a safe location: the encrypted data will be
> inaccessible without the OTP key on the removable media anyway, and if
> you lose that key, you might as well have lost your data. Right?
>
> The best use of a OTP is if you meet someone with whom you'll later need
> to exchange sensitive data: then exchange a OTP key, to later be used
> to encrypt that sensitive data.
>
> Using OTP to encrypt your local harddisk is quite useless.
It depends upon the threat model. If the threat model is someone snooping
the disk than OTP either reduces the utility of the system to ~0 or it leaves
the system vulnerable to the threat.
However, if the threat is one of _seizure_, then an OTP with the pad stored
in volatile memory can be quite useful.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Purported "new" BXA Encryption software export restrictions
Date: Thu, 09 Nov 2000 15:26:58 GMT
CMan wrote:
> I encourage anyone who has swallowed the lies put forth by the White House
> on encryption policy to go to the BXA web site and read the regs.
>
> NOTHING HAS CHANGED!!!!!!!
>
> The encryption regulations HAVE NOT BEEN RELAXED!!!
Not true. I sell three different encryption programs. Previously I was limited
to 40-bit strength in the versions I could sell outside of the US/Canada. That
was increased to 56-bit strength a couple of years ago and then earlier this
year I got them all reclassified as "Retail" and can now sell the full 160-bit
versions anywhere except to the T7 embargoed countries. I've got the paperwork
to prove it. And the fully functional shareware versions are on my web site.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto,alt.hacker
Subject: Re: Purported "new" BXA Encryption software export restrictions
Date: Thu, 9 Nov 2000 08:27:50 -0700
Opps, that would be Commerce Secretary Daley...of the Chicago "Vote early,
vote often" Daleys.
JK
"CMan" <[EMAIL PROTECTED]> wrote in message
news:Q%eO5.688$[EMAIL PROTECTED]...
> At the time the White House held a news conference to announce that they
had
> "relaxed" the encryption regulations I was convinced that the White House
> was again lying about what was being done re: encryption.
>
> At that news conference Attorney General Janet Reno was asked if the new
> regulations had changed anything. She at first avoided the question. Then
> the reporter pointed out that she had not answered the question and
> repeated, What has changed?" Her reply in a rare fit of honesty was
"Nothing
> has changed!"
>
> The White House, staff putting on this incredible dog and pony show
> involving that idiot Commerce Secretary Casey, was of course apoplectic at
> this truthful answer.
>
> I encourage anyone who has swallowed the lies put forth by the White House
> on encryption policy to go to the BXA web site and read the regs.
>
> NOTHING HAS CHANGED!!!!!!!
>
> The encryption regulations HAVE NOT BEEN RELAXED!!!
>
> Read the classification procedure. There is still unconstitutional prior
> restraint!!! I'd rather fill out a thousand tax returns than try to comply
> with these regulations. There is NO WAY anyone could become compliant
> without expert legal counsel and then only if your code passes review and
> meets unpublished requirements - like backdoors maybe - or "workfactor
> reduction fields."
>
> I can't believe they were able to pull the wool over the eyes of our
famous
> cryptographer friends who have written popular books on cryptography -
> unless these guys now have corporations and big fat government
contracts!!!
>
> Hey BXA, give me a big fat government contract and I'll stop pointing out
> the emperor's lack of clothing just like the rest of them!! C'mon, share
the
> wealth...
>
>
> JK
>
>
> --
> CRAK Software
> http://www.crak.com
> Password Recovery Software
> QuickBooks, Quicken, Access...More
> Spam bait (credit E. Needham):
> root@localhost
> postmaster@localhost
> admin@localhost
> abuse@localhost
> webmaster@localhost
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
>
>
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > 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: John Myre <[EMAIL PROTECTED]>
Subject: Re: Rijndael Key Schedule
Date: Thu, 09 Nov 2000 08:26:57 -0700
Trish Conway wrote:
<snip>
> And why have the 4 other AES finalist algorithms ensured that the subkeys
> are derived from the userkey in a more complex fashion?
<snip>
This is a good question, and I hope somebody competent will
address it. I don't know the answer. Don't forget, the other
AES finalists would certainly not have bothered to make their
key scheduling longer if they weren't sure they needed it.
In general, it is certainly true that you have to look at a
cipher in its entirety: you can't conclude insecurity from
a single element. So a good answer to this question would
indicate, in a general way, how the structure of Rijndael is
expected to remove the need for complex key scheduling, as
compared to, say, Twofish.
JM
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: RSA security
Date: Thu, 09 Nov 2000 16:42:51 +0100
"Martin Otten" <[EMAIL PROTECTED]> wrote:
> You mean, instead of using very strong asymetric encryption all
> the time, I should use a 512 bit RSA just for transmitting a
> 128 symetric key for the main data, because symetric en/decoding
> is much more faster.
Yes. Note that 512 bit is a bare minimum, because this key will
be a long-term key (reused from session to session) and 512 bit
is factorable now, though with considerable effort (was done
publicly once only, in mid 1999, by leading researchers using
many workstations and a Cray with lots of memory). Better be safe
and go to 1024 bits, which looks like safe for some time.
> The problem is to get a good random number, right ?
Right. Not easy. There are simple solutions if you have permanent
memory (EEPROM, hard disk) in your device, but they come with a
risk (if someone reads your device once, it can predict the
next session keys).
> What is PKCS#1v2
A standard on using RSA. It teaches, among other things, how to
format data before enciphering to work around possible problems
(like: if you use public exponent 3 and you encrypt 128 bit
naively with a 1024 bit key, there is no modular reduction
at all because 128*3<1024, and a mere regular cubic root extraction
recovers the message; there are many other, more subtle pitfalls)
See <http://www.rsasecurity.com/rsalabs/pkcs/>
Francois Grieu
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA security
Date: Thu, 09 Nov 2000 16:12:00 GMT
In article <8udvit$1fhdt$[EMAIL PROTECTED]>,
"Martin Otten" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I want to use RSA for encryption.
Is there some reason in particular to use RSA?
RSA is best used for signatures or key transport and
not bulk encryption.
The problem is this encryption must be
> very fast ( I have to do it 20 times a second for packets about 256
byte,
> and this should not take more than 1% of a modern CPU).
Then use a symmetric key. Use RSA as a digital envelope to
transport it.
The security must
> not be very strong, since an encrypted session is only <25 minutes
long,
400 bits should be fine for the RSA key for that level of security.
--
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: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Thu, 09 Nov 2000 09:59:31 -0700
In article <8uecj1$pri$[EMAIL PROTECTED]>, Alan Rouse
<[EMAIL PROTECTED]> wrote:
> If a sample is random, then by definition no information exists,
> whether known to you or not, which would reduce the size of a brute
> force search for the sample's value.
>
> There is a difference between a random sample and one that contains
> some entropy. Random is absolute. It means that there are no patterns
> and no biases.
Only the statistical definintion of random is absolute. The common usage
of the term before statistics perverted it never imposed such
restrictions.
------------------------------
From: [EMAIL PROTECTED]
Subject: new gchq challenge...
Date: Thu, 09 Nov 2000 16:57:57 GMT
Has anyone had a go at the new gchq challenge...
It has been updated since "well done now apply for a job!" and comes in
two parts. The first part, finding five words or phrases hidden with
Bacon's bilateral cipher is fairly easy, but i have not had much luck
applying the words to the second part.
See www.gchq.gov.uk for more details
Good luck!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Thu, 09 Nov 2000 16:56:13 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> >
> > You are not getting the source code. I thought of it
>
> Sorry? You thought of XOR? You invented the One Time Pad? Pure BS.
>
> > and engineered
> > it and I am not going to just give it to you all.
>
> That's all right. Since I have now released source code to a program
> that does not only what your program does but more too, anyone who
has a
> genuine need for this software in graphical form has an open source
> alternative to your program. If they don't like the (colossal) lack of
> error-checking in my code, they can add it themselves if they wish, or
> nag me to do it (which I may well do, even though it was meant to be
> joke code).
>
> And those who don't need it in graphical form can use either the other
> program I wrote to do the same thing, or Tom's program, or Andre's
> program. They don't *need* yours. There are at least four open source
> versions available now.
What does the OP mean by "give it all to us". a program that xors
bytes is not particularly ingenius...
hehe, again my program is available in source at
www.geocities.com/tomstdenis/files/xor.c
> > Yes, it's simple
>
> Ah, a correct statement. Well done. Make a note in your memoirs.
>
> > but as most of you should realize by now with all the posturing and
> > pretending in these news groups that all this cannot be too easy
> > because almost none of you are thinking of new ideas or innovations
>
> XOR is innovative?
>
> > or even producing the simplest of software and making it available
> > to the public.
>
> I'm pretty sure that all the finalists in the AES competition are
> patent-free - even the winner. This doesn't sound like a lack of
> available innovation.
The difference is the OP doesn't want to recognize anything but his
software.
> > Your lack of creativity and imagination has been
> > demonstrated by your deciding that your place in these news groups
> > is as pseudo consumer advocate. But you have merely become trivial
> > clowns.
>
> No. Some of the subscribers in sci.crypt (which is where I read your
> article) are world-class cryptographers and cryptanalysts, and you
make
> yourself out to be very foolish by insulting them. Every sensible
person
> is open to *intelligent* criticism, but you provide only the stupid
> kind.
I would consider myself an avid cryptographer and even I am wrong
often. It's part of the learning curve. You have to realize and
accept that you could be wrong to learn however.
I doubt that "world class cryptographers" post here. Perhaps the odd
snippet from David Wagner, Bob Silverman, P. Montgomery, etc... but not
a whole lot of the traffic is from the "pros". (Although their
contributions are often well received and appreciated)
> >
> > It probably runs on 85% of computers in the entire world.
>
> Well, 85% of desktop machines, maybe. We'll allow this as your second
> true statement (in the same article, too!), assuming you meant "can
run"
> rather than "runs" - I don't believe you have that level of market
> penetration yet.
My program runs on all platforms capable of file I/O :-)
> > It is not
> > my fault that there is more than one platform in use worldwide with
> > one dominant. Why haven't you provided a Linux or Mac or Etc.
> > version?
>
> I did one earlier this week which is available on the Web. It can run
on
> Linux, Windows, DOS, wherever. Even Macs, I believe (although you'd
have
> to track down a Mac user to actually test that statement). That's the
> nice thing about command line programs.
>
> > When it really comes down to it, don't you give a damn?
> > All we are hearing from most of you is give me, give me, me me
me ...
>
> Nobody sensible is going to use your stuff if they don't have the
source
> code.
"give me give me give me". Is the OP insane? I posted three times my
recent contributions... this guy is nuts.
And I disagree with you. Most people run PGP without checking the
source regardless of it's availability.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: 9 Nov 2000 17:30:36 +0100
In article <[EMAIL PROTECTED]>,
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Dido Sevilla <[EMAIL PROTECTED]> wrote:
>>>Tom St Denis wrote:
>>>>
>>>> Perhaps you missed the boat, OTP's are not practical solutions!
>>>>
>>>
>>> There are applications for which OTP's can be useful. The only reason
>>> why OTP's are not practical is the extremely onerous key distribution
>>> problem involved in their use. But some applications where, for
>>> instance, data gets protected statically, e.g. files on your hard disk
>>> with keys kept on removable media (kept in a secure location of course),
>>> and for applications where only short messages need to be infrequently
>>> transmitted, thus the key distribution operation is not so hard, e.g. by
>>> exchanging removable media physically for example.
>>
>> If you use a OTP, the key will be as large as the data you want to
>> protect. Now, if you want to protect data on your disk using OTP,
>> storing the keys on "removable media kept in a secure location", then
>> you might as well transfer your sensitive data to that removable media
>> instead and store it in a safe location: the encrypted data will be
>> inaccessible without the OTP key on the removable media anyway, and if
>> you lose that key, you might as well have lost your data. Right?
>>
>> The best use of a OTP is if you meet someone with whom you'll later need
>> to exchange sensitive data: then exchange a OTP key, to later be used
>> to encrypt that sensitive data.
>>
>> Using OTP to encrypt your local harddisk is quite useless.
>
> It depends upon the threat model. If the threat model is someone snooping
> the disk than OTP either reduces the utility of the system to ~0 or it leaves
> the system vulnerable to the threat.
>
> However, if the threat is one of _seizure_, then an OTP with the pad stored
> in volatile memory can be quite useful.
Not particularly, because when the OTP is gone from that volatile
memory, your data will be incomprehensible unless you've backed up
your OTP somewhere else. Then you might as well store the sensitive
data itself in volatile memory, with an optional backup of the
sensitive data if you also need to access it in the future. The OTP
gives you neither more security nor more convenience here.
Since an OTP key is as large as the data it's supposed to protect,
one might as well protect the data itself instead of the OTP key. As
far as I can see, the only time an OTP is of practical value is if
you have a secure communications channel channel now, but not in the
future when you need to communicate sensitive data. The typical
scenario is a spy before leaving for his spying mission.
--
================================================================
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
------------------------------
Date: Thu, 09 Nov 2000 17:35:00 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
<big snip>
[Mr Szopa wrote:]
> > > When it really comes down to it, don't you give a damn?
> > > All we are hearing from most of you is give me, give me, me me
> me ...
> >
[I replied:]
> > Nobody sensible is going to use your stuff if they don't have the
> source
> > code.
[Tom replied to me:]
>
> "give me give me give me". Is the OP insane?
No comment.
> I posted three times my
> recent contributions... this guy is nuts.
No comment. :-)
>
> And I disagree with you. Most people run PGP without checking the
> source regardless of it's availability.
Read again, very carefully, what I actually wrote. Are you claiming Mr
Szopa wrote PGP?
;-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: d <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Thu, 09 Nov 2000 18:08:49 +0000
Tom St Denis wrote:
>
> Perhaps you missed the boat, OTP's are not practical solutions!
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
but they are easiest to implement :-)
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
