Cryptography-Digest Digest #948, Volume #12 Wed, 18 Oct 00 04:13:00 EDT
Contents:
Re: Storing an Integer on a stream ("David Thompson")
Re: SALT + stream cipher ("Joseph Ashwood")
Re: useful literature? ("John A. Malley")
CHAP security hole question ([EMAIL PROTECTED])
Re: DNA encoding ("John A. Malley")
Re: Pegwit group started to make a alternative to PGP based on ECC (Frank M. Siegert)
Re: Pegwit group started to make a alternative to PGP based on ECC ("Benny Nissen")
Re: DNA encoding ([EMAIL PROTECTED])
Re: Stolen Enigma Machine Recovered (David Hopwood)
How insecure is this... ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Date: Wed, 18 Oct 2000 04:05:51 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote :
> If I'm writing a file, whose format is a 64 bit file length, followed by
> some amount of data, followed by some [random] padding, which of the
> following is the best way to store that length value:
>
> 1) 8 base-256 digits. With this format, we always use 8 bytes.
> 2) Some number of base-255 digits, with leading 0 digits stripped,
> terminated by the value 255. With this format, we always use at least 1
> byte (for a value of 0, which is written as just the terminator (255)),
> but generally use 2..9 bytes.
> 3) Some number of base-128 digits, with leading 0 digits stripped, all
> but the last prefixed by a 0 bit, and the last prefixed by a 1 bit.
> With this format, values 0..127 use 1 byte, 128..(128**2-1) uses 2
> bytes, etc, with 9 bytes being used for a 63 bit value, and 10 bytes
> used for a 64 bit value.
...
> By the way, I think I should mention that in the perl programming
> language, the builtin functions pack() and unpack() have a template type
> for method 2, which (If I recall correctly) uses the letter 'w' and is
> refered to as Berweiss-encoding of an integer.
>
perl pack/unpack 'w' is base-128+more, like your method *3*,
but you have the high bit wrong; it is 1 for all bytes but the last.
This is the nominal encoding for extended tags and OIDs
used in BER, the Basic Encoding Rules for ASN.1, the
Abstract Syntax Notation first defined by CCITT/ITU-T
and spread via remote operation to Internet management
(SNMP/MIBs/DMOs) and by X.509 (certs and CRLs)
and PKCS to SSL/TLS, S/MIME, and PKIX (but not PGP).
(Actually certificates, and other signed data, use a subset
called DER, the Distinguished Encoding Rules, because
a signature must reliably be analyzed by the verifier
against exactly the same data as by the signer.)
I have no idea where "weiss" came into this.
Personally I kind of like method 2 just because I've never seen
any good use for base-255 and it would be fun to have one.
It is the most space-efficient of your (byte-oriented) choices
for values likely to be of interest (up to maybe 2**50), though
"wasting" 2 bytes per file is hardly worth worrying about.
The consensus view is that if you are using an encryption algorithm
for which known plaintext is a problem, you need a better algorithm
anyway. Even if you eliminate the (fixed) zeros of method 1,
unless you use *large* amounts of padding (or cover traffic),
an eavesdropper will be able to make a pretty fair guess of
the size of your file and thus the encoding of its length.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Date: Tue, 17 Oct 2000 15:11:48 -0700
> A decrease in entropy can occur in an hashing algorithm? Is this true,
> can you present a logical argument for this?
I certainly can, here goes:
A hash algorithm maps from {0,1}**n to {0,1}**k for some fixed k and
arbitrary n
set n <- k+1
There must exist 2 input values of length n that produce the same output
value
The difference between these 2 values is lost, therefore entropy was lost.
The point at which this happens depends on the input and the hash function
itself.
Joe
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: useful literature?
Date: Tue, 17 Oct 2000 22:24:21 -0700
Florian Peterl wrote:
>
> Hello Guys,
>
> has anybody any recommendation concerning literature in cryptography?
> I'm not a rookie but I'm not a professional in that subject.
> Thanks for your help
Might I suggest
"Cryptography, Theory and Practice" by Douglas R. Stinson,
"Decrypted Secrets, Methods and Maxims of Cryptology" by F.L. Bauer,
"Cryptanalysis, A Study of Ciphers and Their Solution" by Helen Fouche
Gaines,
"Applied Cryptography, Protocols Algorithms and Source Code in C" by
Bruce Schneier,
and either "Military Cryptanalysis Parts I, II, III and IV" by
William F. Friedman
or
"Military Cryptanalytics, Part I, Vol. 1 and 2, and Part II, Vol. 1 and
2 " by William F. Friedman and L.D. Callimahos
as good crypto-knowledge base building blocks. Any of these books are
available from Barnes and Noble (bn.com) or Amazon.com.
Aegean Park Press has its own web site at http://www.aegeanparkpress.com
I recently picked up "Making, Breaking Codes, an Introduction to
Cryptology" by Paul Garrett, prompted by its reviews in this group.
Haven't finished it yet but I do see it eventually making the "core
must-have books list" for us cryptological amateurs.
"The Handbook of Applied Cryptography" is a must-have reference, best
consulted as you work with these other books, and generously made
available by its authors at http://cacr.math.uwaterloo.ca/hac/
(A suggestion for the USENET group - maybe we should add some of these
books to the sci.crypt FAQ in it's next update? )
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: CHAP security hole question
Date: Wed, 18 Oct 2000 05:20:00 GMT
Hi,
I am new to this group. So let me know if my question is not
appropriate for here.
My question is on CHAP, the Challenge Handshake Authentication Protocol.
I have found papers on the Net that publishes crpto weakness in MS
implementation of CHAP that is based on hashed password. And there
seems to be a freely available software based on data dictionary attack
to explore the security hole in MS implementation. So my question is:
Is this weakness general to CHAP itself, to just to MS implementation of
CHAP? And is there other similar authentication or security protocol
that provides better protection against attack than CHAP does?
Thanks in advance for your info.
c6ap
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: DNA encoding
Date: Tue, 17 Oct 2000 22:55:47 -0700
[EMAIL PROTECTED] wrote:
[snip]
> I'm not convinced that a brute-force approach with all primer
> sets is the the only way to find the message, but the alternatives
> I can think of are also slow, if not as slow.
>
I'd be interested in your thoughts on the alternatives. I had a 'hunch'
about a possible attack based on the number of repeating code blocks
representing each plaintext letter as encoded in the DNA (say four
nucleotides as a code for 4! possible characters in the plaintext.)
With a simple substitution cipher, the frequency of occurrence of each
four nucleotide subsequence will match the frequency of occurrence of
its corresponding symbol in the plaintext. Depending on the assignment
of 4 nucleotide sequences to plaintext symbol, it's possible the most
common sequence will find copies of its compliment sequence in the same
strand of DNA and bind to that region, forming a loop. (That is, we
denature the DNA and then try to get the single strands to bind to
complementary regions on the same strand. Is this even possible? Are
there significant yields?)
I have a hunch that the average number of self-loops forming in
ciphertext strands will be significantly different than the number of
self-loops in random nucleotide strands (this needs to be determined by
analysis) The loops change the effective cross-section of the DNA
strand when it's forced to migrate across an electrical field during gel
electrophoresis. So, I would take the jumble of message and nonmessage
strands, try to get them to self-loop, place them into the gel, and then
use the (hopefully present) looping differences to sort them out -
filter the candidate ciphertext messages out from the random strands -
and all of this is done without any hunting for the right promoter
sequences. Take the slow strands, the one with the most loops, and
assess their sequences with other means (say a battery of different
restriction endonucleases.)
Now should it prove impossible to get the DNA strands to self-bind, the
next best thing is to transcribe all of the DNA strands to messenger RNA
and see if the mRNA strands will self-bind or loop more readily (it's a
normal behavior for RNA-based enzymes like transfer-RNA and ribosomes,
for example.) Same attack, but now with mRNA strands looping and then
separated out by gel electrophoresis.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: Pegwit group started to make a alternative to PGP based on ECC
Date: Wed, 18 Oct 2000 06:09:05 GMT
On 16 Oct 2000 20:45:16 -0700, Paul Rubin <[EMAIL PROTECTED]>
wrote:
>> Beside diversity is good.
>
>Great, let's get rid of counting in decimal. We should use balanced
>ternary instead. Diversity is good.
I see you got my point ;-)
Beside I count sheep always in hexdecimal... comes from the
environment.
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Re: Pegwit group started to make a alternative to PGP based on ECC
Date: Wed, 18 Oct 2000 09:28:43 +0200
Please join the pegwit group and state this again to the group members in
the pegwit area. Not all read this usenet group.
Benny
"Paul Rubin" <[EMAIL PROTECTED]> skrev i en meddelelse
news:[EMAIL PROTECTED]...
> Mike Rosing <[EMAIL PROTECTED]> writes:
> > > Actually, nothing stops you from generating El Gamal (or these days
> > > even RSA) private keys from a passphrase. What's nice about ECC is
> > > that it's reasonably practical to type *public* keys into a program
> > > (example: AF646-BEJTR-BTGAP-7MFPW-GRVYX-RRGQW = 150 bits of info).
> > > This is a central feature of the program I've been wanting to write.
> > >
> > > It'll be cool if Pegwit can do stuff like this.
> >
> > that's the goal. Creating a DLL from it so it's a portable
> > package is also a goal. We'll get there one step at a time,
> > but the more people, the more steps we can take at once :-)
>
> OK. I don't have much interest in a DLL but want to make a Java
> applet that can be put onto web pages to encrypt the contents of web
> forms, for use in a webmail application. I looked at the old Pegwit
> for this but it seemed too bloated, and as I remember the choice of
> curve was weak.
>
> I'd like to propose that the new Pegwit give up on characteristic 2
> and use a curve over GF(p) for some p of about 160 or maybe 165 bits.
> That allows writing public keys in the format
>
> 2BJAH-7UKPQ-XXPP5-FBZXT-5W975-HEB62-Q4LAU
>
> which holds 175 bits, allowing specifying a curve point with a few
> bits left over for a checksum or some other annotation. (The encoding
> holds 5 bits per character because it uses the letters and digits
> excluding I, O, 1, and 0, to avoid typographic confusion).
> Implementing GF(p) EC arithmetic using calls to a bignum library
> should be much simpler than the GF(2) implementation in the old Pegwit
> code, and it probably runs faster in Java than the GF(2) stuff,
> because it can use the native java.math.BigInteger class instead of
> doing all that bit-twiddling in interpreted code. I'm not sure how a
> speed comparison between fully native implementations would work out,
> but I think raw EC speed should not be a primary goal for Pegwit.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DNA encoding
Date: Wed, 18 Oct 2000 07:15:31 GMT
In article <[EMAIL PROTECTED]>,
"John A. Malley" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> [snip]
>
>> I'm not convinced that a brute-force approach with all primer
>> sets is the the only way to find the message, but the alternatives
>> I can think of are also slow, if not as slow.
>
> I'd be interested in your thoughts on the alternatives. I had a
'hunch'
> about a possible attack based on the number of repeating code blocks
> representing each plaintext letter as encoded in the DNA (say four
> nucleotides as a code for 4! possible characters in the plaintext.)
> With a simple substitution cipher, the frequency of occurrence of each
> four nucleotide subsequence will match the frequency of occurrence of
> its corresponding symbol in the plaintext. Depending on the assignment
> of 4 nucleotide sequences to plaintext symbol, it's possible the most
> common sequence will find copies of its compliment sequence in the
same
> strand of DNA and bind to that region, forming a loop. (That is, we
> denature the DNA and then try to get the single strands to bind to
> complementary regions on the same strand. Is this even possible? Are
> there significant yields?)
There might be a difference, but I don't think, for various other
reasons that it would be useful. DNA forms 'secondary structure'
(the technical term for loops) all the time - it can be quite
hard to avoid.
You can make an easy analogy here to the genetic code. DNA that
encodes protein is already using a 3-bp (64 codons) 'alphabet'
and the amino acids encoded are used at different frequencies,
and although there are differences in the number of codons
coding for each amino acid (there are 20 amino acids from 61
codons, the remaining three are 'stop' codons) these frequencies
don't, in my experience, match particularly closely to the
frequency of use of the amino acids.
And I've never gotten the impression that protein-coding DNA
is more prone to secondary structure than other DNA.
> I have a hunch that the average number of self-loops forming in
> ciphertext strands will be significantly different than the number of
> self-loops in random nucleotide strands (this needs to be determined
by
> analysis) The loops change the effective cross-section of the DNA
> strand when it's forced to migrate across an electrical field during
gel
> electrophoresis. So, I would take the jumble of message and nonmessage
> strands, try to get them to self-loop, place them into the gel, and
then
> use the (hopefully present) looping differences to sort them out -
> filter the candidate ciphertext messages out from the random strands -
> and all of this is done without any hunting for the right promoter
> sequences. Take the slow strands, the one with the most loops, and
> assess their sequences with other means (say a battery of different
> restriction endonucleases.)
The strands will only be slow (if this indeed is the case, I don't
have a strong intuition about this) relative to other strands of
the same length. There's no reason the DNA the message is mixed
with will all have the same length, in fact it's quite hard to
achieve. And to me, it would be a dead giveaway that the DNA
sample was worth investigating further.
I'm assuming if I'm trying to detect the message DNA that the
first thing to do is insert all the DNA into vectors and into
bacteria so we can multiply it up as needed.
(Correction: the very first thing is to run the DNA on a standard
agarose gel on the off chance that the message is a visible band.
It would be careless stupidity or poor lab technique by the
creators, but we might as well check the possibility).
I'd assume in the first round that the message is there in
isolation and not attached to other DNA. So I would sequence
a good number of the vectors and try to identify the source
of the DNA mixed in with the message - for example, it might
be human DNA. (For economic reasons it would be prohibitive
to synthesise enough different random strands of DNA as background,
it would make more sense to use a biological source). I'd
do hybridisation with what appeared to be the background DNA
to remove as many vectors from consideration as possible and
have a look at the reduced population.
Another approach (once everyone goes to the effort of inserting
their message into pieces of the DNA they will be using for
background - this won't affect PCR in the slightest) is based
on the fact that you can't afford to put just one copy of the
message in (in fact, it's not physically possible -
you're dealing with stochastic effects at such low dilutions).
By doing some hybridisation of vectors against each other, you
should quickly get an idea of how much of the DNA is single-
copy (it can be safely ignored) and how much is in multiple
copies and how many classes there are. The person could
have mixed their message with DNA that only belonged to one
class (for example a purified vector) but that would make it
very easy to identify the minority of vectors that contain DNA
different from all the rest. Clearly there is a trade-off in
creating a background mixture of DNA that makes it harder to
find the message.
If I knew the substitution code used for the message, I'd
check each vectors' profile on a microarray (DNA chip). The message
might not be pinpointed but as long as it reduced the number of
vectors I had to sequence, it would help. Microarrays are still
somewhat expensive technology but I doubt they will be long.
And in the end, brute force sequencing of all vectors would be
more effective than brute force PCR for all primers. There'd be
about 4^40 primer pairs to test and it's unlikely I'd need to
sequence that many vectors before I found a copy of the message.
And even with the brute force PCR, I'd still have to do a lot
of sequencing because many of the other primer pairs would also
amplify something. The brute force PCR approach strikes me as
about the dumbest way to find the message.
Ingrid
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 18 Oct 2000 05:58:12 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Stolen Enigma Machine Recovered
=====BEGIN PGP SIGNED MESSAGE=====
Jim wrote:
> The Enigma cipher machine which was stolen from the museum
> at Bletchley Park has turned up.
>
> It was sent by post to the television 'personality'
> Jeremy Paxman.
... but without the reflector and 3 of the 4 rotors [*].
Curiouser and curiouser.
Apparently the parcel had sat in the Newsnight offices for about a week
(IIRC) before being opened.
[*] which for some reason were called "coding wheels" by Christine Large
(head of BP), and Paxman.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOezT7zkCAxeYt5gVAQGfAgf/Q1X0SsFej7EcRcsVqcftLv9eAEH/4wUK
Y0i8peQVvt1fTC59c19kMYzOTwbPegPLGTY3PEY1XIBzDH7K420EdgsoFuSeLAYa
DeyR36cR/3bj2UwJS7WYxHbsJp5stkBdKiQwAbi5cKcogOshyLM7o5+GxRdz1c5C
ElLPhfsstHYJ3YOp+yoibkxtbhQD4mNTqsm8x5g1szbiXoipkEKaz0Kdlg8xjl2L
hl7xb9bJ9Oy9Wjyt4kqbpwi9tIzGTXSWxO04cl15sxfZTsTfBAw2bgwaakPKCf+y
K6Sqwa7e+BWZfKus9N+LyD15vVgH0vsgt9T7zPiUk7otYx613I2CQA==
=YwKK
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: How insecure is this...
Date: Wed, 18 Oct 2000 07:53:13 GMT
There is no doubt that when using a symetric cipher, one should not use
the standard ECB-mode, but something more elegant like CBC. And when
using the CBC-mode, one should consider how to generate proper IV's.
Now, just assume that I use the CBC-mode, but with a constant IV for
the first block being encrypted. As a result, the ciphertexts of two
plaintexts are identical up to the point where the plaintexts differ
from each other.
Assume that I use a 128bit cipher like Rijndael. Further assume that a
potential attacker is not able to do a chosen-plaintext-attack, all he
has is the encrypted material.
What else can the attacker do with that? What else can account for the
insecurity of this implementation?
I would appreciate your comments.
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
******************************
