Cryptography-Digest Digest #430, Volume #11 Mon, 27 Mar 00 14:13:01 EST
Contents:
Re: Legal Opinion advises use of steganographic filesytems in UK
([EMAIL PROTECTED])
Re: Cryptomat.com (Dave Hamilton)
Re: NIST publishes AES3 papers (David A. Wagner)
WTLS: The RC5 Bulk Encryption Algorithm (Anuj Seth)
Re: Mixing N bits into N bits (Tim Tyler)
Re: OAP-L3: Answer me these? (Jerry Coffin)
Re: ecc equation (Mike Rosing)
Re: DES question (Mok-Kong Shen)
Re: Card shuffling (Scott Nelson)
Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL" ("PJS")
Re: root mod a prime? (Mike Rosing)
Re: bigfloat works! (Mike Rosing)
Re: Gray Code like (Mike Rosing)
Re: DES question (DJohn37050)
Re: Gray Code like (David A. Wagner)
Re: DES question (David A. Wagner)
Re: Mixing N bits into N bits (Guy Macon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.scramdisk
Subject: Re: Legal Opinion advises use of steganographic filesytems in UK
Date: Mon, 27 Mar 2000 16:57:18 GMT
In article <954149703.11229.0.nnrp-
[EMAIL PROTECTED]>,
"NoSpam" <[EMAIL PROTECTED]> wrote:
> 22nd March 2000
>
> As the Opinion concludes:
>
> 'The above would suggest that for anyone using encryption, in order to avoid
> unjustified suspicion and possible wrongful conviction, it would have to be
> good practice to
>
> a) Use steganographic file systems or equivalent technology; and
>
> b) Not to admit to ever having had a key rather than be helpful and
> co-operative.
>
If you're a limey you might want to
consider contacting the company Eurotech.
They have aquired the company Crypto.com
which *claims* to have a technology that can
provide absolute security on open circuits
*without* the use of a key. If you learn
anything about this would you please post the
info here at sci.crypt or send it to my email
( [EMAIL PROTECTED] ) because I'm curious
about the above claim. Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dave Hamilton)
Subject: Re: Cryptomat.com
Date: Mon, 27 Mar 2000 17:16:42 GMT
Yup
They write a cookie containing
uid
1000154
www.cryptomat.com/
0
3499288448
29461512
3994201040
29333510
*
Dave
On Sun, 26 Mar 2000 13:48:14 -0500, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
> Tracing [xxxxxxxxxxxxxxxxxxxxx]...
> RR: www.cryptomat.com (195.224.241.23)
> 1 packets transmitted, 0 packets received, 100% packet loss
> Round Trip: 0 packets ms.
> Storing User Information.
>
>"p1p3r" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I wonder why they pop up that traceroute window when you visit the site
>> more than once. Is it some attempt to show how insecure your computer
>> is? A way to thwart scriptkiddies? Who knows?!
>>
>> p1p3r
>
>I think it has something to do with they are a bunch of morons who want to
>fool who people who don't know much about computers into thinking their site
>has something to do with security. So what information are they storing on
>me? Maybe my hostname will be associated with some cookie they set on my
>computer so if I didn't have a static IP they could tell which IP I was
>using before and which one I'm using now. But that still doesn't tell them
>who I am, what I'm doing or anything at all except what hostnames I have
>been using. If they were really trying to do something with that
>information they wouldn't pop up that window and tell you they are pinging
>you.
>
>
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST publishes AES3 papers
Date: 27 Mar 2000 08:40:42 -0800
In article <#JXaRQ6l$GA.244@cpmsnbbsa03>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> With as much respect as I have for both of you, I still
> disagree. To me triple-DES appears as little more than DES
> with 3x the rounds. While that clearly gives a great image
> of it's security, it seems to me that it would have been
> just as secure to create an expanded DES with 3x the rounds,
> which would give a smaller key.
But then you must choose a new key schedule for this
DES-variant, and that would be dangerous. It would
"void the security warranty" -- i.e., invalidate the
decades of analysis on DES -- and we'd have to start
over from scratch with the analysis.
In contrast, we *know* (we can prove) that triple-DES
is at least as strong as DES. We can't prove that it
is strictly stronger, but there are lots of good reasons
to believe that it probably is.
------------------------------
From: Anuj Seth <[EMAIL PROTECTED]>
Subject: WTLS: The RC5 Bulk Encryption Algorithm
Date: Mon, 27 Mar 2000 17:22:47 GMT
Greetings,
I'm implementing WTLS 1.2 and am facing some problems testing it with
the Nokia 7110 cell phone. The handshake is done without any problems
and the "Client Finished" PDU is successfully decrypted and validated by
my software. The Server Finished PDU that I send to the phone is always
accepted by the client because it does not send back any alert messages.
This means that the session keys that I calculate is being done
properly. The 7110 sends an application data PDU next. This is the 2nd
encrypted PDU; the 1st being the client finished PDU. The decryption for
this always fails for me (but, the client finished PDU is successfully
decrypted and validated!). The padding check & MAC always fails.
The only thing that I could think of was the calculation of the IV for
the RC5_CBC algorithm. I'm doing it as per the standard (record_IV =
original_IV XOR S, where S is the record sequence number). Is there
something else to this? If I'm not mistaken, in SSL/TLS the previous
plain text block is XORed with the new ciphertext block (or something
like this!!). But nothing to this effect is mentioned in the WTLS specs.
Could someone help me out with this?
Any help will be appreciated...
Thanks a ton,
Awaiting an early response,
With Regards,
Anuj Seth
Visit my homepage at http://anujseth.tripod.com/
http://www.geocities.com/anujseth/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Mixing N bits into N bits
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 17:29:06 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: stanislav shalunov wrote:
:> The basic idea is that you split your 32-bit value in two halves, L
:> and R, and then apply the following transformation a few times:
:>
:> TEMP <- L
:> L <- R
:> R <- TEMP XOR F(R, K)
:> F is a function that's as complicated as you can think of. [...]
:> The Feistel network trick described about lets you turn any function
:> F: {0..2^32-1} -> {0..2^16-1} into such 1-to-1 function. [...]
: What properties must F satisfy in order that your function based
: on the Feistel construction is 1-1?
No properties - besides being a deterministic function of its inputs.
Like the man said, you can use *any* function.
: A F that maps everything to 0 certainly wouldn't do.
It would certainly result in a reversible system. That's the
point of using a Feistel construction - you don't have to
worry about the properties of F if you just want invertibility.
Substituting F(R, K) -> 0 into the equations above yields:
TEMP <- L
L <- R
R <- TEMP ... which is perfectly invertible.
--
__________
|im |yler The Mandala Centre http://mandala.co.uk/ [EMAIL PROTECTED]
(send money)SUBLIMINAL(send money)TAGLINE(send money)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 10:55:29 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > Despite this, if a particular person's vote is represented (for
> > example) as a single bit, with a 0 representing a vote for one
> > candidate, and a 1 a vote for the other, I can easily switch
> > everybody's votes: I simply toggle the bit from whatever it presently
> > is, to the other possible value.
>
> That is why no serious encryption protocol would lack at least a CRC checksum
> to make sure that the data received has not been messed with. In reality,
> you'd also have a sequence number and salt value in order to prevent replay
> attacks, and you'd probably also have a cryptographically secure digest rather
> than a plain old CRC (much harder to find a plaintext that encrypts to the
> same checksum then).
Sure -- that's more or less beside the original point. The claim was
made that a one-time-pad, all by itself, was "perfect." It's true
that when properly used and implemented, it's 100% immune to a
plainttext-only attack, but that's more or less beside the point.
There's no question (at least in my mind) that with a properly
designed protocol, you can attain reasonably secure communications,
but doing so nearly always requires a LOT more than a secure
algorithm for the encryption proper, and probably can't ever be done
(at least dependably) with anything approaching theoretically perfect
security.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Mon, 27 Mar 2000 12:10:52 -0600
Tom St Denis wrote:
> No offense, but f@@@ you. Who are you to say I am a know-nothing? In my
> current library I have implemented RSA, several symmetric ciphers, a
> secure-PRNG, etc... So don't say I don't know what I am doing.
>
> Second who are you to say what I should or should not be using my time for.
> Even if I don't get the math right away I would still want to see it. You
> know there was a time when I didn't understand RSA or even the simplest
> large number math...
Tom, some of the math is pretty deep. For random curves over GF(2^n),
it's really hard to follow all of it without a tremendous background
in number theory.
You can follow the method of complex multiplication though. That is
described in the IEEE P1363 draft (appendix I think). If you use
complex
numbers it's down right simple. Since the results are integers, you
don't need complex numbers, but it's conceptually much simpler.
Check out this web site:
http://www.ioc.ee/~helger/crypto/link/public/elliptic.html
the paper under Koblitz curves will explain it.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Mon, 27 Mar 2000 20:16:20 +0200
Douglas A. Gwyn wrote:
>
> Paul Rubin wrote:
> > ... doc <[EMAIL PROTECTED]> wrote:
> > >Or, is it possible to have a ciphertext that does NOT
> > >decrypt using DES?
> > That wouldn't make any sense. It would mean the encryption was not
> > reversible.
>
> While not an issue for DES, it does make sense for some other
> encryption systems.
Question: If a DES key encripts 64 bit plaintext to 64 bit
ciphertext, can one say that this is the only key that
corresponds to this pair? Why? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Card shuffling
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 18:08:45 GMT
On Mon, 27 Mar 2000 02:43:40 GMT, DMc <[EMAIL PROTECTED]> wrote:
>On Sun, 26 Mar 2000 18:26:17 GMT, [EMAIL PROTECTED] (Scott Nelson)
>wrote:
>
>>Pardon, I should have been more explicit.
>
>>1.) I think it's unreasonable to assume that you are starting with
>>a deck in which no person knows it's order.
>>
>If you have a card deck somewhere near you which is previously used,
>use it without looking at any card face. Name the top card and set
>it to the side without looking at its face. Do the same for each
>succeeding card. Of course you record each name. Now compare your
>record with each actual cards.
>
>You will probably end with 0, 1, 2, or 3 matches. That is good
>evidence no person knew your card deck's order.
>
Ok, I happen to have a deck handy that I've used recently
to play solitaire.
Let see... I predict the top card 13 cards will be the Clubs
Ace through King. The next 13 will be Diamonds also Ace-King,
then the Hearts, and finally, Spades.
... Drat, only 26 right.
Well, that's still a tad higher than 3, and I think it's
pretty good evidence that I knew something about the order
of the deck.
Even if the cards aren't known in the first hand,
they will be by the second.
Like I said:
>>In my experience, most expert bridge players can remember the play
>>of every card in the previous hand. And once they are aware the
>>order of the pickup is important, they can remember that too. Even
>>non experts have little trouble remembering the lay of the
>>important cards.
>>
>>
>>3.) It possible that you are demanding too high a level of accuracy.
>>
>I take that as a compliment.
>>
>>In bridge, it often occurs that knowing if a king is to your left or
>>right will let you know if the finesse will work. There's a 50%
>>chance that you can get this right just by guessing. Increasing
>>that to 75% is enough to be noticeable.
>>
>Genuine contract bridge experts have numerous ways to increase their
>finessing chances, including some which increase their probability to
>100%. All are lawful, and do not require knowing anything about a
>prior deal.
Yes, after the bidding is over and the dummy is revealed,
it's quite likely that everyone knows the lay of most of
the important cards. I'm talking about knowing
if the finesse will work before the bidding is over.
>>
>>(Some sharps actually made use of this info in a tournament, and
>>they were caught because the other players noticed that there
>>[their?] bidding was too aggressive, but they always "lucked out")
>>
>This is not a violation of any contract bridge law I am aware of. It
>sounds to me like a "story" someone related to you.
>
There were some complaints about it, but the end result
was that everyone in the tournament shuffled the deck more
often, and nothing more was done.
>Actually, few deals are shuffled and dealt in tournaments.
>They are made up at tables from computer listings.
>The table that makes them up does not later play
>those deals for obvious reasons.
It's tempting to claim that this came about because of bad
shuffling on the part of humans, but actually it's
because of _complaints_ of bad shuffling on the part
of humans.
>>
>[EMAIL PROTECTED] previously wrote:
>>>
>>>I repeat my previous statement: One riffle, and one cut, returns a
>>>bridge deck back to fair; no matter what the previous play and card
>>>collection process. (By the way, this is where bridge experts begin
>>>to lay claim to knowing something of the next deal if certain cards
>>>are observed clumped together. Their claim is not objectively
>>>supportable. In my experiments, I completely controlled for such a
>>>possibility.)
>>
>>I too have run experiments with one shuffle and one cut, but I seem
>>to have gotten very different results.
>>
>>In particular, I find the last cut almost irrelevant.
>>If the Ace of Diamonds is on top of the King before the shuffle,
>>after one riffle shuffle there's a better than 50% chance there
>>is no more than one card between it and the King.
>>
>>(It's better if the shuffler is bad, but expert bridge players tend
>>to be above average shufflers.)
>>
>>That means the odds are about twice as good that the King will not
>>be to the right of the Ace. (About 5/6 instead of 2/3)
>>
>A player notes his D AK together is picked up as part of the 13
>cards just played in order. This player notes the deck being riffled
>and cut smoothly.
>
>You say that player can now calculate a more accurate probability
>of where that D AK ends up in the next hand.
>
No I didn't.
What I said was that he can guess the relative positions of
the King and Ace with a much higher than normal accuracy.
I.e. if the Ace was on top of the King before the shuffle,
there's a good chance it will still be on top of the King
after the shuffle and cut. If it is on top, then it will
be dealt to the right of the King.
>First off, you say there is more than a 50% chance of zero or one
>card lying between the D AK. That means there is less than a 50%
>chance of 2 or more cards separating the D AK in the next deal.
>
>I will let you look at your new hand.
>
>1 - You have the D AK; No advantage.
Ok.
>2 - You have the D A; More than 50% certain it is left of you or
> opposite you. Less than 50% certain it is right of you.
No.
Better than 50% of the time it's to my left, or across.
the rest of the time, it not known (random)
In other words,
<16% chance it's to the right,
>84% chance it's left or across.
>3 - You have the D K; More than 50% certain it is right or
> opposite you. Less than 50% certain it is left of you.
See above.
>4 - You have neither. You are 100% certain you do not know where
> the D AK are.
Probability that my partner has either the Ad or the Kd is much
higher than normal.
>My conclusion: A lot of energy for very little possible advantage.
>
I already remember the fall of the cards from last hand.
I had to do that just to play properly.
The addition expenditure of energy to not forget them
after the shuffle is slight, not "a lot"
>>
>>Knowing this is not a big advantage, but when the players are
>>otherwise evenly matched, even a tiny advantage can be enough.
>>
>You say tiny; I say ignorably infinitesimal.
>
Ok -
Knowing this is not a big advantage,
but when the players are otherwise evenly matched,
even an ignorably infinitesimal advantage can be enough. :)
(sorry, couldn't resist.)
I see two issues here.
1.) Can we really know if the Kd is to the Left of the Ad
with better than chance accuracy after one riffle and cut?
2.) Is there any advantage to be gained in knowing it?
I claim the answer to both is yes.
The first can be experimentally demonstrated.
I have actually done this.
The Ad Kd were removed and placed on top of each
other in position 13 and 14, (1/4 the way down.)
The deck was shuffled once, then examined.
In 9 out of 15 trials, the Ad remained
exactly on top of the Kd. In the 6 remaining
trials, there were 1-3 cards between them.
(3 times there was 1 card. twice there were 2,
and once there were 3.)
Any claim you want to make that the shuffle
doesn't work this way will have to be awfully
convincing to get me to doubt the evidence of
my own eyes.
The second is more problematic, and would require
4 people to test. But nothing you've said
convinces me that it isn't true.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "PJS" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.politics.censorship
Subject: Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL"
Date: Mon, 27 Mar 2000 19:19:11 +0100
Nick wrote in message
<[EMAIL PROTECTED]>...
>
>Geordie <[EMAIL PROTECTED]> wrote in message
>news:8blmck$24j9$[EMAIL PROTECTED]...
>>
>>
>> The most frightening thing is he can get away with it. There seem to be
no
>> organised protest to this attack on fundamental right's to privacy. Well
>> maybe this just goes to prove, as I have often suspected, that we are the
>> most intolerant and authoritarian country in the Western world.
>>
>> Geordie
>>
>1 - The European Convention on Human Rights becomes part of British Law in
>October, and includes provisions on privacy
>
>2 - Get on to your MP and complain like hell!
===========
3 - Assassinate Jack Straw.
--
Will the last person to be eaten
by the Fnord please turn the light out?
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: Mon, 27 Mar 2000 12:16:08 -0600
David Hopwood wrote:
> Careful: if kP is the point at infinity then the order of P divides k,
> but it is not necessarily equal to k.
Right. I was assuming k was a prime already. If k is composite, you
have to figure out what the order is by trying all the factors.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: bigfloat works!
Date: Mon, 27 Mar 2000 12:20:36 -0600
bigfloat works! Like all dumb bugs, it took me a while to nail it down.
The 256 bit mantissa appears accurate to about 250 bits, but I've only
counted Koblitz curves up to GF(2^163). The working version is
uploaded,
check it out from http://www.terracom.net/~eresrch/float
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Gray Code like
Date: Mon, 27 Mar 2000 12:37:14 -0600
Douglas A. Gwyn wrote:
> I think you're assuming that *any* maximal-length sequence can be
> generated by a suitably-tapped LFSR. Is that actually a theorem?
I would bet yes. If it's maximal length, then it's a primitive
polynomial.
Find the polynomial, and you've got the taps.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: DES question
Date: 27 Mar 2000 18:57:28 GMT
No, opne cannot say that.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Gray Code like
Date: 27 Mar 2000 10:22:07 -0800
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> I think you're assuming that *any* maximal-length sequence can be
> generated by a suitably-tapped LFSR. Is that actually a theorem?
I'm not sure what the statement of the claim would be, but let's
try a few:
1. Can all sequences of period 2^n - 1 can be generated by a n-bit LFSR?
Answer: NO (except for very small n). There are close to 2^{2^n - 1}
such sequences (certainly more than 2^{2^{n-1}}), whereas there are
less than 2^{2n} LFSRs (at most 2^n choices of taps times 2^n choices
of initial fill).
2. Can all sequences of period n be generated by a n-bit LFSR?
Answer: YES. Consider the LFSR with polynomial x^n + 1, whose initial
fill is first n bits of the sequence.
Was that what you were asking?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: DES question
Date: 27 Mar 2000 10:23:50 -0800
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Question: If a DES key encripts 64 bit plaintext to 64 bit
> ciphertext, can one say that this is the only key that
> corresponds to this pair? Why? Thanks.
No. In fact, it is not too hard (O(2^32) work) to find an explicit
counterexample, i.e., P,C,K,K' such that DES(K,P) = DES(K',P) = C but K != K'.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Mixing N bits into N bits
Date: 27 Mar 2000 14:04:23 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>
>On 26 Mar 2000 19:44:06 EST, [EMAIL PROTECTED] (Guy Macon) wrote,
>in part:
>
>>I would like to convert the variable into a
>>32 bit variable where each bit is equally likely to flip as time
>>increments, yet I want to keep the property that I am 100% certain
>>that the variable will never repeat in this century.
>
>>BTW, would "hash"
>>be a proper word to call what I just described?
>
>No, because even a cryptographically-secure hash is not 100% certain
>not to convert two different 32-bit values to the same result. But an
>invertible cipher would be, so a scaled-down version of DES with a
>32-bit block size would meet your criteria.
(Pardon me if this is an ignorant newbie question)
It just occured to me that, seeinag as it is ciphersaber that I am
noodling around with [ http://www.ciphersaber.gurus.com ], could
I use ciphersaber to mix up my "seconds since 01/01/2000" variable?
I am learning a lot by actually trying different things using the
basic framework of ciphersaber - I managed to write a variation
that takes 10 seconds to convert 1K of plaintext into the exact
same plaintext the other day... I challenge anyone to figure out
the exact details of my implementation with a known or chosen
plaintext attack! ;) I really appreciate the advice you folks are
giving me. I am flabergasted at those who invent something that
they think is new and then pronounce it to be secure. The more I
fool around with this stuff, the more I am convinced to use known
methods when I have real data to protect.
------------------------------
** 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
******************************
