Cryptography-Digest Digest #908, Volume #9 Mon, 19 Jul 99 01:13:03 EDT
Contents:
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: Xor Redundancies (JPeschel)
Decimal numbers in hex string ("John Dickinson")
Re: Open questions about Dave Scotts Method (JPeschel)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: Algorithm or Protocol? (wtshaw)
Storing RSA public/private keys ([EMAIL PROTECTED])
Re: Compression and security (was: Re: How to crack monoalphabetic ciphers) (wtshaw)
Re: obliterating written passwords ("Douglas A. Gwyn")
Re: Xor Redundancies ("Douglas A. Gwyn")
another news article on Kryptos ("Douglas A. Gwyn")
Re: randomness of powerball, was something about one time pads ("Douglas A. Gwyn")
A Good Key Schedule
Good Autokey and Bad Autokey
The Yamuna Cipher (wtshaw)
Re: Open questions about Dave Scotts Method (SCOTT19U.ZIP_GUY)
Re: Xor Redundancies (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Sun, 18 Jul 1999 20:30:35 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (Patrick Juola) wrote:
>
> > Because the public key can only be used for encryption, not for
> > decryption; if you have a copy of the cyphertext and the key that
> > was used to *en*crypt it, you have no efficient way of obtaining
> > the plaintext. The key that is used to decrypt is a different key,
> > related to but unreconstructable-from the encryption/private key.
>
> Wrong wrong wrong.
>
> The public key can be used for decryption. What do you think RSA
> verifying is?
Tom, you could learn from Patrick Juola's post. Try to.
RSA verify uses the same one-way trap-door function as
encrypt, but it is not the same operation. The public
is used to encrypt and verify, the private key to sign
and decrypt.
> And the private key is reconstructable from the public
> key it's just really hard todo.
You need to read more carefully. He wrote "no
efficient way of obtaining the plaintext".
> You have to distinguish between hard-to-do and impossible-to-do.
Which he did.
[...]
> This never ending blind faith is what puts many snake oil products out
> there...
I'm not aware of Patrick ever producing or promoting
snake-oil. Tom, on the other hand, seems to be trying
to drown us in it.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Xor Redundancies
Date: 18 Jul 1999 21:36:56 GMT
>[EMAIL PROTECTED] writes:
>Then he should have said that. Xor-Ciphers means nothing. You could
>also say Add-Cipher Sub-Cipher Mul-Cipher etc ...
>
>BTW those repeated key ciphers are normally done by twits who haven't a
>clue about computer security. But it keeps normal drones out of
>private files... maybe it does its job?
Some companies call the "cipher" by a different name, some use the XOR
operation on the password only. In the second instance, Turbo Encrypto
uses an XOR operation beginning with 0x20 through the length of the stored
password depending on the type of "encryption" used. Other companies
take classical ciphers, for instance, Aristocrats and tout them as unbreakable
under a different name, of course.
The trouble is these companies claim, falsely, real security. Unfortunately,
they also charge real money.
It gets worse, though. MaeDae Enterprises, for example, uses DES and
Blowfish in its product Encrypt-It. It also uses a proprietary encryption
technique in the unregistered version. The company says, "Our proprietary
encryption algorithm uses the standard xor, transposition, and substitution
forms
of encryption." Later they say, "The proprietary level of encryption built
into Encrypt-It is very safe for normal data because it uses multiple different
encryption layers."
Now, strong ciphers use XOR, transposition, and substitution, but in a
differerent way than Encrypt-IT, which is easily cracked. (Encrypt-It,
incidentally is certified by by ICSA. Gutmann calls the unregistered
and international versions ICSA-certified snake oil.)
Still, companies use such terms as XOR, substitution, and transposition
as buzzwords to imply security. The upshot is that individuals and
companies believe they are using a secure product. True, some individuasl
may expect only a veneer of security, but a small to medium-sized
business may expect real security as promised. A company
expecting that level of security could stand to lose thousands or
million of dollars of proprietary information using any one of a plethora
of snakeoil products.
A while ago, Bruce named a few snake-oil vendors in his "Crypto-Gram
Newsletter," Feb., 1999. Still, there is little work publicly available on
exposing snake-oil. AccessData does some work, Pavel Semjanov
exposes some, I do what I can. There are plenty of folks in this newsgroup
who could do the same, maybe as an infrequent hobby. I wish they
they would.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "John Dickinson" <[EMAIL PROTECTED]>
Subject: Decimal numbers in hex string
Date: Sun, 18 Jul 1999 22:57:07 +0100
The decimal numbers on the left are encrypted? into the following hex string
using the same algorithm for each one. Any suggestions (sensible) about
where I start. I tried putting the lot into one long binary string and
looking for a match, reversed it and inverted it but I have not done any
exor signature feedback or anything like that.
I realise that it will probably require that type of approach but need help
starting off (there's optimism).
206, F8 D2 B2 AC 1C 75 71 16 AF 22 6E 38 EE A3 1E C5
196, 0E D0 36 05 18 29 FA 16 AF 13 67 3C 6C 43 24 CF
163, FC D5 32 1D 1D 51 5B 16 AF 5B 6F 38 69 73 2A CD
139, C5 D8 98 2A 1A 0C 92 17 AE AC 68 32 C4 23 3D CB
100, 4E C2 AE C1 1C 5C 38 11 AE EF 63 24 FE 83 4D C5
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Open questions about Dave Scotts Method
Date: 18 Jul 1999 23:36:01 GMT
>[EMAIL PROTECTED] writes, in part:
>Here are some questions about Dave Scotts method that he has been
>avoiding:
I doubt that David is going to answer your questions, especially since
he has a $1,000 riding on scott16u. (On the other hand, since I just
said what I did, he may answer your questions. :-) )
If you believe you are on the trail of a potential attack, go for it,
and good luck! There may be in a grand in it for you.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sun, 18 Jul 1999 17:42:43 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
> <[EMAIL PROTECTED]> wrote:
>
> > wtshaw wrote:
> > > Come, to think of it, base one is noncomputational as well.
> >
> > No, base one is the common "tally mark" notation, which does work.
>
> Considering that calculations according to normal rules include exactly
> the same number of symbots as the base, including zero, that rule would
> have to be broken with base one, which I would maintain contains two
> elements within the rules, zero and infinity, infinity and zero being
> expressed as one since anything to base 1, including infinity, is one.
> Tally marks would not be a computational base that would fit with all the
> other rules for all the other bases, which makes it an orphan, an
> exception to everything else.
OOps, twisted and wrong mathematics on the scene, realized it when I hit
send and did no have time to correct it then.
"being expressed as one since anything to base 1, including infinity, is one"
wrong, wrong, wrong, as we know, anything to base zero is one....sorry.
Still, base one cannot use the figure one, only zero as a normal
character, which is of course the absense of a value.
>
> About considering the usefulness of tally marks for encryption, they would
> merely be a means of representing a count for symbols in another hidden
> set. Since zeros would be excluded from strings of ones, you do not have
> conventional numbers, only groups, of ones, or a solitary zero perhaps.
> If you use ones and zeros in the same number, you are encroaching on every
> other base, beginning with base two.
>
> I bet you can hardly wait to have ciphertext posted in the forms of tally
> marks, which could not be grouped in less than the total number of the
> string unless you separated them with a solitary zero. Something like:
> 1111 0 111 0 1111111 0 111111 0, which could also be used in
> stegnography were zeros were represented by a list of certain words or
> characters, and everything else was used as ones. You would have to have
> another set to reference to get the meanings of the counts. The
> decryption program would, of course, be the tallywacker.
> --
> Encryption means speaking in turns.
--
Encryption means speaking in turns.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Algorithm or Protocol?
Date: Sun, 18 Jul 1999 17:57:41 -0600
In article <7mtbp3$6as$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I think pioneers in the group should move to designing secure systems
> > (with respect to where the trust is placed). I will bet that anyone
> > could sell a system more then an algorithm and that we could use
> > protocols more then algorithms...
>
> Sure! What problems need protocols? what's your favorite protocol?
> Want to start with intrusion detection, logging in, digital cash,
> pseudonymous transactions, or?
>
I see a protocol as something that an user does, requiring a series of
actions to follow through. A particular algorithm may require either a
certain protocol and/or have options of actions that might be more or less
desirable. When a protocol becomes too difficult to follow, remember, do
when tired, it is probably a bad protocol. Complicated protocols
regarding keys are bad protocols.
However, a protocol put in streamlined form may be or become part of an
algorithm in actuality. There is a kinda muddy boundary between
algorithms and protocols, as an algorithm can be really simple to do, even
in your head, and a protocol can be too complicated to rely on except if
automated.
When I write a program in which the user has to check block count in the
last block, surely this is a protocol step. If I had the program do it
somehow automatically, it might be more algorithmic. Unfortunately, try
as we must, good judgement remains a prefered protocol, including choice
of appropriate algorithms. The danger is excluding much choice is that
you can default to a poor protocol in operating an otherwise good
algorithm, like farming out key management to agents X.
--
Encryption means speaking in turns.
------------------------------
From: [EMAIL PROTECTED]
Subject: Storing RSA public/private keys
Date: Sun, 18 Jul 1999 19:51:13 -0400
In a program I have created, I use RSA and Blowfish for
encryption/decryption. When I store the private key on disk, this is
how it is stored:
The password to decrypt the private file is hashed with SHA. The hash
and the private key is then GZiped together. The GZiped output is then
encrypted with Blowfish using the users password. That output is saved
to disk.
To retrieve the private key, the user enters the password, the file is
decrypted, and the hash is compared with the user's password hash. The
only flaw I find is that if the decryption with an invalid password
creates an output that the hash would equal the user's invalid password
hash. This doesn't matter, because they will not have the private key.
I am not worried at this point in development whether or not windows
swaps the program to disk in the middle of this process, if the key is
left in memory, etc. What I am wondering is this a secure way of
storing a private key?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
Date: Sun, 18 Jul 1999 18:12:01 -0600
In article <7mt7nh$2jak$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>
> Ideally one would like to compress Ascii mesages to
> a file that appears completely random.
> One also would like the decompression
> routine to take any random file and expand it to a readable ascii file. Well
> this is not going to happen ( but if it does I want a copy of the routine)
Surely this is possible. When you say readable, it matters what you mean,
actual intelligent text, or just characters in a desired set. Even the
former is possible, but not practical, but the last is highly practical,
just name the set, say 256, and pick a ball park of end set options, some
being probably better than others when you face the mathematics.
I am not talking of Huffman type compression, but just the base
translation mechanisms I like to work with.
> The reason this would be nice is that the entropy of the encrypted compressed
> message would be a maximun and that if one guesses a key used for the
> encryption the resulting decompressed file would be a valid looking file
> and the attacker would not have a way to know if it was the correct
> key or message.
Of course, any change of base, a possible use of keys grafted into the
process optionally included, will produce characters that are not apt to
be attackable without considering the complications that were added.
--
Encryption means speaking in turns.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: obliterating written passwords
Date: Mon, 19 Jul 1999 03:54:37 GMT
wtshaw wrote:
> In the field, this may not be possible.
In the field, we had barrels of thermite ready to go.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Xor Redundancies
Date: Mon, 19 Jul 1999 04:02:39 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Yes many people feel that this is unbreakable due to the fact the
> masses are kept ignorant about encryption.
The masses keep themselves ignorant. This simple periodic
polyalphabetic system is quite close to the historic ciphers
explained quite clearly in Kahn's best-seller "The Codebreakers",
which any good public library should have.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: another news article on Kryptos
Date: Mon, 19 Jul 1999 03:45:37 GMT
http://www.washingtonpost.com/wp-srv/national/daily/july99/kryptos19.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Mon, 19 Jul 1999 03:58:57 GMT
No, the obvious fix is that you lose your dollar only if your number
doesn't show on any of the dice.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: A Good Key Schedule
Date: 19 Jul 99 04:35:46 GMT
Let's say I'm trying to design a conventional encryption program. It
accepts a text message as input, and allows files to be attached.
The user types a phrase in as a key.
That key controls several different encipherment steps. First I compress
the message in binary. (Binary, with its small-sized bits, is very well
suited to data compression. Arithmetic coding is unneccessarily
complicated for a very small additional gain, and may be covered by
patents.) Then I perform a pencil-and-paper style transposition, then use
a block cipher like DES, do some other steps, convert the message from
binary to base-26, perform some more encipherment, and finally convert the
message to 78-character armor for transmission.
In converting the message from binary to base-26, I'm introducing a slight
(very slight) additional redundancy.
I could avoid problems by using two different keyphrases as the source of
the keys for the encryption steps before and after the conversion.
However, that merely avoids one risk. Ideally, one would like the key for
every encryption step to be completely independent from the keys for all
the others.
Yet this shouldn't depend on the skill of the user, who should just have
to type in a single keyphrase.
What kind of technique should be used?
It strikes me that one should first generate an initial keystream that has
a long period, such that any short piece of the keystream depends on the
entire key. Even a simple method, such as an insecure PRNG seeded by a
hash of the key, and XORed with the keyphrase repeated, might suffice.
Something a little better, though, such as Panama, is really recommended.
Then after taking enough key from the stream to set up one encipherment
step, what should be done is to subject that piece of the key to a one-way
hash function. In this way, breaking one step in the encryption always
yields a key that provides no exploitable clue to the keys used for the
other steps.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Good Autokey and Bad Autokey
Date: 19 Jul 99 04:24:57 GMT
A thread on what the relationship between stream ciphers and PRNGs is
elicited a mention of a class of stream ciphers that does not involve a
PRNG: self-synchronizing stream ciphers. These are ciphers that work
basically like the Cipher Feed-Back mode of a block cipher: the operation
done on a unit of plaintext to encipher it depends on a function of a
certain amount of preceding ciphertext.
This avoids the need to send timing or counter information along with the
ciphertext, and yet allows decryption to resume after a short hiatus if
there is an interruption in the transmission.
In general, autokey ciphers are currently out of fashion. It is
specifically because they _can_ have very bad error-propagation
characteristics that this is so.
>From a security standpoint it is desirable for a stream cipher to have a
very large internal state, only a part of which is used at a time. But in
that case, the cipher can't be of an autokey type without a loss of
synchronization affecting the decipherment of all future blocks. Note that
this is a problem with Terry Ritter's Dynamic Substitution, but it is
avoided by RC4 which uses the same principle, but only _inside_ a PRNG.
Of course, two other things can be noted:
If we do send counter information along with ciphertext, a complex PRNG
with a large internal state is not a problem; and an autokey component of
the self-synchronizing type, without an internal state, can be used at the
same time too, as long as the two are reasonably independent.
And for enciphering things like E-mail messages, error propagation need
not be a consideration; if errors are likely, using error-correcting codes
may be sufficient.
John Savard
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: The Yamuna Cipher
Date: Sun, 18 Jul 1999 23:07:42 -0600
Yamuna plaintext is in base 27, and ciphertext is in base 81. The
conversion is seamless in that both character sets can be represented in
trits, three per character in base 27 and 4 per character in base 81.
Yamuna can operate in three sizes 12, 24, or 36 trits, which are the
number of trits that are transposed. I could have used substitution keys
in both bases 27 and 81, but did so only in base 27. The default keys for
Yamuna 36 are as follows:
Subs(Ya): abcdefghijklmnopqrstuvwxyz/
Trans(Ya): abcdefghijklmnopqrstuvwxyz0123456789
As before, keys may be generated from text, or entered directly,
acceptable strings being a minimum of 12 characters to a maximum of 66
when both keys are to be generated. The user has the option of using a
keylength of his choosing, the longer being the stronger, text or random
characters however ordered.
These few words result in these keys in Yamuna 24:
Subs(Ya): vibrchdz/opasqetymwknxjfugl
Trans(Ya): cuoikvajrlbwxqhdpegfstmn
Plaintext groups are 4, 8, or 12 characters, ciphertext, 3, 6, or 9.
Once I had worked on the 27 character front end for Santa Maria, it seemed
like it would be easy to do this simple conversion, no complex
calculations involved; it proved reasonable at least. I have used a
similiar conversion, but without the keys, in other programs.
Here is a sample of ciphertext, these words in a key based on the previous
paragraph:
n3~au x91a8 ITS/- qqonC ipUKS AE+03 7ubX7 du*U1 1-+pc ~,l!8 cEJCv ztiJ7 qqh
Notice that some compression occurs. Even with formating, the ciphertext
is slightly shorter than the plaintext. Since the character sets are
different, the amount of information is actually the same in both.
Ciphertext is in historic groups of five characters, but has nothing to do
with the true ciphertext blocks, three characters in this case.
--
When I talk about running the bases, it't not baseball.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Open questions about Dave Scotts Method
Date: Mon, 19 Jul 1999 05:47:33 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>>[EMAIL PROTECTED] writes, in part:
>
>>Here are some questions about Dave Scotts method that he has been
>>avoiding:
>
>I doubt that David is going to answer your questions, especially since
>he has a $1,000 riding on scott16u. (On the other hand, since I just
>said what I did, he may answer your questions. :-) )
>
>If you believe you are on the trail of a potential attack, go for it,
>and good luck! There may be in a grand in it for you.
>
>Joe
Joe I am not sure you have noticed but little Tommy likes to use big
words but never anwsers any questions himself. I long ago give up on
the kid he is hopeless. He does not have the patience or the brains to solve
the scott16u puzzle. We once had a very long exchange where he seemed
incapable of learning anything and said he was done talking to me. I don't
mind anwsering questions for those that truely want to learn but our little
boy Tommy does not want to learn.
Maybe the NSA could give the solution to him so he could collect the
money. No I don't think they could have solvied it. But they may have planted
some trojan program in my PC to find out what I have done.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Xor Redundancies
Date: Mon, 19 Jul 1999 05:55:41 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>>[EMAIL PROTECTED] writes:
>
>>Then he should have said that. Xor-Ciphers means nothing. You could
>>also say Add-Cipher Sub-Cipher Mul-Cipher etc ...
>>
>>BTW those repeated key ciphers are normally done by twits who haven't a
>>clue about computer security. But it keeps normal drones out of
>>private files... maybe it does its job?
>
>Some companies call the "cipher" by a different name, some use the XOR
>operation on the password only. In the second instance, Turbo Encrypto
>uses an XOR operation beginning with 0x20 through the length of the stored
>password depending on the type of "encryption" used. Other companies
>take classical ciphers, for instance, Aristocrats and tout them as unbreakable
>under a different name, of course.
>
>The trouble is these companies claim, falsely, real security. Unfortunately,
>they also charge real money.
>
>It gets worse, though. MaeDae Enterprises, for example, uses DES and
>Blowfish in its product Encrypt-It. It also uses a proprietary encryption
>technique in the unregistered version. The company says, "Our proprietary
>encryption algorithm uses the standard xor, transposition, and substitution
>forms
>of encryption." Later they say, "The proprietary level of encryption built
>into Encrypt-It is very safe for normal data because it uses multiple different
>
>encryption layers."
>
>Now, strong ciphers use XOR, transposition, and substitution, but in a
>differerent way than Encrypt-IT, which is easily cracked. (Encrypt-It,
>incidentally is certified by by ICSA. Gutmann calls the unregistered
>and international versions ICSA-certified snake oil.)
>
>Still, companies use such terms as XOR, substitution, and transposition
>as buzzwords to imply security. The upshot is that individuals and
>companies believe they are using a secure product. True, some individuasl
>may expect only a veneer of security, but a small to medium-sized
>business may expect real security as promised. A company
>expecting that level of security could stand to lose thousands or
>million of dollars of proprietary information using any one of a plethora
>of snakeoil products.
>
>A while ago, Bruce named a few snake-oil vendors in his "Crypto-Gram
>Newsletter," Feb., 1999. Still, there is little work publicly available on
>exposing snake-oil. AccessData does some work, Pavel Semjanov
>exposes some, I do what I can. There are plenty of folks in this newsgroup
>who could do the same, maybe as an infrequent hobby. I wish they
>they would.
>
>Joe
>
>
Joe it is kind of hard to expose a product when they charge real money
for the product. I for one don't see any reason to spend money on a product
and then expose it. For one thing besides the money issue. Who would
belive me. THe unclean masses wouldn't have a mathematical background
to know that it was exposed. The fact is a real company could spend money
in some polished PR ad and the masses would belive them and not the
obvious truth that was poorly written by me. In crypto being right means
little to being rich.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
