Cryptography-Digest Digest #422, Volume #14 Thu, 24 May 01 07:13:00 EDT
Contents:
Re: "computationally impossible" and cryptographic hashs (Paul Crowley)
Re: survey (Paul Crowley)
Re: Unix file encryptor (Paul Crowley)
Re: ECB plus padding instead of CBC? (Roger Fleming)
Quicksilver ("Greg Pierce")
Re: ECB plus padding instead of CBC? (David Wagner)
Re: "computationally impossible" and cryptographic hashs (David Wagner)
Re: taking your PC in for repair? WARNING: What will they (Martin Schultz)
1st CipherText Application prototyped ("Prichard, Chuck")
Re: survey (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Combining functions for stream ciphers ("Tom St Denis")
Re: survey ("Tom St Denis")
Message for Alexis Machado (Paul Crowley)
----------------------------------------------------------------------------
Subject: Re: "computationally impossible" and cryptographic hashs
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 24 May 2001 05:33:34 GMT
[EMAIL PROTECTED] (Mark Wooding) writes:
> You're also not wrong in guessing that it's possible for two Unix
> passwords to have the same hash. However, I don't think anyone's
> actually found such a pair yet. ;-)
Bearing in mind that Unix passwords are accompanied by a
randomly-generated salt, so the hash is
H(password, salt) = hash
David Wagner posted such a pair to the group about a year ago, in a
discussion of the van Oorschot and Wiener parallel collision search
algorithm.
I don't suppose it would be much harder to find a pair using the same
salt value, but that wasn't the case with David Wagner's pair.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
Subject: Re: survey
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 24 May 2001 05:33:34 GMT
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> Thanks. I think I should work more on my "Tack" (is that how you
> spell it?) than my Analysis skills.. heheheh
Your name came up in a conversation at FSE 2001 this year, and people
thought it likely that, if you worked on your tact and attitude as
well as your analysis skills, we'd see you at a future such
conference.
Today's reading, thus, is Bruce Schneier's "Self-Study Course in Block
Cipher Cryptanalysis" and Dale Carnegie's "How to Win Friends and
Influence People" ;-)
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
Subject: Re: Unix file encryptor
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 24 May 2001 05:33:34 GMT
"Arik Shelter" <[EMAIL PROTECTED]> writes:
> I am looking for a command-line Unix file encryptor that uses 128 bit (or
> higher) encryption. Does anyone know of anything out there besides PGP (too
> much $$$) or GnuPG (not recommended for production environments) ?
GnuPG (www.gnupg.org) provides the most trustworthy message encryption
I know of, and supports both public-key and symmetric encryption; I
can see no reason why it should not be used in a production
environment. It would certainly be my first recommendation.
There are also versions of PGP available which are not Open Source but
which can legally be had for no money: see www.pgpi.org
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: ECB plus padding instead of CBC?
Date: Thu, 24 May 2001 05:06:53 GMT
Julian, in this post I keep referring to the mode you proposed. To avoid
calling it "your mode", which sounds a bit personal, I will call it "CP mode"
for "cruft padded mode".
"Julian Morrison" <[EMAIL PROTECTED]> wrote:
[...]
>Count mode if I understand it is:
>
>(crypt(block-count as 16 byte bignum)) xor (crypt(16 byte data-chunk))
Err, no. This may be why you're arguing at cross purposes; counter mode is
much simpler than that. It's just:
crypt(counter) xor plaintext
Plaintext is 1-16 bytes long, as required. Counter can be _anything_ that is
highly unlikely to repeat before re-keying, and is accessible to the receiver.
It does not have to be secret, and is commonly sent in clear in front of the
first encrypted block. Conventionally, it's a counter starting from zero 'coz
that's nice and simple, but something like the packet number is ok too
(provided the opponent can't go manipulating packet numbers on you).. The
number of bits actually incremented in the counter will depend on your
application, but for nearly all real world applications only a single 32 bit
add is required. You say that 2^32 blocks before re-keying isn't enough for
your application; that's a pretty huge data stream!! For example, if you're
doing voice over IP, you won't need to increment the second 32 bit word for
more than a year! Hopefuly before then, you will have re-keyed anyway.
>As a reciever-stateless datagram, that's:
>
>- 1 byte: number of significant bytes in the count (after trimming all
>left-side 00 bytes)
>
>- 0..16 bytes: count, as many bytes as the preceding byte indicated.
>
>- 16 bytes: encrypted data chunk
>
>This would be able to survive block loss. It would be computationally much
>slower than just cruft-padding each block and ECB-ing (one encrypt,
>versus two encrypts, an xor, and a bignum increment)
No. Even if the receiver is _totally_ stateless (in which case, where does it
get the key?), it can still use the packet number for the counter. Then the
only data transmitted is the encrypted block. Message expansion: zero. Speed:
one encrypt plus 4 x 32 bit xors, which is much faster (on average) than one
encrypt plus calling bits from /dev/urandom. Either way, both processes are
dominated by the speed of the encrypt, so there isn't much point comparing CPU
time, we need to look at security and network efficiency.
Even if, for some reason, you can't use the packet number (eg an evil process
on your host may cause you to repeat packet numbers quickly, in violation of
various RFCs), putting the counter (or the fast changing bits of the counter,
say 4 octets, or 8 if you will have a _very_ persistent key) in the start of
the packet will do the trick, _regardless_ of the number of blocks per packet.
This is a message expansion of 4 or 8 octets _per_packet_, and almost no
computation.
>> Assuming that you are looking at datagrams of no more than 4 Rijndael
>> blocks at a time, I believe your mode to be the best for your situation.
>
>Where did "no more than 4 Rijndael blocks" come from?[...]
What he meant was that counter mode (with the counter prepended as
plaintext) offers a data expansion of a fixed number of bytes, while CP mode
expands data by a percentage, so it will be interesting to see where the
crossover is, ie where one becomes more efficient than the other. He said 4
blocks, but actually he's erred considerably in favour of CP mode! Let b be
the number of data bytes, the counter mode expands to (probably)
b + 4
or maybe
b + 8
while CP mode expands to
16 b /12 = 4 b/3
Obviously if we only use 4 bytes for the counter, CP mode is _never_ more
efficient. If we use an 8 byte counter, CP mode becomes less efficient when 4
b/3 > b + 8
ie b > 24
So if we have even two blocks per packet, CP mode wastes space as well as
being slower.
Now you've said you only want to send one block (16 octets) of data per packet
"to be sure to be less than any MTU". No modern medium uses an MTU smaller
than 1kB (64 blocks), (ethernet is 1500 octets, BTW) and even the tiniest old
fashioned MTUs I've ever heard of are 128 octets (8 blocks). Using packet
sizes as small as you are discussing will cause serious transmission
inefficiencies and are simply unneccesarily small for fragmentation issues.
Error expansion:
Error expansion is not a serious issue here, because we know any received
error is likely to cause the whole packet to be dropped. However it is to be
noted that counter mode is very resilient to bit flipping errors: each bit
flipped will cause the garbling of exactly one bit. CP mode has the same error
expansion poperty as ECB mode: a flipped bit will cause a whole block (128
bits) to be garbled.
OK, now the biggie: security.
In a nutshell, counter mode has been well studied for decades, whereas no-one
has studied the security properties of CP mode. But to be more specific, the
two problems with ECB are:
1. The opponent can re-order, delete or duplicate blocks at will. The classic
example of this is where the attacker debits his bank account by $1000
dollars, then credits it by $1. He listens in over the wire, and takes the
firts part of message 2 ("Credit Mr Bloggs") and the second part of message 1
("$1000"), combines them, and starts adding money to his account.
Counter mode completely prevents this class of attack, but CP mode provides
absolutely no protection against it.
2. Although the attacker can't see inside blocks, he can look at statistics of
whole blocks. In ECB mode, if the plaintext has very little randomness, he
will quite often see matching blocks, and may start to glean all sorts of
useful information from it. Counter mode guarantees that repeating plaintexts
will not reveal themselves until the counter clocks over (after 2^128 bocks,
ie a little after hell freezes over). In CP mode, there is a significant risk
of repeating plaintexts revealing themselves after 2^16 blocks (birthday
paradox), and a certainty after 2^32 blocks (you implied you are likely to
send many more than 2^32 blocks under each key). Thus, although CP mode is
better in this regard than ECB, it is not nearly as good as counter mode.
3. On the other hand, the zero error expansion property of counter moe means
that an opponent who knows _exactly_ what certain encrypted bits mean, can
change them to any other value of the same length. (He can't do this in ECB
mode or CP mode with any realsitic possibility of success, although increasing
the amount of "cruft" in CP mode (to harden against the problem in 2., above)
makes it more likely.) Thus in situations where this is a plausible
possibility, counter mode should be used with a MAC. But the conservative
approach is to use a MAC with all ciphers all the time, anyway.
In short, CP mode is computationally less efficient, less network efficient,
and less secure. As Mr Schneier wrote: "stay away from the weird modes. One of
the standard modes is nearly always better".
------------------------------
From: "Greg Pierce" <[EMAIL PROTECTED]>
Subject: Quicksilver
Date: Thu, 24 May 2001 07:14:35 GMT
This is a multi-part message in MIME format.
=======_NextPart_000_001C_01C0E3FF.860034E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I was wondering if anyone has experienced any problems using =
Quicksilver's nym creation wizard.=20
When I try to go through the process of creating a nym, I can't seem to =
get the key for the nym that I created on my PGP keyring to dropdown =
from the drop down menu. I followed the directions exactly,...using a =
RSA key, and limiting it to 2048 bits. It even appears on my keychain =
from within the QS program.
I would appreciate any comments, suggestions.
Sincerely,
Greg
=======_NextPart_000_001C_01C0E3FF.860034E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Lucida Bright">Hello,</FONT></DIV>
<DIV><FONT face=3D"Lucida Bright"></FONT> </DIV>
<DIV><FONT face=3D"Lucida Bright">I was wondering if anyone has =
experienced any=20
problems using Quicksilver's nym creation wizard. </FONT></DIV>
<DIV><FONT face=3D"Lucida Bright">When I try to go through the process =
of creating=20
a nym, I can't seem to get the key for the nym that I created on my PGP =
keyring=20
to dropdown from the drop down menu. I followed the directions =
exactly,...using=20
a RSA key, and limiting it to 2048 bits. It even appears on my keychain =
from=20
within the QS program.</FONT></DIV>
<DIV><FONT face=3D"Lucida Bright"></FONT> </DIV>
<DIV><FONT face=3D"Lucida Bright">I would appreciate any comments,=20
suggestions.</FONT></DIV>
<DIV><FONT face=3D"Lucida Bright"></FONT> </DIV>
<DIV><FONT face=3D"Lucida Bright">Sincerely,</FONT></DIV>
<DIV><FONT face=3D"Lucida Bright">Greg</FONT></DIV>
<DIV> </DIV></BODY></HTML>
=======_NextPart_000_001C_01C0E3FF.860034E0==
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: ECB plus padding instead of CBC?
Date: 24 May 2001 08:07:32 GMT
Julian Morrison wrote:
>Count mode if I understand it is:
Nope, it's simpler than you thought. You might want to see the
following paper for an overview and proposal for standardization:
Helger Lipmaa, Phillip Rogaway, and David Wagner.
"Comments to NIST Concerning AES-modes of Operations: CTR-mode Encryption."
http://www.cs.berkeley.edu/~daw/papers/ctr-aes00.ps
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: 24 May 2001 08:10:14 GMT
Paul Crowley wrote:
>[EMAIL PROTECTED] (Mark Wooding) writes:
>> You're also not wrong in guessing that it's possible for two Unix
>> passwords to have the same hash. However, I don't think anyone's
>> actually found such a pair yet. ;-)
>
>Bearing in mind that Unix passwords are accompanied by a
>randomly-generated salt, so the hash is
>
>H(password, salt) = hash
>
>David Wagner posted such a pair to the group about a year ago, in a
>discussion of the van Oorschot and Wiener parallel collision search
>algorithm.
>
>I don't suppose it would be much harder to find a pair using the same
>salt value, but that wasn't the case with David Wagner's pair.
Yup. Here's the pair, if anyone cares:
crypt("2NGGMda3", "Hx") = "yX8CL2luKyI"
crypt("gnB9Gw1j", "s8") = "yX8CL2luKyI"
[after removing the salt which crypt(3) prepends to its output]
This was just a fun toy exercise, with no practical implications
for crypt(3) that I can see. More may be found at
http://www.cs.berkeley.edu/~daw/my-posts/crypt-collision
------------------------------
From: Martin Schultz <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they
Date: Thu, 24 May 2001 10:26:10 +0200
On Wed, 23 May 2001 20:03:22 GMT, Darren New <[EMAIL PROTECTED]> wrote:
>Jim Turner wrote:
>> Two others to look at are LCC, which has a decent IDE, and MINGW,
>> which is based on GNU but uses standard windows DLLs instead of a unix
>> emulation DLL. There is also the DEV-C++ package which adds an IDE to
>> MINGW or Cygwin.
>
>Does it really need to be written in C?
No it can be written in what ever languages the author likes.
(allmost)
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: 1st CipherText Application prototyped
Date: Thu, 24 May 2001 09:05:10 GMT
CipherText has been prototyped in Visual Basic as an easy-to-use
companion to 'Outlook Express.' The application can be used to send
encrypted messages to virtually any Java-enabled email client, targetting
specifically 'Outlook Express' for its base of potential users.
The CipherText ASCII encryption algorithm is implemented in Visual Basic
to allow the user to compose a message, set a key, encrypt and send the
message. Virtually any 'Outlook Express' user can receive a CipherText
message without requiring ANY special software to decode it on the
receiving end. An HTML delivery template is used with an embedded
Javascript implementation of the CipherText ASCII cipher. The key is
optionally set by the sender so that the recipient needs to change but a
couple of characters and press the Cipher button to decode the message.
This is a very low-cost solution that has potential to become accepted by
all types of computer users to encrypt common email transmissions.
When an installation program is complete, a demonstration copy will be
available for testing on the Windows platform. The prototype application
may be lacking some desireable features, but it is functional for the
specific purpose of encrypting common email messages.
-Charles Prichard
www.greentv.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 24 May 2001 11:26:07 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > Would you please explain a bit on the meaning of 'stream
> > ciphers that are not of the key-generator class'?
>
> Basically, there is no subsystem that generates a
> plaintext-independent key which is then combined
> with the plaintext in a totally separate subsystem.
>
> Note that when I phrase it that way, it is evident
> what some weaknesses might be in key-generator
> based systems.
I suppose you would consider a PRNG which uses some
feedback from the encryption processing to dynamically
influence its state (alter its normal state transitions)
a key generator of your said class. Are there other
typical/interesting characteristics of operations of
systems of your category that could be specially mentioned?
I think that basically you are favouring a good well-
coupled combination (unification/synergy) of stream and
block processing techniques (in the common terminology).
could I be right in that? Thanks.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 24 May 2001 10:26:33 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <psZO6.19345$[EMAIL PROTECTED]>:
>
> >Well most people don't reply to ya because you are in their killfiles.
> >I am trying to be nice by saying "dude prove your stuff". You chose not
> >to. Perhaps I should populate my killfile.
> >
>
> Well you use to be in my kill file so two can play this game.
>
> >> >> And you never anwsered the FACT that a one byte ouput file
> >> >> from CTR mode (though you have no working program) would imediately
> >> >> lead an attacker to realize that the input file could only have
> >> >> come from 1 of 256 possible messages. With BICOM you have many
> >> >> many more messages. That alone makes it more secure. Or do
> >> >> you have the ability to even understand this fact. Both methods
> >> >> use RIJNDEAL as the underlying model. One just does it in
> >> >> a better way. As I pointed out above. I would rather confuse the
> >> >> enemy with many possible messages than just 256 messages.
> >> >>
> >> >
> >> >That's entire BS. If the plaintext is uniformly distributed then CTR
> >>
> >> Well I see you can't anwser the above want to try again.
> >
> >What the F#CK are you yacking about? a 8-bit message can only map to
> >8-bit outputs to be bijective (well not entirely). CTR mode is just a
> >bloody xor of some random bits against a message. How can that possibly
> >be less secure than BICOM?
> >
> >Want me to write a program that uses the CTR mode?
>
> Only if your willing to look at what BICOM does. You
> seem to only habd wave. You have never looked at it or
> tested it.
> Yes CTR being less secure can only map one BYTE to one
> BYTE. But bijective BICOM is not that weak. Why would
> anybody want a one byte file to map to one byte when
> it would means there are only 256 possiblilites for input
> messages.
Because if you knew anything about information theory that's all you need.
Here's an OTP encrypted message.
C = 1
What is the plaintext? You will never know. P is either 1 or 0, but you
can't tell.
> If you encrypt one byte with BICOM you most likely will
> get several bytes out. However if you did get one byte
> out the input file could be far more than one byte. This
> is beacuse if the key is not known many many thousands of
> different possible input files could have mapped to that
> single one byte output file.
Ok bud, there is more to the world than "encryption". BICOM as I pointed
out earlier is vastly inefficient as compared to CTR modes and as you have
failed to point out not any more secure.
Besides BICOM can't be a "bijection" if one input maps to several bytes.
Let's say a 1 byte file maps to 3 bytes. Now to be fully bijective you must
map all 3 byte files to 1 byte. However that's not an invertable function.
So basically you do 1=>3 but out of the 2^24 possible 3 byte files only 2^8
of them occur.
Seriously though, do you not realize how badly you behave? It's hard to
maintain a conversation with you when all you to is belittle and hand wave.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Combining functions for stream ciphers
Date: Thu, 24 May 2001 10:30:55 GMT
"Laura" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I am currently working on improving the ORYX stream cipher, but am
> wondering how to adjust the combining function. I want to make it
> more complex, but not slow down the encryption process too much. Does
> anyone have any ideas? (Currently, the outputs from the LFSR's are
> combined using modular addition).
Well you could decorrelate the plaintext using the stream. That would be
slower but in theory perfectly secure.
Do this.
1. Clock the ORYX system to get a byte. If it's zero get another. Call
this A
2. Clock ORYX to get another byte and call this B
3. Take your plaintext byte P and do C = AP + B
The "C = AP + B" will be done in GF(2^8)/p(x) where p(x) is some irreducible
polynomial. (+ is xor btw)
This system is weak against known/chosen plaintext attacks though (hint P=0
will kill it)
You can re-write it as
C = A(B + P)
To avoid that attack since now P=0 will not give you a multiplicand of zero.
With P=0 you will get AB which would be hard to split.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 24 May 2001 10:33:53 GMT
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > Thanks. I think I should work more on my "Tack" (is that how you
> > spell it?) than my Analysis skills.. heheheh
>
> Your name came up in a conversation at FSE 2001 this year, and people
> thought it likely that, if you worked on your tact and attitude as
> well as your analysis skills, we'd see you at a future such
> conference.
Really? Neat. I appreciate the comments :-)
I shall endeavour to work on my tact and analysis skills. I am getting alot
better at attacking Feistels at least. SPN's are a bit new to me.
> Today's reading, thus, is Bruce Schneier's "Self-Study Course in Block
> Cipher Cryptanalysis" and Dale Carnegie's "How to Win Friends and
> Influence People" ;-)
Not a bad idea actually. I will print off a copy and try to work on them
during my slow classes at school.
If I actually analyze one of the "variants" Schneier suggests would anyone
here care to review the analysis?
Tom
------------------------------
Subject: Message for Alexis Machado
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Thu, 24 May 2001 11:09:34 GMT
Alexis, I got your mail, but your mail provider is *seriously* broken;
the DNS for the brfree.com.br is very bad, and my attempt to send mail
to the one administrator whose address is outside that domain bounced
further down the line. More details on request.
But I was interested in your paper and would like to respond; if you
have another email address that's nothing to do with the broken
brfree.com.br domain, please announce it here so I can mail you.
Thanks.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
** 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
******************************
