Cryptography-Digest Digest #241, Volume #11 Thu, 2 Mar 00 20:13:00 EST
Contents:
Re: - US "allows" encryption program online ("John E. Kuslich")
Re: IDEA question. ("Brian Sipos")
Re: Can someone break this cipher? (Mark VandeWettering)
Re: Best language for encryption?? (Paul Schlyter)
Re: Microcontroller Cipher (David Hopwood)
Re: Ciphering = deciphering; is this a weakness? (David Hopwood)
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: Passphrase Quality ? (jungle)
Re: https (Paul Rubin)
Re: Status of alleged *THIRD* key in MS Crypto API ? (David A Molnar)
----------------------------------------------------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: Thu, 2 Mar 2000 16:14:26 -0700
Rights are not GIVEN to us by the Constitution.
Rights accrue to us by virtue of our being human.
Rights are GUARANTEED by the constitution. That, in fact, is the only
legitimate function of government.
And that guarantee is only as good as the man who holds the office of
President.
How does THAT make you feel??
JK
<[EMAIL PROTECTED]> wrote in message
news:897hjb$ot2$[EMAIL PROTECTED]...
> this is off topic but, just had to respond to John:
> Your right. Most people in america don't even know their rights given
> to them by the Constitution. I believe the government has figured out
> that they can't take big chunks of our rights away at one time. They
> figured out they have to do it one tiny piece at a time, through tiny
> lines of lesgislation from a bill that gets past without people knowing
> whats going on. It all adds up in time, then in the near future people
> will suddenly realize they don't live in a "free" society at all, and
> that all their rights have been legislated away, that is ,unless
> everyone does something about it now.
>
> joeb
>
> "John Galt" <[EMAIL PROTECTED]> wrote:
> > "Professor allowed to post encryption program online"
> >
> > I have been watching the responses to this post. It is incredibly sad
> that
> > so many people consider themselves as "subjects" instead
> of "citizens", in
> > that they do not appear to be the least bit angry that any government
> would
> > be so paternal and condescending as to "allow" them to post an
> encryption
> > program.
> <snip>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Brian Sipos" <[EMAIL PROTECTED]>
Subject: Re: IDEA question.
Date: Thu, 2 Mar 2000 18:04:45 -0500
You could use a hash of the unencrypted file as the known block, so that it wouldn't
be a static number.
Chris DiTrani <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I wrote a little utility to en/decrypt files using IDEA, building the
> encryption key from a user provided pass phrase. In order to confirm
> that a file is being decrypted with the correct pass phrase, I encrypt
> a block containing known (but not secret) data and append it to the
> file before encrypting the file (so this block is encrypted twice). I
> can look at the block after decrypting the file to confirm (to some
> certainty). My question is, am I appreciably weakening the encryption
> with this approach? Is there a better way?
>
> Thanks,
>
> CD
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Thu, 02 Mar 2000 15:03:41 -0800
Mary - Jayne wrote:
> As you reproduced them in the previous paragraph, I would suggest you have
> answered your own question. Now just how specific did you want me to be?
> Shall I send you the plaintext and a copy of the program source code?
> Perhaps you would like the keys as well?
A copy of the program source code would be in order. It seems rather unfair
for you to ask people to analyze your algorithm without the source code to
find weaknesses that you can't with the source code.
If you think that you can keep the algorithm of any program secret, I suggest
you review the state of decompilation technology, and perhaps review the status
of the RC4 "trade secret".
> Almost forgot! Can I get you a coffee or something?
Skip the coffee, how 'bout taking the time to read section 2.3 of the sci.crypt
FAQ? A brief snippet:
If you have come up with an encryption scheme, providing some
ciphertext from it is not adequate. Nobody has ever been impressed by
random gibberish. Any new algorithm should be secure even if the
opponent knows the full algorithm (including how any message key is
distributed) and only the private key is kept secret. There are some
systematic and unsystematic ways to take reasonably long ciphertexts
and decrypt them even without prior knowledge of the algorithm, but
this is a time-consuming and possibly fruitless exercise which most
sci.crypt readers won't bother with.
Need we be any more explicit?
Mark
> http://www.xarabungha.btinternet.co.uk/
>
> http://website.lineone.net/~auntie_min/
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 2 Mar 2000 20:29:47 +0100
In article <89m4k9$aik$[EMAIL PROTECTED]>,
Brian Hetrick <[EMAIL PROTECTED]> wrote:
> The currently most popular language in the world, by count of number of
> installations, is Visual Basic for Applications. (VBA is included with
> every Microsoft Office product and with such things as Visio.)
This measure is quite misleadning for two reasons: 1. Most people don't
choose this -- it's being more or less forced upon them, because it's
preinstalled on their computers, and 2. only a minority of those who
have this does actually use it. Do you really think something is
"popular" if it's rarely used?
> While there are minor performance drawbacks to Visual Basic (as the code
> generator is optimized for C++ rather than Basic),
In many cases these performance drawbacks are more than minor. Remember that
Basic was never designed for efficient execution....
> the real drawback to using Visual Basic for everything is that one's
> market becomes "limited" -- to a mere 95% of the boxes and 90% of the
> CPU cycles in the world....
Reminds me of the argument "50 trillion flies can't be wrong - eat shit!" :-)
But it may make sense to those who are after quantity rather than quality....
However you're wrong about the box and cycle count here. The
majority, both in the number of boxes and the CPU cycles, aren't to
be found among PC's but among all the embedded systems out there!
Each PC have, in addition to its x86 CPU, several such embedded
systems: one in the keyboard, another one in each HD, CD reader,
modem, etc. The CRT probably has some too. And they're found
virtually everywhere else as well: in washing machines,
refrigerators, stoves, clocks, locks, cellular phones, ... et cetera,
et cetera. THERE you'll find most boxes and most CPU cycles. And VB
is utterly incapable of producing code which runs on such devices!
But even if we ignore all those many embedded systems, your figures
"95% of the boxes and 90% of the CPU cycles in the world" is still
wrong: the Macintosh ha a market share of some 10-15%. In addition,
an increasing number of PC's are running Linux rather than Windoze.
Can VB produce executables which runs on either the Mac or on Linux?
Finally, outside the field of personal computers you'll find some of
the most interesting of all computers. And your VB application is
guaranteed to never run on one of those....
> Arguing about which language is "best" is like arguing about which color is
> "best."
Colors doesn't perform anything -- programming languages do.
> Can we get back to what sci.crypt is supposed to be about, now?
To you it must be encryption exclusively on PC's -- in VB... :-)))))
--
================================================================
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, 02 Mar 2000 05:00:58 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Microcontroller Cipher
=====BEGIN PGP SIGNED MESSAGE=====
Gary wrote:
> Microcontroller Cipher.
>
> I'm using an 8 bit microcontroller and am implementing the following simple
> variation of a Feistel cipher.
> Let the 128 bit key K have bits k0,k1,k2,....,k127.
> I have a block of memory 16 bytes long. I split this into 2 halves, 8 bytes
> each.
>
> To Encrypt:
> If k0 is set I XOR the second half to the first, otherwise if k0 is clear I
> ADD the second to the first.
> If k1 is set I XOR the first half to the second, otherwise if k1 is clear I
> ADD the first to the second.
> and so on... for 64 rounds.
> Note:Adds are carried across the whole of the 8 bytes (64 bit ADD).
This doesn't sound very promising; in fact I seem to remember something
quite similar being proposed and broken here before. The main problem is that
XOR is very similar to ADD, since it only differs in the treatment of carry.
Just off the top of my head (and with a lot of handwaving), I think that
given a small amount of known plaintext, you can solve for the lowest order
bit (for which XOR and ADD are identical), and then progressively work up
through the higher bits, using information obtained from the lower bits.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOL31XDkCAxeYt5gVAQFkQwgAzWT2Iy5Ot7un1S5ibEen6Zxfe8Fx1IXk
WfCHa+EMBThFuaLcmWMxcoffRQOiBVI98XwE06d2RRsJipJDKkvW0/fLhkJXXO+A
nau2R5kX8ZNMtr6ghaVoffF3S6gxaDijT4xDvc13BzywvmQwZgA/oVaZDEt2pL73
0De3K9cEtNuZHEIy/TAbHlo/k1YelbYlPuN35d5e3/bypX/kKn+uuKpr/GgQeLIk
/g5PkEjvQuGddJMYRC61vHRBlf0QloH4L9vjwmRWKSrVDPcKlqCZK3KxXgYZIRCk
Wnt3AYe6riGcmSZUtn1YGYiOrXYW6Hr78jbNjjIdrACxmKd8hZGULw==
=8q6b
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 02 Mar 2000 04:14:35 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Ciphering = deciphering; is this a weakness?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> In a previous article, "Manuel Pancorbo" <[EMAIL PROTECTED]> writes:
> >I think there is a small weakness under a known plaintext attack; if the
> >attacker needs (2**M) plaintexts to break the cipher, the involution
> >property makes twice easy the work: (2**M)/2 =3D (2**(M-1)); if M is,
> >let's say, 50, then the new exponent drives to 49: not so much help!
> >
> >I love too much elegance; so if this is the only weakness I will design
> >the cipher with involution property.
It is not the only weakness. Normally, modern ciphers are designed to
be secure against chosen plaintext attacks. A chosen plaintext attack
against a block cipher that is an involution (when used in ECB and CBC
modes) obviously allows any given ciphertext encrypted with the same key
to be decrypted.
> BTW. Any cipher run in OFB mode posses the property of having the same
> encoding function as decoding function.
A cipher in OFB mode is only used as a keystream generator, with the
keystream used exactly once, and therefore chosen plaintext attacks aren't
applicable. I.e. it's not valid to infer that the involution property is
safe for a block cipher in ECB or CBC mode, just because OFB has this
property.
(It's also not worth designing a block cipher that is only safe when used
in OFB or CFB modes; you might as well design a dedicated stream cipher
instead, since that can probably be made faster.)
Note that the AES candidate MAGENTA had an involution-like property
(with an extra swap of halves of a block), and that property would
certainly have been sufficient to disqualify it from consideration in
the second round of AES, even if it had not had other severe security
and performance problems.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOL3qnDkCAxeYt5gVAQEW2Qf/XGv7+2JroePnthkO94UZSJgv7CXVTE9G
Dlnuj6Bk2+DaVF/EsH6CfD2e/bBUYBO/VqqVDTX2v9UB8Ke0IZMUF1j0ORvoapvR
FUGOTlb/RUeKT7bD3uu3iEHt6C1B0XXlwKhegc9RO+WvbYbEcqfjGR8U/fKhLtc1
+nb5LeN5SH16wg84A352YhhZEYmNw3WXQJmg9uNkniQuXLl1GEkNkYBgEB3uXjgu
imt23ejwDnID5cBRamUYIwzau9dPzdv/69F7QSbfmzcBJSvfTFo8cJpWwTHgPByh
gWcTTbQbKmSmB2vRQHXaeTlqy5vqZVFLkWbB/7XDy5XPxS0xn4ux+Q==
=03tI
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 2 Mar 2000 23:58:01 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <89mpu1$6i4$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>How much RAM do you have available?
>
>Can you say more about your application? I.e. what kind of data do you
>want to decrypt, and how often? Would there be a fixed key or do you
>have to be able to load ones? Does the key count as part of the 50 bytes?
Each device has the cpu, 512 bytes of ram, and 1MB of eeprom. A fixed
key in flash eeprom (set during the manufacturing process, unique for
each device) is used to decode a small packet containing the key that
will be used to decode content. Content (roughly 1MB) is decrypted using
that content key. Multiple devices (owned by the same person) will share
the same content key.
Since the key(s) are stored in eeprom, it does not count against the
50 byte code space restriction. All the instructions on this processor
are either 16 or 32 bits long, so we have 25 instructions to work with.
Code space restrictions drove us to a single block algorithm, although
a stream algorithm would probably be faster for the bulk data.
>The Atmels are pretty fast compared to typical cheap 8-bit parts, IIRC.
>You might be able to get away with something pretty inefficient if you
>only have to decrypt something once in a while.
We only decrypt the content during the loading process. It is stored
in clear text in the eeprom. If anyone wants to open the devices and
attach probes, they can obtain the clear text.
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOL7//tZjPoeWO7BhAQG5/gQAnHWZdS/Uc2DLr+khA5103zZ75hrWsMKa
2PsOgSGReHLlRVHStvRoHNvGHRLmgBMDKLDFrLsH1t47adAjr9t6cenGMmgXOUBb
uJS+gGRkoBySQY8WKD1V4bPlD53WFpj64nyXRJlbRh0q06bjmmv/TS54Ie22XZKp
6amxd1+ntb4=
=Kauv
=====END PGP SIGNATURE=====
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Fri, 03 Mar 2000 00:33:30 GMT
there is no recommendation / reference to ROT-13,
I used it as the EXAMPLE ONLY to encode text from dictionary ... & as the
encoding example it is as valid as any other method available or will be
available
I'm using very often ROT-35 on 70 common characters from keyboard, but again
this will not help you much to find how my encoding works
the next point is, do you really believing me that I'm using ROT-35 and not
ROT-36 instead, on 80 char set ?
because we have such "tools" as crack or pass crack or recreate pass or whoever
some "experts" will call them for performing DICTIONARY ATTACKS the "Dictionary
Attacks" as the term will be valid
for pure cryptography terms, the "Dictionary Attacks" are / obsolete / bulshit
/ non existent distinctions, only bit space is relevant
in practical world of cracking "Dictionary Attacks" will be used as the
preliminary tools, or as the primary tools for the majority of required cracks
...
let's take the majority of users, where he will think that his pass consisting
of given name of his wife is secure, will be cracked by Dictionary Attacks
today & tomorrow, but encryption expert who has pass text consisting of 10
words from pass text database will not be cracked by Dictionary Attacks tools
I addressed many levels of sophistication, for pure expert penetration, only
bits key space calculation is valid, therefore pass text consisting of 16
random characters is equivalent to symmetric encryption 128 bit kay space,
equally relevant would be 20 char from 70 common on the keyboard =
70P20 = 4 x 10^35
Johnny Bravo wrote:
>
> On Thu, 02 Mar 2000 01:07:21 GMT, jungle <[EMAIL PROTECTED]> wrote:
>
> >For "pure" dict attack this [Vs lbh nyernql unir na rneyvre irefvba] is
> >unbreakable, none of the words are present in standard dict list.
> >
> >For improved "pure" dict attack, the situation is not clear, because we need to
> >draw line between "brut force" & "dict attack".
>
> The problem is that the line will be drawn differently for every
> attacker. You have no way of knowing if the attacker will try ROT-13 or
> not,
there is no recommendation / reference to ROT-13,
I used it as the example only to encode text ...
there are literary hundreds of thousands of encoding methods that can be used
to do this ...
use your imagination please & all the options are open to you ...
> it might be the second thing they try after the dictionary attack
> fails. Constructing a secure password based on a "secret" method is not a
> benefit to security, you always have to assume that your method has been
> discovered.
can be discovered, yes, but it's practically impossible ...
all the time you are using "your method", because you did make your selection
decision ...
> >Where dict attack will blur into brut force.
> >Brut force in symmetric encryption is very easy to define, but for language
> >pass it is not.
>
> Done with randomly chosen words from a list of N words, each word will
> offer log2(N) bits of password which is exactly comparable to a symmetric
> password.
thanks, I do know calculations very well ...
there is a small problem in your thinking ...
it's very likely that you will not remember [ from your 128 bit equivalent key
space ] 10 words randomly chosen, for some very stupid or valid reason & as the
result you will never be able to recreate your pass text ...
you will end up in your own protection trap ...
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: https
Date: 3 Mar 2000 00:43:34 GMT
In article <[EMAIL PROTECTED]>,
Michael Sierchio <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>
>> I've never heard of anyone issuing free certificates that are recognized
>> by most browsers. The usual supplier of low-cost certificates is Thawte
>> (www.thawte.com), which is now part of Verisign but will continue to
>> issue certificates for 125 USD til the end of this year. Some certificate
>> vendors offer "free trial certificates", but those are only recognized
>> by browsers that you specially set up to accept them. That's really
>> no better than issuing your own certificates.
>
>Presumably all it takes to get your CA cert embedded in a Netscape
>release is some assurance that you're operating the CA properly and
>paying Netscape $150,000 (last quoted price).
That doesn't get your CA root into older browsers. If you're running
a web store, you want your certs to work in as many browsers as possible.
That's partly why people were willing to pay 2x as much for Verisign
certificates as Thawte certificates--Verisign certs worked in browsers
like Netscape 2.x until the end of last year. At the beginning of this
year the old Verisign roots expired and Thawte certs became as good
as Verisign certs. That might be part of what made Verisign decide
to acquire Thawte.
>Maybe the EFF would like to fund a non-profit CA?
I don't see why they'd want to do that, but anything's possible.
>One of the problems is that a sizeable portion of fees will
>need to go towards insurance against what one litigation expert
>has called (somewhat gleefully) "huge pools of liability" in PKI.
I like that ;-).
>A small CA might also need to contract with an online verification
>service provider, such as Valicert -- managing revocation is hard,
>issuing certs is easy.
Almost nobody sets up their browser to check for certificate
revocation, even for browsers capable of revocation checking (MSIE
5.x). Who needs the slowdown? Even if your cert gets in a CRL, most
browsers will never notice. That slightly justifies CA policies of
expiring customers' certificates every year, though I suspect the real
reason has more to do with collecting more fees.
>So, I can imagine a CA in which individual S/MIME certs cost $5,
>and server certs cost $100. My current employment bars me from
>engaging in this business, but expect to see me when I cash out ;-)
Server certs from www.thawte.com are still $125 and they say they
won't raise prices this year. You can be a Thawte reseller ("Chained
CA") and issue site certs for a lot less than that. (I don't know
if that scheme is still available under the new regime).
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Status of alleged *THIRD* key in MS Crypto API ?
Date: 3 Mar 2000 00:57:20 GMT
Hammer <[EMAIL PROTECTED]> wrote:
> brightest minds spending cycles on such things. Can I say that while
> still being full of genuine respect for the participants in sci.crypt?
> I hope so.
Yup. Technical competence doesn't automatically confer good judgement
in the sense you're writing about.
------------------------------
** 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
******************************
