Cryptography-Digest Digest #949, Volume #13 Tue, 20 Mar 01 10:13:00 EST
Contents:
Re: Codes that use *numbers* for keys (those who know me have no need of my name)
Re: Idea (those who know me have no need of my name)
Re: A future supercomputer (DJohn37050)
Re: Codes that use *numbers* for keys (DJohn37050)
Re: Simple XOR "pseudo encryption" : Question about my test ("Fred")
Re: Safe Multiple Encryption (Benjamin Goldberg)
Re: a 32-bit block cipher (SCOTT19U.ZIP_GUY)
Re: Fast and Easy crypt send (Benjamin Goldberg)
Re: Idea (SCOTT19U.ZIP_GUY)
Re: How to eliminate redondancy? (Joe H. Acker)
Re: Idea (SCOTT19U.ZIP_GUY)
Re: Between Silk And Cyanide - Identity checks. (Matthew GC)
Re: [OT] Why Nazis are evil (SCOTT19U.ZIP_GUY)
Memorizable passwords (was Re: Codes that use *numbers* for keys) (Benjamin Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Codes that use *numbers* for keys
Date: Tue, 20 Mar 2001 13:11:24 -0000
<996l6l$rdd$[EMAIL PROTECTED]> divulged:
>not weird number / letter / whatever combinations that
>can't be pronounced. Even hiragana would be an improvement, as long as
>they left out Wo and N.
what sounds wierd to you may not to another, and vice versa.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Idea
Date: Tue, 20 Mar 2001 13:23:22 -0000
<[EMAIL PROTECTED]> divulged:
>I'm not using a secret algorithm.
will you please keep a single from header. i really don't want to
killfile all of netcom.ca. thank you.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 20 Mar 2001 13:28:12 GMT
Subject: Re: A future supercomputer
A gigaflop computer, this has been reported in The Economist and is at IBM's
web site.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 20 Mar 2001 13:30:14 GMT
Subject: Re: Codes that use *numbers* for keys
Hey, I hear they take dollars in London.
Don Johnson
------------------------------
Reply-To: "Fred" <[EMAIL PROTECTED]>
From: "Fred" <[EMAIL PROTECTED]>
Subject: Re: Simple XOR "pseudo encryption" : Question about my test
Date: Mon, 19 Mar 2001 08:31:17 -0500
Hello,
Thank's for your informations. Im just begenning reading about
cryptography, and, I think the best way to learn, is to immediatly practice
( when you know the big base ), it's why I begenned with this "essaie" with
XOR "encryption", but it is not :P.
But, I have a question about your comments, how can you easely crack
this password? With using wich method? Becose my next program will be a
software for discovering the key and decrypt the message with this found
key.
Thank's alot for your help,
Salutations,
Fred
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Safe Multiple Encryption
Date: Tue, 20 Mar 2001 13:31:12 GMT
John Savard wrote:
[snip]
> It would therefore be very helpful if there were a set of guidelines
> for safe multiple encryption.
>
> Let us look first at the simplest case, applying multiple ciphers to a
> plaintext in order.
>
> It would seem to be true that if the following conditions were met,
> multiple encipherment would be 'pretty safe', provided at least none
> of the ciphers were contrived:
>
> - each cipher step has an independent key (either genuinely
> independent, or made independent through the use of a secure hash
> function; the GGR scheme that David Wagner recently mentioned is also
> applicable here)
>
> - no cipher step is allowed to change the size of the plaintext; where
> an IV is desired, the IV is generated independently of the cipher
> step, and supplied to it from the outside
- each cipher step must be invertible. This was probably something you
assumed, but you ought to state it anyway.
> Then it seems as though the steps don't have room to either leak key
> bits, or attack subsequent steps. But that isn't really quite enough.
>
> Not being allowed to change the length of the plaintext seems to
> prevent leaking information deliberately. After all, typical
> compression schemes, when fed an incompressible plaintext, have to
> expand it at least slightly - by one bit to say 'I didn't compress
> this'.
>
> But that does *not* actually mean that a cipher scheme couldn't be
> designed to leak key bits _when_ fed compressible plaintext and yet
> never expand the plaintext or lose part of it.
That's because you left out the invertability requirement.
With a little though, you'll see that if the cipher is required to be
invertible, in all cases, the attack dissapears.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: a 32-bit block cipher
Date: 20 Mar 2001 13:54:58 GMT
[EMAIL PROTECTED] (Gregory G Rose) wrote in <996sao$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Gregory G Rose) wrote in <996cks$[EMAIL PROTECTED]>:
>> What your looking for is a Single cycle permutaion.
>>Its not that hard to create one.
>
>Yes, but I don't need it to be a single cycle
>permutation in the sense I think you mean... it
>will just run in counter mode. At time "t" I
>represent t in 32 bits, encrypt it, and use that
>value.
OK I see what your doing.
>
>> The 80 bit key implies that it can't be too randon
>>because there are ((32**2) - 1)! different single
>>cycle transforms and to define them all as in
>>scout19u would take over a one million byte key
>>much more than 80 bits. Also how do you know each key you
>>used will lead to a maximum cycle length in your
>>32 bit block?
>
>An 80 bit key is plenty for my application, and I
>didn't want to change Skipjack more than was
>needed... mucking with key schedules is very
>sensitive stuff.
>
>Since it is a reversible encryption algorithm, by
>definition each counter value input to it is
>distinct, each output value will also be
>distinct. After 2^32 outputs, the outputs will
>form a single-cycle permutation, yes... but not
>one definined directly by the encryption function.
>
>Greg.
I see that it appears to be a single cycle from
this discription. But I worry the 80 bit key to
small. Only becasue I firmly belive when DES was
released 56 bits was easy for the NSA to break
at that time and I feel 80 bits is likely to
be easy now, But those are just my feeling
so don't worry about it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Tue, 20 Mar 2001 14:02:50 GMT
amateur wrote:
>
> What if I use single function to transmit my encrypted text E
> Algo Fast and Easy
>
> Symetric keys Bob and Alice have the same key just to receive E (not
> to encrypt). I suppose that they have the key to decrypt and encrypt.
> I'm talking about a secure sending.
>
> E=f(k)= a-k
>
> Sample
>
> E=1532 as decimal integer
>
> k= 5421 as decimal integer
>
> a= 6953 as decimal integer
>
> Bob using his key "k" send "a" to Alice
>
> The attacker ("passive attack") has only "a"
>
> Even if he intercept "a", it will be to hard to deduce "e".
> I suppose that he did intercept it. He has to decrypt it.
>
> How he can e= a-k if he obtain only "a"? he doesnot know nor E nor k.
>
> In reality Bob has to use a hudge number k not as my sample.
>
> Fast and Easy?
>
> I'm waiting for comments.
In a real life situation, an attacker sees many many ciphertexts, all
encrypted with the same key, and is even able to guess some of the
message contents. Let's suppose that the first message you send, I
happen to know the contents of... For example, suppose I tricked you
into sending "My neighbor stood on the roof and mooned the world!
hahaha!" by standing on the roof and... As a result of this, I know what
your plaintext message will be. I observe the encrypted message, and
subtract out the known plaintext. As a result of this, I have the key!
And since all your other messages are sent with this key, I can decrypt
them all.
In short, you scheme is like the one-time-pad, but without the one-time
part -- and that is the part which makes otp secure.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Idea
Date: 20 Mar 2001 14:06:38 GMT
[EMAIL PROTECTED] (Paul Crowley) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (John Savard) writes:
>
>> On 18 Mar 2001 19:50:25 GMT, [EMAIL PROTECTED]
>> (SCOTT19U.ZIP_GUY) wrote, in part:
>>
>> >Of couse the pompous assholes will find fault with many
>> >of so called ametur stuff and use that as an excuse to never really
>> >check what many ametures are doing.
>>
>> Given the number of hours in the day, and the fact that as far as most
>> amateur stuff is concerned, the time of the 'pompous' ones is better
>> spent for them working on their own stuff than looking at that, they
>> need _some_ excuse.
>
>Actually the professionals will look at amateur cryptosystems, and
>even accept them as papers to conferences, if you can present them
>properly and argue their advantages in the right way. I know, because
>I did it.
>
>I was in every way an amateur - I had a largely unrelated day job to
>do and had to work on the paper in my free time, I'd only ever bought
>two books about crypto (Applied Crypto 1st ed and 2nd FSE proceedings)
>downloading everything else, my only qualification was a 2:2 in
Sounds like you had no qualifications, Maybe you got in by
appearing to swallow the crap they feed you. If I get in it
will not be by ass kissing. Scott19u produces encrypted code
that is more secure in many ways than the crap of AES. I
did a cash contest for over a year to prove it. None of the
other methods using current stand FIPS chaining where input
and output file same length could do that.
Yes you may have to do it on a computer not conneted to internet
and yes you may have to delete files but as far as concept of
plaintext to cipher text with a key it is better in many ways.
I go for security not speed. I think your still beliveing the
shit Wagner spouted for along time about how his slide attack
would make mince meat out of it. When some one actaully tried
it proved he was full of shit and I can see your of the same
mold condem with out looking. If your to stupid to follow source
code that compiles and runs. What makes you think you can
understand encryption which has a purpose of hiding things when
you can't even understand stuff not hidden.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: How to eliminate redondancy?
Date: Tue, 20 Mar 2001 15:09:45 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Joe H. Acker wrote:
> >
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >
> > > SCOTT19U.ZIP_GUY wrote:
> > > >
> > > > see.signature (Nicol So) wrote in
> > > > <[EMAIL PROTECTED]>:
> > > >
> > > > >
> > > > >That's not true. Lossless compression works exactly by reducing
> > > > >the redundancy in the representation of information.
> > > > >
> > > >
> > > > Actaully most Lossless compressors that are not bijective
> > >
> > > A compressor which is lossless is bijective.
> >
> > ...if you compare possible outputs of the compressor with possible
> > inputs of the compressor.
>
> If you try to claim that the set of *all* streams is the range, when it
> isn't, then of course you lose the "onto" property, since some streams
> simply don't get produced. An incorrect definition of range produces an
> incorrect conclusion regarding the onto property, and hence the
> bijection property.
There are no incorrect definitions, just more or less appropriate ones.
> If you use definitions other than those that the scientfic community
> accepts, you can make any sort of claims you like.
Okay, let's find another term for the property David Scott has proposed.
To name it "bijective" is confusing and not appropriate, so let's call
it "s-bijective" (S in honour of David Scott). But perhaps that is not
even necessary because there's already a precise term for this that is
established in contemporary mathematics---I'd guess there is. Anyway
David Scott has made clear *what* exactly he means, although he has done
this informally and might not always been using the appropriate terms.
So instead of argueing about names, is there actually someone who has
opinions about how and how much overall security an s-bijective
compressor would add or not add? What do cryptanalists say about
s-bijective compression once they have learned what "s-bijective" is
supposed to mean?
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Idea
Date: 20 Mar 2001 14:23:30 GMT
[EMAIL PROTECTED] (David Schwartz) wrote in
<[EMAIL PROTECTED]>:
>
>
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> I hate it when people think it is necessiary to prove one
>> is qualified to do something.
>
> Why? Because you can't prove you're qualified?
>
One can never prove one is qualifed to a group of
assholes who don't like you in the first place. They
only claim your qualifed if you can kiss ass and hold
some of there limited views about encryption.
I think as proof of that would needs only to look
at padding for certian of the encryption modes. I have
argued for a long time they should be completely bijective.
This will not happen until some asshole claims to think
he thought of it first. I use this as an example.
Actually the concept is so simple many people I am
sure have thought this up years ago. But why has it not
been implimented. The standards I have seen for padding
suggest adding (for 64 bits 8 bytes ) one to eight characters
ALWAYS when doing ( for exampe ECB ) encryption. This is
stupid since when exaiming what happens when a wrong key
is used. You often get messages that could not have been
encrypted with the method above. This is easy to see for
even a high school student.
The fix is so simple the resulting file when encrypted
will either be the same file or one block smaller. Yet
it will be fully reversable when a wrong key used. Why
has not this been fixed years ago. My guess is either
the NSA has seen to it that it is not fixed. Or the limited
narrowmindedness of those in a position to decide just are
there for show and really never gave it second thought.
Which makes me wonder how good anything they produce can
be if even the simple stuff is not done correctly.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Matthew GC <[EMAIL PROTECTED]>
Subject: Re: Between Silk And Cyanide - Identity checks.
Date: Tue, 20 Mar 2001 14:29:08 GMT
> > An expansion of this idea might work.
> >
> > On OTPs there are groupings of letters that are transmitted in plain
> > text to identify which OTP is in use. What Roger could do in his first
> > message to Bob is within the cypher text to specify another OTP by its
> > id letter group and then specify which of this OTP's letter groupings he
> > will use to modify every OTP he uses in future. Then of course he would
> > destroy the OTP that he is using for his identity check. This however
> > wouldn't work if Roger and Alice are captured before Roger has
> > transmitted his first communication to Bob.
>
> I can't see any reason for your expansion. My scheme works like I've
> described it,
Sorry for my delay in replying, I had a long weekend away.
The reason for my expansion on your scheme was to improve it, you scheme
would work. One problem with it is that Alice is specifically told not
to look at the OTPs given to Roger (she knows where the numbers that
will be used as ID are). It may be hard for Alice not to look at the
OTPs and if she did her eyes might *unconsciously* look at the ID
sequence, human nature being what it is this is not out of the question
even for a trained agent. My scheme removes this possibility since Alice
won't know which OTP and which group on the OTP Roger will use as his ID
check.
Still I don't think Mark's solution is along these lines. Firstly
because it doesn't get around the 'what if Alice is captured before
handing the OTP's over to Roger' problem. Secondly in the book Marks is
asked not to reveal his solution, why would they ask him to keep quiet
(even today) if his solution is so *simple* that it can be guessed with
a few minutes thought by people not even involved in the 'Intelligence'
community. Finally (the weakest reason) Marks' boss, is very impressed
with the cleverness of the solution and I am not that impressed with our
ideas.
I'd be interested if you have any other thoughts on this matter.
Regards,
..matthew
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: [OT] Why Nazis are evil
Date: 20 Mar 2001 14:30:46 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Your response clearly demonstrates the point I was making in the post
>you responded to -- specifically, whether certain things are good or bad
>(or "evil") is something that different people people have different,
>possibly irreconcilable, beliefs about.
I agree on the above with you.
>
>Further, I think we can all agree that there's no possibility of all of
>coming to an agreement one way or another about right and wrong, any
>time this century. This seems to indicate -- to me, at least -- that it
>is now time to end this discussion and this thread.
>
Why is it time to end it. I just got interested in reading it.
Especially since you seem reluctant to stand up for your
beliefs. What ever they are. If you fear discussion maybe you
should reexaimine what your beliefs really are.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Memorizable passwords (was Re: Codes that use *numbers* for keys)
Date: Tue, 20 Mar 2001 14:41:39 GMT
Joe H. Acker wrote:
>
> Juuichiketajin <[EMAIL PROTECTED]> wrote:
>
> > Even granting that binary divisions are somehow superior, I suspect
> > that the REAL reason bits are used, rather than bytes or at the very
> > least nibbles, is so the sizes sound bigger.
> > When you hear "48-bit key", don't you find yourself performing some
> > mental calculation as to the value of 2^48 in some other system?
>
> You're somewhat right if you exchange "key" with "passphrase". In many
> language systems, one character (like a Hiragana symbol) is
> represented by two or more bytes, but the maximum entropy actually is
> defined by what the user can enter, not by the number of bits used to
> represent the characters. Same for plain ASCII: the user can only
> enter a small subset of the whole character range 0...255 (or 0..127
> resp.). That's something an implementor has to be aware of.
>
> Of course, you have to hash the passphrase and try to "stretch" it.
> Nevertheless, when the user just enters 4 or 5 symbols as passphrase,
> the cipher will be broken by brute force attack. And as the user has
> to be able to remember his passphrase, a clever guessing attack is
> likely to succeed against many passphrases that are much longer. That
> means, that in real-world applications, the theoretical keyspace is
> only good for measuring strength against direct attacks against the
> possible keys, not for measuring attacks against the passphrase.
The reason you suggest that passphrases should be memorizable is a
leftover from when crypto was something only the military used. In a
military encipherment scheme, it's common for, multiple people have the
key memorized, and if one person forgets it, it's not a great loss, but
if one person writes it down, and it's stolen, it's a HUGE loss. Also,
if a soldier has a written version of the key somewhere on his person,
and he gets captured, again, it's a HUGE loss.
This kind of key management is anachronistic, or at least, not really
applicable to most private citizen's crypto.
For data enciphered with a modern system, the key is known by one and
only one person, and if it's forgotten, then the data is irrecoverable.
There's also little threat of private citizens being captured by enemy
military.
So not only is there great loss from forgetting, there is little
likelyhood of a written down passphrase being stolen (unless you leave
it in the workplace).
So for a private citizen, the intelligent thing is to have a long
passphrase, write it down, and keep it nice and safe in your wallet,
right next to your credit cards. And don't worry about memorizing it.
> But in order to be aware of such issues, you need to use bits as
> units. Heck, on a strange system, a character might even be
> represented as 4 bytes, but only 1 of them actually used. If you don't
> strip the remaining 3 off, the attacker knows a lot of plaintext at
> regular patterns that has been fed into the hash fuction.
Actually, this could be even worse... suppose your characters are 16 or
32 bit unicode values, and you are implementing in C. You somehow
confuse the endian-ness issue, and are trying to strip off the unused
byte or bytes from each character... and end up stripping of the wrong
ones! Whoops!
Moral: Your hash function should be good enough that feeding in regular
patterns should not be harmful, so long as the entropy is there.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
