Cryptography-Digest Digest #646, Volume #13 Wed, 7 Feb 01 00:13:01 EST
Contents:
CBCC ([EMAIL PROTECTED])
Re: CBCC (Tom St Denis)
Re: Phillo's alg is faster than index calculus ([EMAIL PROTECTED])
Re: Phillo's alg is faster than index calculus ([EMAIL PROTECTED])
Re: Encrypting Predictable Files ([EMAIL PROTECTED])
Re: Phillo's alg is faster than index calculus (Tom St Denis)
Re: Phillo's alg is faster than index calculus (Tom St Denis)
Re: CBCC (David Wagner)
Re: Well, it stumped the bikers.... (Jim Gillogly)
Re: Encrypting Predictable Files (Splaat23)
Re: Different cipher type ("Michael Brown")
Re: Encrypting Predictable Files ("Matt Timmermans")
Re: Encrypting Predictable Files ("Matt Timmermans")
Re: On combining permutations and substitutions in encryption ("Matt Timmermans")
RSA prime selection. (Newbie question) ("StuartL")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: CBCC
Date: Wed, 07 Feb 2001 01:58:32 GMT
I'm trying to implement an anonymous network model at
www.eskimo.com/~weidai/pipenet.txt
given N hops in the network, the packet has to grow by some length,
linearly, to hold integtriy info to keep nodes from colluding to
track down a user of the network.
in other words, if one node at the beginning of the route can alter a
packet, and only the last node will be able to see that the packet is
altered, than the last node and the intermediate node can seriously
degrade the anonymity of the user.
anyhow, to defeat this each cycle of encryption (a packet is encrypted
once for every hop) has to provide for integrity so honest nodes can
drop a packet before it reaches the last node.
anyhow, using a one-way hash like SHA1 or MD5 to produce a MAC for each
hop is too burdensome (these are at least 32bytes) and probably too
expensive for streaming these packets in near real-time. I was wondering
if using a combination of a cipher CBCC mode and a CRC32 checksum in the
last block of every packet (per encryption cycle) can provide the
integrity approximating that of using a straight hash value encrypted
along w/ the rest of the packet.
i'm a novice, so feel free to shoot down whatever assumptions i'm making
here.
tia,
bill
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CBCC
Date: Wed, 07 Feb 2001 02:11:37 GMT
In article <95qa46$b6o$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm trying to implement an anonymous network model at
> www.eskimo.com/~weidai/pipenet.txt
>
> given N hops in the network, the packet has to grow by some length,
> linearly, to hold integtriy info to keep nodes from colluding to
> track down a user of the network.
>
> in other words, if one node at the beginning of the route can alter a
> packet, and only the last node will be able to see that the packet is
> altered, than the last node and the intermediate node can seriously
> degrade the anonymity of the user.
Why not do a End to End system? Where the the two users agree on a key and
send it encrypted through all others nodes.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Phillo's alg is faster than index calculus
Date: Wed, 07 Feb 2001 02:14:53 GMT
>
> Why again did you not reply to my post?
>
because... you're full of it too? :)
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Phillo's alg is faster than index calculus
Date: Wed, 07 Feb 2001 02:17:13 GMT
>
> I think you are full of it.
>
> Given
>
> p=C0B3A0B1FFCAB1F8B240F1F0E5AE4AEC2438AC0063C0D228386860CE80124257
> g=3
> x=??? who knows ???
> g^x = 909E7ACDCA5C1E9511E4115DEEBDC33F2683B70D3728405A324962F168A5634A
>
> Ask phili boy to find x using his algorithm. (Values are in hex).
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
>
I charge a lot for solving your puzzle... :)
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypting Predictable Files
Date: Wed, 07 Feb 2001 02:28:33 GMT
In article <95q5ab$76k$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <95q4lc$6mm$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> >
> > Two can play this game. Suppose one has a general file encryption
> > program that works for any file. Take Scott16u or your OTP
> > The amount of possible plaintext texts is 2**(number of bits in
file)
> > encrypt with scott16u or the OTP the resulting output file has
> > the same number of bits and there are no possible encrypted files
> > that could have come from something other then any of the input
> > files. Since they are the same length plain text and encrypted and
> > since there is the same number in each set and there is a 1 to 1
> > relationship between every file in the palin set as encrypted there
> > is no difference in entropy. Something you fail to understnd.
>
> Either Scottu19 is an OTP or this paragraph doesn't make sense. If
the key
> going into Scottu19 is smaller then the message then it's not an OTP
**AND**
> there is not a 1-1 relationship between messages and keys.
>
> Tom
Tom scott19u is not an OTP for long files. Maybe for short file
of a few hundred bytes. But we where talking about weather or not
information was added to a file. But I see where you are taking it.
suppose that the key is only 2 bits long then for any encypted file
you have one of 4 possible input files. Its like kinetic energy of
an object. It kind of depends on ones frame of reference since
observers moving at different velocities are going to get a different
number.
But your correct if I have a 2 bit key then to decrypt there can
only be at most 4 plaintext files that it decrypts to. However if
say we are working with 8 bytes of input file and if if every possible
input file is allowed. No matter which one of the 4 keys I use.
When I encrypt I will get an 8 byte file out. The enropty going in
was 1 per/bit and that is what it is going out. If you use encryption
that adds information to the file it cannot map every binary file with
out gaps. What I mean is that if one exaims the cipher text.
Information must be added in such a way that not every file is possible
the entropy will be less than one per bit. This means that the
NSA or what ever could imediately rule out many possible encryption
methods since they may be able to determine that the file they are
looking at. Could not be the result of encryption method X. THe nice
thing about mine and Matts. Is that any binary file is possible so
it could never be ruled out on an information basis.
dave
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Wed, 07 Feb 2001 02:31:01 GMT
In article <95qb2o$c2t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >
> > Why again did you not reply to my post?
> >
>
> because... you're full of it too? :)
Well solve the system and prove me wrong!
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Wed, 07 Feb 2001 02:30:31 GMT
In article <95qb74$c5s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> >
> > I think you are full of it.
> >
> > Given
> >
> > p=C0B3A0B1FFCAB1F8B240F1F0E5AE4AEC2438AC0063C0D228386860CE80124257
> > g=3
> > x=??? who knows ???
> > g^x = 909E7ACDCA5C1E9511E4115DEEBDC33F2683B70D3728405A324962F168A5634A
> >
> > Ask phili boy to find x using his algorithm. (Values are in hex).
> >
> > Tom
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
> I charge a lot for solving your puzzle... :)
Hey wait, you are trying to show me that your method (or the method your are
advertising) works. Now prove it!
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: CBCC
Date: 7 Feb 2001 02:42:41 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
>I'm trying to implement an anonymous network model at
>www.eskimo.com/~weidai/pipenet.txt
>
>given N hops in the network, the packet has to grow by some length,
You might want to read about how Mixmaster networks deal with this.
A google search should turn up information, or you can refer to
reference 11 of the following paper:
Ian Goldberg, David Wagner, and Eric A. Brewer.
Privacy-enhancing technologies for the Internet. IEEE COMPCON '97.
http://www.cs.berkeley.edu/~daw/papers/privacy-compcon97.ps
As for what mode to use, I strongly recommend against non-cryptographic
checksums like CRC32. Use your favorite mode (CBC, CFB, or OFB are fine)
plus a cryptographic-strength message authentication code, such as
SHA1-HMAC.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Well, it stumped the bikers....
Date: Wed, 07 Feb 2001 02:49:31 +0000
Jim Gillogly wrote:
> As a hint, the key is 6 letters long, as you can determine
> by the index of coincidence or the Kasiski method.
BTW, if you go check out the original posting in uk.rec.motorcycles
you'll find two further cryptograms, each more challenging. The
third is doubly encrypted with two different keywords, and it's a
worthwhile exercise.
--
Jim Gillogly
Mersday, 17 Solmath S.R. 2001, 02:47
12.19.7.17.3, 9 Akbal 6 Pax, First Lord of Night
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Wed, 07 Feb 2001 02:59:13 GMT
Umm, I do recall saying that inserting the length of the file on the
plaintext would solve the problem. Or using an escape code to signal
the end of the message. Or sending the length in the clear. Or any
number of other options.
Reading thr rest of this thread, I see that I misunderstood the
original topic. However, I'm not sure I see the usefulness of having a
completely bijective file encryption process (as opposed to just the
block cipher component, which is required for all).
- Andrew
In article <95o146$aei$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <95nhq3$tj3$[EMAIL PROTECTED]>,
> Splaat23 <[EMAIL PROTECTED]> wrote:
> > Well, I tried it again, and recorded the results. The results
follow:
> >
> > >>> import rc6
> > >>> k = rc6.new(12345678912034L)
> > >>> m = "Hello, worl"
> > >>> len(m)
> > 11
> > >>> c = k.decryptecb(m)
> > >>> c
> > '\006S\033\010#\037\242\202\227\327\3452E\304\011\361'
> > >>> k.encryptecb(c)
> > 'Hello, worl\000\000\000\000\000'
> > >>> m = "The seems to work correctly, even with messages that are
not
> > multiples of the cipher block!"
>
> Actaully you are missing somethiing the orignal file had
> 11 characters. The final file had 5 extra zeros so the file
> changed. I suspect the method "added trailing zeros" at the
> start a common technique. But it may mean that you can't
> distinguish btween a "hello worl\000" or "hello worl" as
> the original file. Its a minor detail. But its the minor
> detail that breaks encryption.
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Different cipher type
Date: Wed, 7 Feb 2001 17:02:02 +1300
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It's not favored simply because you don't know that there aren't weak
> keys. Some keys are secure, some aren't.
With simple operarions such as XOR, I would have thought a filter could have
been written that would test a key for secureness. For example, XOR with
prev 5 bytes followed by Xor with prev 5 bytes obviously would not help
much.
But still, unless this is known, the attacker still has to test just as many
keys to actually determine the key.
>
> Also, there is the possibility of timing attacks, if the different
> operations take different amounts of time.
Good point, but wouldn't this only apply to streaming (as in real time)
encryption? And the latencies on the net these days would surely help here
:)
>
> --
> A solution in hand is worth two in the book.
> Who cares about birds and bushes?
--
Code snippit 1 : Fibbonachi fill
Stats:
In : esi = destination address, ecx = number of numbers / 2
Out : esi,eax,ebx,ecx destroyed. [esi] = 1,2,3,5,8...
Time: 2.5 clocks per Fibbonachi number + 1 clock initialisation
Code (replace ";" with newline):
mov eax,1;mov ebx,1;L1:mov [esi],eax;add ebx,eax;add esi,4;
mov [esi],ebx;add eax,ebx;add esi,4;dec ecx;jnz L1
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Wed, 07 Feb 2001 03:52:14 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:ukDzy$IkAHA.278@cpmsnbbsa07...
> Now on to the other statement I addressed before
> Earlier claims by DS in this thread:
> Matt Timmermanns Rijndael implementation does not add information.
> Matt Timmermanns Rijndael implementation changes the length of files
> So you have once again proven yourself incorrect in at least one way.
> Now since I'm tired of clogging the NG I'm going to leave DS alone while
> he tries to figure out whether or not logic applies in his world or not,
so I
> will no longer reply to him (or others replying to him) in this thread.
Actually, both of those statements are true.
While I don't agree with all of David's opinions, I don't recall a single
instance of him having his facts wrong.
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Wed, 07 Feb 2001 04:31:35 GMT
If you want to have it out with David on the matter of bijective
preprocessing before encryption, you have to understand the attack model it
protects against, and then you can understand what he's actually saying
below.
If you have ciphertext, but _no_ knowledge of the plaintext, then attack is
impossible if the transformation from PT to CT is bijective. All possible
plaintexts are plausible, and so you have no way to check any guess at the
key.
The important part here is that the phrase "_no_ knowledge" explicitly
disallows all of the assumptions you normally make about plaintext that let
you conduct key searches without it. Is this a valuable property for an
encryption system? I can't really say, but I don't think so -- it depends
on whether or not anything sufficiently close the the above situation
actually occurs in practice, and I don't think it does.
If we keep to that model, however, then it is easy to see that if the PT to
CT transform itself introduces redundancies which then undergo key-dependent
transformations, it makes ciphertext-only attacks against the key possible
again.
Now, I may not think that this sort of thing is a particularly important
property for an encryption system to have, but I'm not a cryptographer, and
I occasionally see fuss in the literature about other properties that I
don't consider to be important either. I can say that in the few instances
I've seen when a cipher has been stupidly weak enough to allow really
practical known-plaintext attacks that are actually _used_ (e.g., pkzip,
decss), the most commonly used known plaintext is the fixed header
introduced by some file format. What these cases _really_ show is that you
should use decent ciphers, and that's what I'd do, but what do you do if you
don't believe that decent ciphers exist, or don't beleive they will stay
that way?
It is also somewhat interesting that a bijective PT to CT transform is the
necessary and sufficient condition for provable security against
ciphertext-only attacks on the key (albeit, again, with that overly strict
definition of "ciphertext-only").
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:95q5ab$76k$[EMAIL PROTECTED]...
> In article <95q4lc$6mm$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >
> >
> > Two can play this game. Suppose one has a general file encryption
> > program that works for any file. Take Scott16u or your OTP
> > The amount of possible plaintext texts is 2**(number of bits in file)
> > encrypt with scott16u or the OTP the resulting output file has
> > the same number of bits and there are no possible encrypted files
> > that could have come from something other then any of the input
> > files. Since they are the same length plain text and encrypted and
> > since there is the same number in each set and there is a 1 to 1
> > relationship between every file in the palin set as encrypted there
> > is no difference in entropy. Something you fail to understnd.
>
> Either Scottu19 is an OTP or this paragraph doesn't make sense. If the
key
> going into Scottu19 is smaller then the message then it's not an OTP
**AND**
> there is not a 1-1 relationship between messages and keys.
>
> Tom
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Wed, 07 Feb 2001 04:40:35 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What do you mean the size of the input?
>
> Or, to put it another way, suppose you have AES with a 192 bit key.
> Write the relationship between the key bits, the plaintext bits, and the
> ciphertext bits as a 3SAT problem. Does this conversion take polynomial
> in terms of 192, or superpolynomial in terms of 192? (I think you've
> said the conversion takes polynomial time in terms of 192, but I'm not
> sure.) If it takes polynomial time to convert, then there cannot be
> more than polynomial terms in the 3SAT problem. If it takes
> superpolynomial time to convert, then there may [or may not] be a
> superpolynomial number of terms.
Strictly speaking (though not as strictly as Bryan does, which is why I'm
posting yet another response ;-), the reduction takes time polynomial in
worst-case run time of the algorithm (AES, in this instance) for inputs of
the given size. So (assuming key size unbounded), if the worst-case running
time of AES(K,M) is polynomial in length(K)+length(M), then the question
"AES(K,M)==C?" can be converted to 3-SAT in time polynomial in
length(K)+length(M).
------------------------------
From: "StuartL" <[EMAIL PROTECTED]>
Subject: RSA prime selection. (Newbie question)
Date: 7 Feb 2001 04:41:12 GMT
Hi, I'm new to this group and know hardly anything about encryption, but I
just read some stuff about how RSA works and there was one part that I
couldn't figure out. I was hoping someone here might help me understand :)
I wasn't sure if the prime numbers that RSA uses were calculated off-line
and stored somewhere? Say like when you download Netscape are the primes
that it will use for RSA pre-computed and downloaded with the software. If
so that sounds pretty insecure.
Alternatively if they are computed, are they computed once (say during
installation) or are they computed each time a secure sessions is
initiated. At fist that's how I though it was done but I just can't see how
it would be possible to do that in a reasonable amount of time with the
size of the prime numbers that they are using. (Just how big are they
anyway? I've heard figures like 200 digits or more mentioned.)
------------------------------
** 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
******************************
