Cryptography-Digest Digest #246, Volume #13 Thu, 30 Nov 00 12:13:00 EST
Contents:
Re: RC4 Questions (Guy Macon)
Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys! (PhyloBhetto)
Re: Probability Question on Square Attack (John Savard)
Re: keysize for equivalent security for symmetric and asymmetric keys (DJohn37050)
Vulnerability to Attack ("James Dabbs")
Re: voting through pgp (Dan Oetting)
Re: Pentium 4 and modular exponential ("James Dabbs")
Trivial Encryption Algorithm (TEA) ("James Dabbs")
PRNGD for Windows ("James Dabbs")
Re: Trivial Encryption Algorithm (TEA) (John Myre)
ARCFOUR (RC4) used for CipherSaber-N (Glide)
Re: Trivial Encryption Algorithm (TEA) ("James Dabbs")
Re: Pentium 4 and modular exponential ("James Dabbs")
Re: Vulnerability to Attack (Eric Lee Green)
Re: Trivial Encryption Algorithm (TEA) (Simon Johnson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4 Questions
Date: 30 Nov 2000 06:01:28 GMT
James wrote:
>
>
>After reading the information on the ciphersaber web site, I have a few
>questions about RC4.
>
>The site led me to believe that the maximum secure key length was 512 bits
>(where the key is the string used to initialize the random number
>generator). Is this correct??? Could I use a longer key and not have my
>security compromised?
>From http://ciphersaber.gurus.com/
"To leave room for the initialization vector, the length of the
user key must be less than 246 bytes (1,968 bits). To insure
adequate mixing of the initialization vector and user key, we
recommend you select a user key of 54 bytes (432 bits) or less."
http://ciphersaber.gurus.com/cryptanalysis.html
"In most cryptosystems, the longer the key, the better. However,
it was pointed out by several individuals who looked at
CipherSaber-1 that a very long user key could prevent the IV
from affecting more than a few of the S(i) values. This could
cause leakage of plaintext. To insure adequate mixing, we
advised users to restrict their user key length to 54 characters
or less, as most would anyway. This insures that the IV will
be mixed in at least four times during the setup process."
A key of < 41 bytes (328 bits) insures 5 mixings
A key of < 54 bytes (432 bits) insures 4 mixings
A key of < 74 bytes (502 bits) insures 3 mixings
Please note that the effect of not enough mixings is to allow an
attacker to make a slightly better than random guess as to what
the second byte in your plaintext is. That's it.
>Also, the ciphersaber implemtation suggests appending a fixed
>number of random bytes to the end of the key (10), and then
>placing these random bytes at the start of the encrypted stream.
>Doesn't this compromise security??? Is there something I'm missing??
The ciphersaber web page doesn't "suggest" anything. You must
do it the way they say or it isn't ciphersaber. Ciphersaber is
one of many implementations or ARCFOUR - you are free to do it
however you please, but not to call the result ciphersaber.
The 10 random bytes let you use the same 54 bytes as your key
over and over, yet still allow ARCFOUR to see a different 64
byte key every time. On the other end, the repipient who knows
your 54 byte key needs to know those extra 10 bytes, so they are
sent in the clear.
Now I have a question for you; why do you wish to use a longer key?
Surely you don't believe that someone will do a brute force guess
and come up with your 54 byte/432 bit passphrase! I understand
the temptation - when I am faced with an encryption scheme that allows
keys of 128, 256, 512, 1024 and 2048 bits, I pick 2048. There is
no added security over 1024 bits though; all I am doing is stealing
CPU cycles from my sreensaver...
If you want to maximize your security, just implement ciphersaber as
described. You will be using a system that has been tested and
attacked over and over again without breaking. Why give that up for
a nonstandard, untested variant?
On the other hand, if your purpose is to learn rather than just to
keep your data secure, then by all means try various modifications.
------------------------------
From: PhyloBhetto <[EMAIL PROTECTED]>
Subject: Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys!
Date: Thu, 30 Nov 2000 14:19:20 GMT
In addition... if you actually watch the packets on the supposed
encrypted line, you'll find that they aren't encrypted at all... The
user/password were the only things encrypted for me.
In article <[EMAIL PROTECTED]>,
Eric Smith <[EMAIL PROTECTED]> wrote:
> I've been trying to find an FTP client for Windows that supports SSL,
> and tried WS_FTP from Ipswitch. It's inexpensive, and they provide
> a time-limited demo.
>
> I'm very glad that they provided the demo. If I'd paid money for it
> I'd demand a refund. I found out the hard way that they support
> *only* 40-bit ciphers. I inquired of their technical support,
> expecting perhaps to be told that I needed an expensive SGC
certificate
> in order to use secure crypto. To my surprise they said that they
> don't support it at all.
>
> Although the product seems to be quite good in other respects, I have
> to recommend *against* it for anyone who actually is concerned about
> security.
>
> Eric Smith
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Probability Question on Square Attack
Date: Thu, 30 Nov 2000 13:53:41 GMT
On Thu, 30 Nov 2000 02:42:01 GMT, Raphael Phan <[EMAIL PROTECTED]>
wrote, in part:
>What is the random probability of obtaining a delta set used in the
>Square Attack? In the case of Square, a block is a collection of 16
>bytes, hence a delta set is a byte with all 256 possible values while
>the 15 other bytes have all constant values...
The probability would be
16 * (256!/2^2048) * (1/2^(15*2048))
which is more than astronomically low.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 30 Nov 2000 14:53:55 GMT
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Roger,
Regarding the ANSI X9 group,
not only bankers sit on ANSI X9 workgroups. NIST and NSA representatives sit
on ANSI X9 committees to ensure the result is reasonably good, security-wise.
They speak up when it is not. We are talking real money here and bankers want
it to be protected.
Regarding the keysize chart,
NIST has a working arrangement with NSA to be able to consult with them on
these kind of security related matters.
But as you do not attend, you may not have known these facts.
Don Johnson
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Subject: Vulnerability to Attack
Date: Thu, 30 Nov 2000 10:28:07 -0500
We are adding features to an existing client/server telecom system. One of
the problems I have with it is its's method of data security, although I am
new to this.
In the present system, multiple clients connect to a single server using an
account/password and TCP/IP connections. In the protocol, each PDU is
prefixed with a 32-bit random spoiler and then encrypted using "TEA". TEA
is a private key 128-bit block cipher, and the protocol uses CBC to encrypt
a whole packet. The TEA key comes from a hash (proprietary, as far as I can
tell) of the account password string. After a connection, the first PDU
contains the account ID string in the clear. Everything else after that is
encrypted. The password itself is not transmitted over the link.
The original author argues that this is secure and supports UDP, which SSL
does not support. And to my knowledge, it has never been hacked. However,
none of us are data security experts, and my argument is that we should
tunnel the protocol through SSL because this is where the experts are
putting their analysis and talent.
Can anyone point out any obvious flaws in the above scheme?
Thanks,
James Dabbs
------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Thu, 30 Nov 2000 08:43:33 -0700
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>
> Although it's clear that there was a problem in that election, the
> concept is still sound. Firstly, the audit log probably actually
> punched (not dimpled) holes in paper, or printed with ink on paper,
> unlike the problematic florida votes, where in properly done there were
> punched holes, but in some ballots were only dimpled -- thus, checking
> by hand probably did not involve "iffy" ballots. Secondly, the problem
> described *could* most certainly be fixed in the next design of the
> machine -- once new machines are built, with the problem fixed, the
> problem you described won't happen again.
I can only relate what I heard in the news at the time but I think they
were reading dimples on the audit log because they also forgot to change
the ink. The problems were all solved in the next election by switching
to a marksense system and shipping the old voting booths to Denver.
I do have direct experience with the problems causing dimpled ballots on
the Votomatics used in Florida. I was working as an election judge a few
years back when a voter complained that one of the holes would not
punch. I tested the unit with a sample ballot and the best I could do
without breaking the stylus only dimpled the ballot (not a pregnant chad
but a little round dimple caused by the tip of the stylus). The ballot
frames used in the Votomatics have a small access port in the front for
shaking out the chad. After shaking out the loose chad I could see a
solid clump near the back corner. I think I used a knitting needle to
prod at the clump and break it up. (one of the judges thought she would
have time to knit :)
I can only speculate on what causes the chat to clump. The Votomatics
are occasionally removed from the booth to assist disabled voters. By
moving the Votomatic, all the punched chad is going to shift to a side
or corner. When the Votomatic is returned to the booth the top end is
inserted first then the bottom end is lowered and latched in place. This
process almost guarantees that all the chad is in one of the top corners
of the ballot frame. Each time a vote is cast in the corner where all
the chad has accumulated the chad is compressed a little. Eventually a
wall builds up around the hole and as more votes are cast the pocket
fills in and a solid column of chad backs up to just beneath the ballot.
[I realize we have wandered way off topic in this thread. There is
probably a better group for discussing voting systems that don't involve
cryptography. I'll follow if someone wants to move.]
-- Dan Oetting
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: Thu, 30 Nov 2000 10:54:58 -0500
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> <snip> may be that you have to have software
> optimized for the Pentium 4 to get any benefit.
I would say so. It's architecture is wildly different from the P3 or
anything I've ever seen before.
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Subject: Trivial Encryption Algorithm (TEA)
Date: Thu, 30 Nov 2000 11:01:19 -0500
I've seen a brief history of this algorithm. First, it was invented, then
someone broke it, then the author "fixed" it by changing the key digest.
However, the present status of this algorighm is unclear to me. Does anyone
know how the "revised" TEA stacks up against 3DES and other block cyphers?
TEA is interesting to us because of the low CPU overhead - but we don't want
to use it if it's "weak" in some way we don't understand.
James Dabbs
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: PRNGD for Windows
Date: Thu, 30 Nov 2000 11:10:09 -0500
Is there a PRNGD (or equivalent) designed as a WindowsNT service?
James Dabbs
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Trivial Encryption Algorithm (TEA)
Date: Thu, 30 Nov 2000 09:18:53 -0700
James Dabbs wrote:
>
> I've seen a brief history of this algorithm. First, it was invented, then
> someone broke it, then the author "fixed" it by changing the key digest.
<snip>
I think that the "someone" is David Wagner, who actually
posts here quite often. Also, I think it may be a little
much to say he "broke" it; it depends on your definitions.
If I understand correctly, the vulnerability of consequence
is to an attack that requires encryption of 2^32 blocks under
each of two related keys (i.e., the attacker gets to choose
how the second key differs from the first). Whether this is
a real attack depends on your circumstances.
On the other hand, almost anyone would agree that 3DES is
"safer": not because we know so, but because it has had
much more analysis without falling. I wouldn't care to
hazard a guess of this type in comparing TEA to, say, AES.
On a third hand: the protocol(s), and other system-level
implementation issues, are far more likely to be a
problem than the actual encryption algorithm.
JM
------------------------------
From: [EMAIL PROTECTED] (Glide)
Subject: ARCFOUR (RC4) used for CipherSaber-N
Date: Thu, 30 Nov 2000 16:27:44 GMT
Hi Cryptoids. If any of you are familiar with the CipherSaber
implementation of RC4 and you would care to enlighten me, I'd
appreciate it. Since I do my thing in Visual Basic, it will look
fairly different from the usual suspects (C code).
If you are so inclined, please comment to this here in the newsgroup
since my e-mail address is fraudulent.
I use a Visual Basic version of ARCFOUR. I tried it against
thevectors that were published with "alleged RC4" and it passes. I
added support for CipherSaber (part of which will not show in the
following code) and would like to correctly implement CipherSaber-n
where n is the number of times you mix the key. I'm not sure I'm
doing it in the right spot. If you wouldn't mind, would you comment
on where I propose to mix the key "n" times? Here is the code:
' *** Begin ARCFOUR Function ***
Public Function ARCFOUR(inp As String, key As String) As String
Dim S(0 To 255) As Byte, K(0 To 255) As Byte, i As Long
Dim j As Long, temp As Byte, Y As Byte, x As Long, z as long
Dim Outp As String
Dim n as long
' Array/S-box is setup for ARCFOUR
For i = 0 To 255
S(i) = i
Next
j = 1
For i = 0 To 255
If j > Len(key) Then j = 1
K(i) = Asc(Mid(key, j, 1))
j = j + 1
Next i
' end of setup
'*** This is where I'm mixing the key "n" times
'*** If n = 1 then it is standard CipherSaber
'*** This example shows CipherSaber-2
'*** beginning of part 1 of added code
n = 2
For z = 1 to n
'*** end of part 1 of added code
' This is where I believe the key is mixed for ARCFOUR
j = 0
For i = 0 To 255
j = (j + S(i) + K(i)) Mod 256
temp = S(i)
S(i) = S(j)
S(j) = temp
Next i
' end of key mixing
'*** beginning of part 2 of added code
Next z
'*** end of part 2 of added code
' encryption part of ARCFOUR
i = 0
j = 0
For x = 1 To Len(inp)
i = (i + 1) Mod 256
j = (j + S(i)) Mod 256
temp = S(i)
S(i) = S(j)
S(j) = temp
t = (S(i) + (S(j) Mod 256)) Mod 256
Y = S(t)
Outp = Outp & Chr(Asc(Mid(inp, x, 1)) Xor Y)
Next
' end of encryption
ARCFOUR = Outp
End Function
' *** End ARCFOUR Function ***
*** Important *** - This code does not show generation or handling
of the CipherSaber ten-byte vector which is appended to the key and
will be prepended to the encrypted data.
Thank you.
Glide
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Subject: Re: Trivial Encryption Algorithm (TEA)
Date: Thu, 30 Nov 2000 11:37:48 -0500
> On a third hand: the protocol(s), and other system-level
> implementation issues, are far more likely to be a
> problem than the actual encryption algorithm.
Agreed! I have a seperate post ("Vulnerability to Attack") asking about
this as well..
Thanks for the info..
James Dabbs
------------------------------
From: "James Dabbs" <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: Thu, 30 Nov 2000 11:43:51 -0500
This situation reminds me of when 386's came out and everyone said the
performance increase was not so great. Of course everyone was running
segmented 16-bit apps and it was hard and expensive to find 32-bit tools.
Well, same thing now. Of course, with IA-64, I can't even see how a C++
compiler can even make use of the architecture.
Roger Schlafly <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom's Hardware has had mixed reviews of the Pentium 4. The
> chip did well on some benchmarks, but surprisingly poorly
> on a lot of them. It may be that you have to have software
> optimized for the Pentium 4 to get any benefit.
> http://www.tomshardware.com/blurb/00q4/001128/index.html
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Vulnerability to Attack
Reply-To: [EMAIL PROTECTED]
Date: Thu, 30 Nov 2000 16:35:35 GMT
On Thu, 30 Nov 2000 10:28:07 -0500, James Dabbs <[EMAIL PROTECTED]>
wrote:
>a whole packet. The TEA key comes from a hash (proprietary, as far as I can
>tell) of the account password string. After a connection, the first PDU
>contains the account ID string in the clear. Everything else after that is
>encrypted. The password itself is not transmitted over the link.
This is succeptible to dictionary attacks. If the hash algorithm can be
duplicated (a simple case of reverse-engineering a stolen copy of the
software), a large selection of pre-defined passwords can be hashed with
the algorithm. Then each resulting hash key can be attempted as a
decrption key on packets captured off of the network. In one study, this
approach "cracked" over 80% of the passwords used on a network. This
approach is also used for most attacks against Microsoft's CHAP
authentication protocol.
In addition, the protocol may be succeptible to replay attacks, depending
upon how encryption is handled in the resulting packets (do they have
a random value pre-pended to them and use a good cipher feedback mode?).
Finally, password storage on the server side is an issue. It may be
possible for an attacker to gain access to the password store. This
gives the attacker access to log in as anybody, since all he has
to do is use the hashes in the password store to encrypt his connections.
All in all, I believe you are quite correct to be worried about the
security of this scheme. It appears to use techniques which have been
repeatedly "cracked" in the past. I suggest that you go to
http://www.counterpane.com and read Bruce Schneir's and Mudge's cracks
of various versions of Microsoft CHAP, which uses similar techniques
(though to a different end).
Regarding solutions, SSL is certainly a possibility, and one which has
received a large amount of cryptoanalysis. I would suggest, however,
consulting with a competent designer of cryptographic systems because
SSL is only part of a system, and by no means ensures that the entire
cryptographic system is secure.
--
Eric Lee Green http://www.badtux.org
[EMAIL PROTECTED]
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Trivial Encryption Algorithm (TEA)
Date: Thu, 30 Nov 2000 16:41:38 GMT
In article <905t2p$t7t$[EMAIL PROTECTED]>,
"James Dabbs" <[EMAIL PROTECTED]> wrote:
> I've seen a brief history of this algorithm. First, it was invented,
then
> someone broke it, then the author "fixed" it by changing the key
digest.
> However, the present status of this algorighm is unclear to me. Does
anyone
> know how the "revised" TEA stacks up against 3DES and other block
cyphers?
> TEA is interesting to us because of the low CPU overhead - but we
don't want
> to use it if it's "weak" in some way we don't understand.
>
> James Dabbs
>
>
TEA stands for Tiny Encryption Algorithm _NOT_ Trivial Encryption
Algorithm. TEA was cracked by Bruce and Co, and they modified the
keyshedule to prevent the attack they showed against TEA. This new
algorithm is called XTEA.
This said, XTEA is not a very good cipher. Though its tiny, it is
almost certainly not as strong as any of the AES candidates.
Since you mentioned speed as a requirement, i would recomemend Blowfish
or Rijndael for your application.
=====
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
