Cryptography-Digest Digest #354, Volume #11 Fri, 17 Mar 00 15:13:01 EST
Contents:
Re: Cipher Contest (Mike Rosing)
Re: Enigma encryption updated (Adam D) (Nemo psj)
Re: 64-bit Permutations ([EMAIL PROTECTED])
Re: 64-bit Permutations (Mike Rosing)
Re: The Breaking of Cyber Patrol� 4 (John Savard)
Re: 64-bit Permutations ([EMAIL PROTECTED])
Cipher Contest ("Adam Durana")
Re: Public timestamping servers (Jorge Davila Muro)
Re: 64-bit Permutations (Stephen Houchen)
Re: Encryption of fax ("Scott K. Lindsay, P.Eng.")
Re: Encryption of fax (Tony L. Svanstrom)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Cipher Contest
Date: Fri, 17 Mar 2000 12:11:20 -0600
Adam Durana wrote:
> I like the idea of a continual contest. Maybe we could have no submission
> deadline and just add ciphers to the "contest" as people submit them. And
> once an attack was discovered on a cipher it would be removed from the
> contest and the author could have the option to revise the cipher to fix
> whatever attacks were found. We could have ciphers ranked by how long they
> have been in the contest without being broken. If we did it this way I see
> no reason why entries in any category could not have different block sizes
> since the ranking would be decided totally by the security of the cipher.
> Would we even need categories then? The only problem I see is when the
> better ciphers find their way to the top and stay there for a long time
> people will become discouraged and loose interest. Maybe we could retire a
> cipher after it has spent X weeks at the top of the list.
How about bumping things up to new catagories based on the total number
of attacks? For example, if a beginner cipher hasn't been broken by 3
or
4 methods, it could be bumped up to intermediate and pounded on by
more advanced attacks. It'd still be a "beginner" cipher since it's
only
64 wide, but that's ok.
If a cipher has been subjected to every known possible kind of attack
and
survives, it should be honored and removed from the contest. Sort of a
"cipher hall of fame" maybe? That would give some motivation to
continue,
and as new types of attacks are developed, the hall of fame might be
reviewed.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Enigma encryption updated (Adam D)
Date: 17 Mar 2000 18:12:36 GMT
On another note what part of the algy did I not describe in the doc? I
described everything incuding how it encrypts the text. (not just the password)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 64-bit Permutations
Date: Fri, 17 Mar 2000 18:19:56 GMT
> Imagine a cipher where you took plaintext in 64-bit blocks.
> The bits in each block are simply permuted in the same
> fashion for each block. The key, then would be the bit-
> mapping.
> My gut feeling is that this is so simple that it's probably not
> very hard to break.
>
> So cryptanalysts, how would you break it?
There are some ways to break this cipher that is indeed weak (but
it's a simple and efficient idea for systems requiring some security).
For chosen plaintext, I would only need 8*63 bytes to get the key
with ease (but I alredy figured other ways to reduce this number), each
64-bit block with just 1 different bit set and the last one could be
deduced.
I see no difficulty also with known plaintext. The mapping would
become apparent with some words.
With ciphertext only, things would become more complicated, but not
too much with a good amount of ciphertext.
I would get hints from the blocks with the most bits that are SET
and the blocks with the most bits RESET. I would then try to list all
the possibilities of sequence of characters that could have that
quantity of bits set in the plaintext and see how much could prove to
be meaningful (I know that we could have part of words here, but some
digraphs and trigraphs aren't simply allowed). This is a weakness of
the algorithm, that garantees that I would no change the quantity of
bits SET/RESET in 8 bytes block. This probably would not solve the
problem, but should give a hint in a common plaintext.
Other trick I could get is making a statistic of the "most/least
common bit" in english language, that is, given a plaintext written in
ASCII, what bit will be the most and least common in the binary level?
For example: in ascii with all letters capital, the bit 7 is always 0.
Almost ALWAYS there would be the same 8 blank bits (representing the
bit 7 of the 8 characters in the block) in the word.
Getting information in the bit distribution of the ASCII plaintext
is the key for the solution. When I get good hints for the probable bit
permutations, I would start analysing some by hand and with pattern
matching software.
Daniel.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: 64-bit Permutations
Date: Fri, 17 Mar 2000 12:34:58 -0600
Stephen Houchen wrote:
>
> Imagine a cipher where you took plaintext in 64-bit blocks.
> The bits in each block are simply permuted in the same
> fashion for each block. The key, then would be the bit-
> mapping.
>
> My gut feeling is that this is so simple that it's probably not
> very hard to break.
>
> So cryptanalysts, how would you break it?
Start with a crib: a set of plaintext-ciphertext pairs. 32 pairs
should be more than enough to recover the key. You'll have
an average of 1 bit set and 1 bit clear in each plaintext position
and you can compare that to the ciphertexts. With 64 pairs you
could just write out a system of 64 equations and just solve the
inverse matrix to get the key.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Breaking of Cyber Patrol� 4
Date: Fri, 17 Mar 2000 11:45:47 GMT
"seifried" <[EMAIL PROTECTED]> wrote, in part:
>"Microsystems also asked the judge to order the Swedish Internet company
>where the bypass utility is published to turn over records identifying
>everyone who visited the Web site or downloaded the program."
Had they asked that of a judge in a Swedish court, promptly erasing
these records would constitute contempt. Asking a judge in a U.S.
court to issue such an order, however, is something of a waste of
time. Although Sweden is a signatory to international copyright law
treaties, the world we live in isn't quite _that_ borderless just yet.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 64-bit Permutations
Date: 17 Mar 2000 18:32:45 GMT
I hope you do realize that the look up table for such a permutation would
have a size of 137438953472 giga byte.
In a previous article, Stephen Houchen <[EMAIL PROTECTED]> writes:
>Imagine a cipher where you took plaintext in 64-bit blocks.
>The bits in each block are simply permuted in the same
>fashion for each block. The key, then would be the bit-
>mapping.
>
>My gut feeling is that this is so simple that it's probably not
>very hard to break.
>
>So cryptanalysts, how would you break it?
>
>S
>[EMAIL PROTECTED]
>
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Cipher Contest
Date: Fri, 17 Mar 2000 13:53:29 -0500
Hello,
We've been talking about this contest for a while now. And I think we came
up with a good idea. There will be no fixed deadline for submissions or end
of the contest. Instead it will be a continual thing. Everyone submits
ciphers as they get them done, the ciphers are listed on a web site ranked
by how long they have been in the listing. When a problem arises with any
entry it will be removed from the listing and the author will have the
option to fix the problem and resubmit the cipher. A resubmitted cipher
will be added to the bottom of the list. When a cipher has spent a set
amount of time at the top of the list it will be retired and moved to a
"hall of fame" sort of listing. As new attacks are discovered and old ones
are improved, if any cipher listed on in the hall of fame can be broken it
will be removed and moved back to the original list, if the author fixes the
problem.
I still think we need to have limits on the ciphers, but they can be more
loose. We could have a maximum block size and a maximum key size. Maybe
512 bits for the maximum block size and 256 bits for the maximum key size?
We might also need a minimum block size to keep people from submitting
stream ciphers. We could have another such listing for stream ciphers, but
we can worry about that later. Also we would need some sort of speed or
maximum rounds requirement, so people could not submit ciphers with 1024
rounds. Maybe we could set the maximum rounds to 16? Or should there be a
speed requirement? I think a speed requirement would be much more difficult
to decide on, so I say there should be a maximum rounds requirement.
If no one objects to any of this, these will be the rules and the contest
will start.
Right now I see the rules being
- Block cipher, block size between 32 and 512 bits. Key size between 0 and
256 bits.
- Number of rounds between 1 and 16.
- Resistant to all known attacks.
- Reasonable resource requirements.
The "reasonable resource requirements" is needed so people can't submit
ciphers that use huge amounts of memory, disk etc. I think it would be
unfair to allow people to submit ciphers were the resource requirements are
unreasonable. This will have to be done on a case to case basis unless we
want to set a maximum memory requirement.
- Adam
------------------------------
From: Jorge Davila Muro <[EMAIL PROTECTED]>
Subject: Re: Public timestamping servers
Date: Fri, 17 Mar 2000 20:04:14 +0100
This is a multi-part message in MIME format.
==============73415601BB87349E0959B585
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Logi Ragnarsson wrote:
> I have written a simple time stamping server which returns the usual signed
> timestamp of a short string you supply (should be a hash normally) and with
> some features to allow third-party authentication of the logs.
>
> Are there already servers like this on the 'net? Is this something that is
> worth actually putting up?
look here: http://tictac.fi.upm.es/ Does your server do the same? Where
it's located your server?
Cheers,
- Jorge D�vila -
==============73415601BB87349E0959B585
Content-Type: text/x-vcard; charset=us-ascii;
name="jdavila.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jorge Davila Muro
Content-Disposition: attachment;
filename="jdavila.vcf"
begin:vcard
n:Davila Muro;Jorge
tel;fax:34 91 336 69 42
tel;work:LSIIS - Facultad de Inform�tica - UPM
x-mozilla-html:TRUE
url:tirnanog.ls.fi.upm.es
org:Universidad Polit�cnica de Madrid;LSIIS - Facultad de Inform�tica
adr:;;Campus de Montegancedo s/n;Madrid;Madrid;28660;Espa�a
version:2.1
email;internet:[EMAIL PROTECTED]
title:Profesor Titular
fn:Jorge D�vila
end:vcard
==============73415601BB87349E0959B585==
------------------------------
From: Stephen Houchen <[EMAIL PROTECTED]>
Subject: Re: 64-bit Permutations
Date: Fri, 17 Mar 2000 13:10:52 -0600
What lookup table? The simplest (implementation-wise) key
could be 64 6-bit fields. The first field specifies which plaintext
bit goes in the first ciphertext bit, etc...
You could tighten the key to log2 (64!) = 297 bits, but I guess
that's irrelevant since it sounds sort of easy to break anyway.
S
[EMAIL PROTECTED]
> I hope you do realize that the look up table for such a permutation would
> have a size of 137438953472 giga byte.
>
> >Imagine a cipher where you took plaintext in 64-bit blocks.
> >The bits in each block are simply permuted in the same
> >fashion for each block. The key, then would be the bit-
> >mapping.
> >
> >My gut feeling is that this is so simple that it's probably not
> >very hard to break.
> >
> >So cryptanalysts, how would you break it?
>
------------------------------
From: "Scott K. Lindsay, P.Eng." <[EMAIL PROTECTED]>
Subject: Re: Encryption of fax
Date: Fri, 17 Mar 2000 14:54:53 -0500
Reply-To: [EMAIL PROTECTED]
This is a multi-part message in MIME format.
==============6FED29FF5B43BCBC51754DC9
Content-Type: multipart/alternative;
boundary="------------7B50FEDA9A0AD6E1A7E7DB62"
==============7B50FEDA9A0AD6E1A7E7DB62
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alex Chartier wrote:
> My company is in the fax encryption business so take that into consideration
> when reading my answers..
>
> To reply please remove no_spam_ from address.
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > 1. Are there specific features ('structure' etc.) of fax that could
> > lead to (practically significant) advantages of the opponent,
> > when fax is encrypted (as compared to pure common ASCII texts)?
>
> As mentioned by a previous poster, the volume of information in a
> transmitted fax is significantly higher than that in an e-mail message. The
> data on the page is rasterized and then sent as bits, and in general only
> the dark bits are sent.
Actually, no. It sends alternating codes for dark and white spaces, i.e. a
dark code is (more or less) always followed by a white code. The codes
represent the number of pixels of either dark or light. Unless you're doing
compression. That works by sending differences between the current line
and the previous line. I think that half of the lines are sent as normal and
half are sent as difference lines.
> All fax machines will add some padding to the lines,
> some more than others (one example is winfax versus msfax, msfax sent a
> blank page in 4K bytes while Winfax sent 40KB). This tends to help 'hide"
> the data.
>
> The protocol however for fax transmissions is well documented and easily
> intercepted. Part of the protocol even identifies the type of fax machine at
> either end. Most encryption products only encrypt the payload and not the
> protocol headers so much information can be obtained even if the source
> document is hidden. This is why we set up a data connection between each
> unit and tunnel both the protocol and payload.
> >
> > 2. If a message is handwritten and faxed, does it have advantages
> > or disadvantages compared to e-mailing the same message in
> > respect of security resulting from using the same encryption
> > algorithm (i.e. we neglect issues of transmission cost, etc.)?
>
> No comments on this one. A fax treats a handwritten document no different to
> a typed document.
> >
> > Many thanks in advance.
> >
> Hope this helped somewhat.
> > M. K. Shen
--
Scott K. Lindsay, P.Eng.
Wireless System Technologies
[EMAIL PROTECTED]
===========================IMPORTANT NOTICE===========================
This message, and its attachments if any, is intended only for the
use of the individual or entity to which it is addressed, and contains
information that is Valuable, Proprietary and Confidential to Wireless
System Technologies. If the reader of this message is not the intended
recipient, or an employee or agent authorized and responsible for
delivering the message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please immediately notify Wireless System Technologies either by telephone
at (416)-977-1414 or (415)-543-4255 or by email at [EMAIL PROTECTED]
and delete all copies of this message after doing so. Thank you.
==============7B50FEDA9A0AD6E1A7E7DB62
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Alex Chartier wrote:
<blockquote TYPE=CITE>My company is in the fax encryption business so take
that into consideration
<br>when reading my answers..
<p>To reply please remove no_spam_ from address.
<br>"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
<br><a
href="news:[EMAIL PROTECTED]">news:[EMAIL PROTECTED]</a>...
<br>> 1. Are there specific features ('structure' etc.) of fax that could
<br>> lead to (practically significant) advantages of
the opponent,
<br>> when fax is encrypted (as compared to pure common
ASCII texts)?
<p>As mentioned by a previous poster, the volume of information in a
<br>transmitted fax is significantly higher than that in an e-mail message.
The
<br>data on the page is rasterized and then sent as bits, and in general
only
<br>the dark bits are sent.</blockquote>
Actually, no. It sends alternating codes for dark and white spaces, i.e.
a
<br>dark code is (more or less) always followed by a white code. The codes
<br>represent the number of pixels of either dark or light. Unless you're
doing
<br>compression. That works by sending differences between the current
line
<br>and the previous line. I think that half of the lines are sent as normal
and
<br>half are sent as difference lines.
<blockquote TYPE=CITE>All fax machines will add some padding to the lines,
<br>some more than others (one example is winfax versus msfax, msfax sent
a
<br>blank page in 4K bytes while Winfax sent 40KB). This tends to help
'hide"
<br>the data.
<p>The protocol however for fax transmissions is well documented and easily
<br>intercepted. Part of the protocol even identifies the type of fax machine
at
<br>either end. Most encryption products only encrypt the payload and not
the
<br>protocol headers so much information can be obtained even if the source
<br>document is hidden. This is why we set up a data connection between
each
<br>unit and tunnel both the protocol and payload.
<br>>
<br>> 2. If a message is handwritten and faxed, does it have advantages
<br>> or disadvantages compared to e-mailing the same
message in
<br>> respect of security resulting from using the same
encryption
<br>> algorithm (i.e. we neglect issues of transmission
cost, etc.)?
<p>No comments on this one. A fax treats a handwritten document no different
to
<br>a typed document.
<br>>
<br>> Many thanks in advance.
<br>>
<br>Hope this helped somewhat.
<br>> M. K. Shen</blockquote>
<pre>--
Scott K. Lindsay, P.Eng.
Wireless System Technologies
[EMAIL PROTECTED]
===========================IMPORTANT NOTICE===========================
This message, and its attachments if any, is intended only for the
use of the individual or entity to which it is addressed, and contains
information that is Valuable, Proprietary and Confidential to Wireless
System Technologies. If the reader of this message is not the intended
recipient, or an employee or agent authorized and responsible for
delivering the message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please immediately notify Wireless System Technologies either by telephone
at (416)-977-1414 or (415)-543-4255 or by email at [EMAIL PROTECTED]
and delete all copies of this message after doing so. Thank
you.</pre>
</body>
</html>
==============7B50FEDA9A0AD6E1A7E7DB62==
==============6FED29FF5B43BCBC51754DC9
Content-Type: text/x-vcard; charset=us-ascii;
name="sklindsa.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Scott K. Lindsay, P.Eng.
Content-Disposition: attachment;
filename="sklindsa.vcf"
begin:vcard
n:Lindsay;Scott
tel;fax:416 977 1505
tel;work:416 977 1414
x-mozilla-html:FALSE
org:Wireless System Technologies
adr:;;205 Richmond St. West Suite 601;Toronto;Ontario;M5V 1V3;Canada
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Engineer
x-mozilla-cpt:;-16544
fn:Scott Lindsay
end:vcard
==============6FED29FF5B43BCBC51754DC9==
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Re: Encryption of fax
Date: Fri, 17 Mar 2000 21:06:04 +0100
Scott K. Lindsay, P.Eng. <[EMAIL PROTECTED]> wrote:
> Scott K. Lindsay, P.Eng.
> Wireless System Technologies
> [EMAIL PROTECTED]
>
> ---------------------------IMPORTANT NOTICE---------------------------
> This message, and its attachments if any, is intended only for the
> use of the individual or entity to which it is addressed, and contains
> information that is Valuable, Proprietary and Confidential to Wireless
> System Technologies. If the reader of this message is not the intended
> recipient, or an employee or agent authorized and responsible for
> delivering the message to the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please immediately notify Wireless System Technologies either by telephone
> at (416)-977-1414 or (415)-543-4255 or by email at [EMAIL PROTECTED]
> and delete all copies of this message after doing so. Thank you.
That so called signature does NOT belong in newsgroups (this one was
found in sci.crypt)!
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
** 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
******************************
