Cryptography-Digest Digest #108
Cryptography-Digest Digest #108, Volume #14 Sun, 8 Apr 01 20:13:00 EDT
Contents:
Re: How good is steganography in the real world? ("Frank Young")
Re: JPEG also problematic (Mok-Kong Shen)
Re: anyone have digital certificates sample code (Anne Lynn Wheeler)
Steganography with natural texts (Mok-Kong Shen)
Re: Delta patching of encrypted data ("Anon")
co-author wanted for a paper (SAC conference...) ("Tom St Denis")
Re: anyone have digital certificates sample code (Paul Rubin)
Re: Dynamic Substitution Question (newbie)
Re: Delta patching of encrypted data (David Wagner)
Re: Delta patching of encrypted data (Mok-Kong Shen)
Re: New stream cipher (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: How good is steganography in the real world? (Charles Lyttle)
Re: Steganography with natural texts (Joe H Acker)
Re: Would dictionary-based data compression violate DynSub? (David Formosa (aka ?
the Platypus))
From: "Frank Young" [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: How good is steganography in the real world?
Date: Sun, 8 Apr 2001 13:26:40 -0700
Bruce Schneier had an excellent talk about this at DEF CON one year; I
don't
know if he ever wrote it down (perhaps in one of the issues of the
CRYPTO-GRAM newsletter?). He made the point that if two people suddenly
start
sending GIFs to each other, whereas previously they had not done so, this
may
attract suspicion. especially if the GIFs are pretty silly looking things
like pictures of flowers. Enough suspicion and people come to your house
with
rubber hoses...
One has to wonder why the "Technology Advisor" who started this whole thread
thinks that no one from Iraq will read it... including the employees of the
company he works for who are stationed in Iraq.
Just a suggestion Gil, in case this is not a troll and you really don't have
a clue what you have just done wrong
When everyone in Iraq suddenly wants to come home for vacation you should
think about taking a long vacation yourself.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: JPEG also problematic
Date: Sun, 08 Apr 2001 22:38:06 +0200
Frank Gerlach wrote:
Mok-Kong Shen wrote:
I have no knowledge but wonder voice in normal telephone
communications couldn't carry stego bits rather easily,
since all people speak differently (accents, male/female,
age, etc.) and at different times (health, emotions etc.)
so that differences due to stego modifications could be
very hard to detect.
So you would want to distort the phase and amplitude (let's use those crude
frequency domain terms) in order to encode the hidden information ?
I agree this is difficult to detect for an automated system, but then whatbout
the Mk1 acoustic bio-neural system (aka. "ear") ?
There are obviously two major approaches:
1. distorting the bogus signal (voice, music, images, video)
2. distorting the noise of the sampling process
Approach 1 is very difficult to assess, as a difficult-to-understand opponent
(the trainable and genetically varying human brain) is involved.
Approach 2 "only" makes assumptions about mathematical methods.
I do think that approach 1 is practically viable in voice,
since in general situations the opponent has to face the
fact that there are many candidate speakers and these are
unknown to him. (The speakers may also be foreigners of the
language employed.) Of course, the ratio of embedded bits
to the total volume of communication has to be kept
sufficiently low.
M. K. Shen
--
Subject: Re: anyone have digital certificates sample code
Reply-To: Anne Lynn Wheeler [EMAIL PROTECTED]
From: Anne Lynn Wheeler [EMAIL PROTECTED]
Date: Sun, 08 Apr 2001 20:51:06 GMT
"normang" [EMAIL PROTECTED] writes:
Does anyone know of sample working code to create digital certs.
We are trying to write a system for user authentication using our own
digital certificates for a internal user base (and so not have to shell out
to Verisign every time!). We intend to use ebcrypt as the basis for the
encryption requirements and transfer the packages using tcp/ip.
Thanks in advance.
Basically we want to issue x509 certs of out own and user a Kerberos type
system
even simpler would be to take radius and implement digital signature
authentication (i.e. public key recorded in an internal radius
database) for user authentication. then the radius protocol allows for
a wide-range of applications with access to the real-time database.
aka the registration authority part of registering public key w/o
having to do the certification authority piece (i.e. since they are
internal they presumably don't need 3rd party certification)
... an
Cryptography-Digest Digest #108
Cryptography-Digest Digest #108, Volume #13 Mon, 6 Nov 00 11:13:01 EST
Contents:
Re: XOR Software Utility (freeware) available from Ciphile Software (Lissi)
Re: XOR Software Utility (freeware) available from Ciphile Software (Richard
Heathfield)
Re: Microsoft's script encoder (Richard Heathfield)
blowfish ([EMAIL PROTECTED])
Memory map Visual C (MS) ("kihdip")
Re: Hardware RNGs (Alan Rouse)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: blowfish (Alan Rouse)
Re: A new paper claiming P=NP (Daniele Degiorgi)
Re: Memory map Visual C (MS) ("Brian Gladman")
Re: Brute force against DES (David Wagner)
Re: CHAP security hole question (David Wagner)
Re: ECC choice of field and basis (Anwar Hasan)
Re: Brute force against DES (JPeschel)
Thanx alan ([EMAIL PROTECTED])
Re: Brute force against DES (David Wagner)
Re: Microsoft's script encoder (Sundial Services)
Re: Memory map Visual C (MS) (Sundial Services)
Re: [newbie] Is PGP 7.0 hash extension secure? ("Thomas J. Boschloo")
Re: [newbie] Is PGP 7.0 hash extension secure? ("Thomas J. Boschloo")
From: Lissi [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Mon, 06 Nov 2000 12:33:29 GMT
On 06.11.00, 04:36:29, the suspect Tom St Denis [EMAIL PROTECTED]=20=
answered when questioned about Re: XOR Software Utility (freeware)=20
available from Ciphile Software:
=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1
How on earth did you make such a simple program take 155kb?
Tom
LOL! Did you scan it for hidden nuisances, Tom?
Lissi
- --=20
Life ain't fair, but the root password helps.
-BOFH
PGP-Fingerprint:
F119 52A9 A520 B1C5 28B7 BDFE 2B72 9E38 479E 31CC
=BEGIN PGP SIGNATURE=
Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com
iQA/AwUBOgaW9ytynjhHnjHMEQL+1ACg9gsM8JtXCI8KH7jY+Mt+Je36c1UAoOcB
QHY46IJvTlwkOsZ8SABND7wF
=3DYdYl
=END PGP SIGNATURE=
--
Date: Mon, 06 Nov 2000 10:26:07 +
From: Richard Heathfield [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
[alt.freespeech snipped from crosspost - my news server hates free
speech]
Anthony Stephen Szopa wrote:
XOR Software Utility (freeware) available from Ciphile Software
This software simply performs the universally available logical XOR
process on two files chosen by the user and outputs the resulting
file.
http://www.ciphile.com
I tried to have a look at this, but failed. No source code. Just the
binary. On the system I'm using right now, I couldn't have run it even
if I'd wanted to.
Since it's such a simple program to write, why no source code?
If someone will kindly point out what they would expect to happen if the
two source files are of different lengths, I will happily post portable
C source code to do this, on alt.crypto.sources (to avoid clogging up
all the splendid newsgroups to which this was cross-posted). Mind you,
if the code exceeds twenty lines of code (not including #includes, {,
and }, I'll be very surprised indeed...
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
KR Answers: http://users.powernet.co.uk/eton/kandr2/index.html
--
Date: Mon, 06 Nov 2000 11:18:29 +
From: Richard Heathfield [EMAIL PROTECTED]
Subject: Re: Microsoft's script encoder
Ichinin wrote:
Richard Heathfield wrote:
You probably can't learn how it works, because reverse-engineering it
probably contravenes the terms of your licence agreement.
Except where such license agreements are nullified by law...
Perhaps. But it seems to me that, when one agrees to a contract, one is
morally bound by that contract even if one is not legally bound by it
(unless there are overwhelming considerations to the contrary, such as
in the case of, say, a forced marriage).
opinionated rant
There's so much high-quality, free, Open Source and GNU software around
nowadays that locking oneself into proprietary and closed solutions
seems an odd strategy.
/opinionated rant
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
KR Answers: http://users.powernet.co.uk/eton/kandr2/index.html
--
From: [EMAIL PROTECTED]
Subject: blowfish
Date: Mon, 06 Nov 2000 13:16:58 GMT
Hi ...
I've had the "honor" to translate the blowfish algorithm from c to java
and i wonder ... can it be done ?
If yes! Hasn't it been already made by someone else ? If so is there
any good site you would recommend
Cryptography-Digest Digest #108
Cryptography-Digest Digest #108, Volume #12 Mon, 26 Jun 00 08:13:00 EDT
Contents:
Re: Public key algorithm conversion - does it possible? (Mark Wooding)
On a notation issue of Feistel ciphers (Mok-Kong Shen)
RPK ([EMAIL PROTECTED])
Re: MD5 Expansion (Mark Wooding)
Re: TEA-wmlscript question (dexMilano)
Re: How Uncertain? (Runu Knips)
Re: DES 64 bit OFB test vectors (Jack Spencer)
Re: security problem with Win 2000 Encryption File System (Sébastien SAUVAGE)
Re: DES 64 bit OFB test vectors (Jack Spencer)
Re: Quantum computing (Rob Warnock)
Re: XOR versur MOD (Mark Wooding)
Re: DES and questions (Gerard Tel)
Re: DES 64 bit OFB test vectors (Mark Wooding)
Re: TEA-wmlscript question (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: On a notation issue of Feistel ciphers (tomstd)
Re: RPK (tomstd)
Key agreement in GSM phones (Gerard Tel)
Re: Algo's with no easy attacks? (Runu Knips)
Re: Quantum computing (Runu Knips)
Re: Idea or 3DES (jungle)
Has anyone got / read: "The CRC Handbook of Combinatorial Designs" ("Sam Simpson")
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Public key algorithm conversion - does it possible?
Date: 26 Jun 2000 08:14:43 GMT
acoola [EMAIL PROTECTED] wrote:
Maybe it's my fallacy but it seems to me that it's no trivial for
cryptanalyst to get g.
You're right, it's not trivial. However, it's also irrelevant. *Any*
generator will do!
I'll restate the various parameters for your system, in more general
terms, and switching around the `public' and `private' labels:
Possibly shared:
A cyclic group G, with order q.
Public key:
An integer 1 x q.
Private key:
A generator g of the group G, and the element y = g^x.
`Signature'
A pair (a, b) = (g^k, M y^k)
`Verification'
b / a^x
The adversary chooses any generator g' of the group G. This is easy
enough to do. He computes y' = g'^x and uses the pair (g', y') as his
private key.
What's the difference between what you want to do and a digital
signature?
I'd like to unite properties of digital signature and enciphering and
I want to find out does it possible to make it at a time.
Investigate signature algorithms with message recovery, e.g., RSA.
-- [mdw]
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: On a notation issue of Feistel ciphers
Date: Mon, 26 Jun 2000 10:50:24 +0200
Feistel ciphers having two equal halves, e.g. DES, are
commonly described as follows for the i_th round:
L_i = R_(i-1)
R_i = L_(i-1) + F(K_i,R_(i-1))
If one combines two rounds into one combination ('big round'
for short in the following) and denotes the two halves of
the input to the big round with L and R, the two round keys
with K_1 and K_2 and the two halves of the output from the
big round with L' and R', one obtains
L' = L + F(K_1,R)
R' = R + F(K_2,L')
With this formulation one clearly sees the nature of the
iteration process involved when sucessive rounds are
performed, while in the original formulation this is
obscured a little bit by the 'swapping' of the two halves
of the block.
It may be interesting that using big rounds enables one to
simplify formulation for the (at least theoretically
conceivable, though for practical purpose presumably not
advantageous) case where the block is divided into, say,
three equal parts instead of two. Denoting the three parts
with U, V and W and the three round keys with K_1, K_2
and K_3, we have
U' = U + F(K_1,V)
V' = V + F(K_2,W)
W' = W + F(K_3,U')
M. K. Shen
=
http://home.t-online.de/home/mok-kong.shen
--
From: [EMAIL PROTECTED]
Subject: RPK
Date: Mon, 26 Jun 2000 08:38:16 GMT
This public key cryptographic system seems to fit audio and video
application very well.
Does anyone know about "real" applications that use it ?
Does anyone work on trying to break it ? ( Just to know how robust this
system is and how reasonnable it is to use it).
Thank you
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 26 Jun 2000 09:08:29 GMT
David A. Wagner [EMAIL PROTECTED] wrote:
David Hopwood already posted one attack, so this is probably
irrelevant, but here's another, just in case you're interested.
I think this works with the `fixed' version. I'll give up at this
point.
-- [mdw]
--
From: dexMilano [EMAIL PROTECTED]
Subject: Re: TEA-wmlscript question
Date: Mon, 26 Jun 2000 09:13:29 GMT
I love you guy.
I'll meka the test and let you know.
Just a question: How can I calculate a golden number (which is the
theory)? Have you some reference on th
Cryptography-Digest Digest #108
Cryptography-Digest Digest #108, Volume #11 Sat, 12 Feb 00 17:13:01 EST
Contents:
Re: *** ECC - new strong and fast calc method ("Craig Clapp")
Re: RFC: Reconstruction of XORd data (David A Molnar)
Re: BASIC Crypto Question (Johnny Bravo)
Has some already created a DATA DIODE? (No Spam)
From: "Craig Clapp" [EMAIL PROTECTED]
Subject: Re: *** ECC - new strong and fast calc method
Date: Sat, 12 Feb 2000 20:51:26 GMT
David Hopwood wrote in message [EMAIL PROTECTED]...
-BEGIN PGP SIGNED MESSAGE-
Greg wrote:
Here is another stab at trying to make things run faster for ECC.
Assuming that none or only portions may already be covered by
existing patents, the remainder is immediately submitted to the
public domain for free use by all.
Patents that MAY have some overlap include 5,987,131.
Given a curve over a field of say 163 bits, I have found
that average performance in calculating a point multiplication
can be reduced to 1/3 the time if all points resulting from
each power of 2 are precomputed and the ones matching the powers
of two in the private key are then added together.
This is a special case of a well-known technique called "fixed
base windowing", for example see Handbook of Applied Cryptography
section 14.6.3 (which describes it for exponentiation in a
multiplicative group, but it's obvious that it also applies to
multiplication in an additive group). The algorithm you've described
is the case where h = 2.
Chapter 14 of HAC is at
http://www.cacr.math.uwaterloo.ca/hac/about/chap14.pdf (or .ps);
I strongly recommend reading it. Chapter 3 is also relevant to
this thread.
I second that recommendation.
This is the part that most likely conflicts with 5,987,131.
If you have enough storage space for 163 powers of the base
(including the base itself), then you would need just 28 point
additions to achieve 160-bit exponent diversity by properly
applying the techniques of US5,987,131, not the 80 that you
plan on doing. If you use the fixed-base comb method of [LL94]
(see also HAC 14.6.3 (iii) ) then you can get by with 36 point
additions. To get down to 28 point additions using the fixed-base
comb method you need something north of 381 table entries
(381 is enough to get down to 29 point additions, 508 gets you
down to 27).
Fixed base windowing is not patented.
Hmmm. If you are using the term as it is used in HAC (which for
all I know may be the origin of this term), then you may note that
HAC attributes the fixed-base windowing method (algorithm
14.109) to Brickell et al. (HAC page 633, ref [204] ). This is
the method embodied in U.S. patent 5,299,262 (HAC ref [203] ).
Moreover, this is one of the ten selected patents that HAC
details in section 15.2.3, and HAC page 644 explicitly references
the technique of US5,299,262 as that presented in algorithm 14.109.
Of course, the scope of the patent is defined by its claims, all of
which are related to using the fixed-base windowing technique for
exponentiating in cryptographic systems. So, strictly speaking you
may be right - fixed base windowing is not patented in the abstract
sense. If you have non-cryptographic uses for the fixed-base
windowing technique then you'll probably have no problems with
patent infringement. :-)
In fact, mathematical
algorithms are not supposed to be patentable (in any country,
AFAIK), although the US Patent Office in particular is very
inconsistent about applying this rule.
[...]
Additionally, if the key space is limited to 80 bits (in this
case), the number of point additions on average is cut in half.
That is, the average time it takes to calculate the resulting
point is 1/6 of the average using standard calculations using
a full key space. I argue that security is not weakened for
the following reasons:
Some have argued that 80 bits is enough to prevent a brute force
key search attack. This is accepted as obvious.
Some have argued that limiting the private key to 80 bits is enough
to make the Pollard Lambda (aka Pollard Kangaroo) attack feasible,
since the attack can be limited by boundaries in the key space.
However, if the bits that are used to define the key are 80 in
number, it does not matter where they are located. The total
time to calculate remains roughly the same. Therefore, they
can span the entire 163 bits in any random fashion.
The sci.crypt thread from November 1999 (title "bits of
diffiehellman private key") that I mentioned before was about
precisely this case, assuming the positions of the 80 bits are
known but arbitrary. In this case the cost of the attack described
there would be 2^41 curve additions (with a fairly large memory
requirement of 2^40 curve points, although it may be possible to
reduce that).
Also note that as pointed out in the notes on page 128 of HAC, an
exponent space with a Hamming weight of t (i.e. the
Cryptography-Digest Digest #108
Cryptography-Digest Digest #108, Volume #9 Fri, 19 Feb 99 14:13:04 EST
Contents:
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) ("Dan")
Re: Key ID, Key FingerPrint (Lutz Donnerhacke)
Fast exponentiation based on data Compresssion ("Pedro Félix")
Re: Double-DES, DESX, and instinct (Jerry Leichter)
Re: SkipJack vs RC2 (John Savard)
Re: Randomness of coin flips (Patrick Juola)
Re: SkipJack vs RC2 (John Savard)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The (David Vivash)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The ("james d.
hunter")
More Stuff: Rotor Design, Animated GIF (John Savard)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) (David Vivash)
Re: Telephone Encryption (R. Knauer)
Re: Telephone Encryption (Doug Stell)
Re: Where to publish hashes? (fungus)
Key ID, Key FingerPrint ([EMAIL PROTECTED])
Re: Bruce's Feb. "CRYPTO-GRAM" (wtshaw)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The ("james d. hunter")
From: "Dan" [EMAIL PROTECTED]
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness
Come From ?!? *** )
Date: Fri, 19 Feb 1999 11:24:27 -0800
In reply, not quite about randomness, but:
Lately, I've encountered problems with people
recognizing hypothetical situations, questions,
and dialogues.
Have any of you been experiencing problems with others
recognizing hypotheticals?
If-then-else is such a simple and effective way to dialogue,
but in the recent past, I've encountered some "resistance".
It really sucks, and makes other people appear
quite stupid, although I know they aren't.
There are two different types of if-then-else.
The problems that I've encountered have to
do with people who only do computer programming
forgetting that there is such a thing as a time
component in a machine.
There is a logic if-then-else
and there is a logistic if-then-else.
The logistic "if-then-else" has a non-removable random component.
Sounds like bullshit to me.
If "The logistic "if-then-else" has a non-removable random component."
is True, then please explain it further,
else it is false, ...
Of course, if time runs backwards, then we're all screwed, and if-then-elses
become meaningless, and bummers all around, else it only runs forwards
in reality, and we can all be happy.
Of course, in a machine, simulations can be run many different ways.
Also, there may be alot more to reality than us humans understand. For
example, if there are beings/civilizations who perceive all of time
instantaneously,
then who knows ... Maybe they'll help us out of our y2k problems!
--
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: Key ID, Key FingerPrint
Date: 19 Feb 1999 17:13:58 GMT
* [EMAIL PROTECTED] wrote:
Hi, i would to know what mecanims behind to make the Key ID and the Key
FingerPrint are the same for public key and secret key.
Yes, they are.
--
From: "Pedro Félix" [EMAIL PROTECTED]
Subject: Fast exponentiation based on data Compresssion
Date: Fri, 19 Feb 1999 15:21:41 -
I'm looking for the paper
I. E. Bocharova, B. D. Kudryashov, "Fast Exponentiation based on data
compression", ???
Any help in finding a elecronically available copy of this paper would be
very welcomed, as well as any other references on this topic.
I thank you in advance
P. Félix
--
From: Jerry Leichter [EMAIL PROTECTED]
Subject: Re: Double-DES, DESX, and instinct
Date: Fri, 19 Feb 1999 12:00:56 -0500
| : However, it seems to me that this encryption method *does* gain
| : resistance to a differential cryptanalysis attack...
|
| Upon further reflection, while some resistance might be gained, it
| wouldn't be that much; any "characteristic" wouldn't be much affected
| by a simple XOR, even if it would change the blocks for which the
| characteristic was manifested.
This isn't true. (The following are not my observations, but from
comments made to me when I made similar assertions in the past.)
DC starts by noticing that "sufficiently good" characteristics exist.
Those go through unmodified with XOR before and after.
However, the next step in DC is to compute actual internal states. To
do that, you need to know the key and data that went in and came out.
But you don't know that with DESX, so you get stuck.
Could DC be extended to produce and attack against DESX? Perhaps,
though no one has published one. It's certainly not an obvious
e
