Cryptography-Digest Digest #307, Volume #14 Mon, 7 May 01 05:13:01 EDT
Contents:
Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone expected all
along... ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],)
magic; was Re: OTP WAS BROKEN!!! ("David Thompson")
SafeDebit Protocols & Scrutiny ? (shoot a spammer week)
Re: research on polymorphic crypto/Best Possible Privacy? ("Mark G Wolf")
Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone expected all
along... (Jim Deluca)
IV question !! ("gilles")
help for decrypt (Carlo Geuna)
Re: IV question !! ("Scott Fluhrer")
Re: LUCIFER ("Henrick Hellstr�m")
Re: IV question !! ("Henrick Hellstr�m")
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
Re: IV question !! (Ben Smith)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
----------------------------------------------------------------------------
Subject: Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone
expected all along...
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.privacy.anon-server
From: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
Date: Sun, 6 May 2001 17:54:52 +0200 (CEST)
On Sun, 06 May 2001, "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo TOO MUCH
Boschloo NO
Boschloo TOO MUCH
Boschloo is a TROLL
Boschloo is a CLOWN
Against Boschloo
Neuter Boschloo
SCREW Boschloo
Stop Boschloo NUTS
Stop Boschloo NONSENSE
Stop Boschloo RAT
Stop Boschloo insanity
Boschloo is a PLAGUE
NONSENSE from Boschloo, as usual,
trying to occupy frontstage with his pretense of knowledge
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wanted
to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(when he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
Stop Boschloo diarrhea
Stop Boschloo posting diarrhea
Fight Boschloo
Stop Boschloo MADNESS
Stop Boschloo RAT
Stop Boschloo INSANITY
Stop Boschloo NONSENSE
Stop Boschloo NUTS
Boschloo TOO MUCH
Boschloo is a PLAGUE
SCREW Boschloo
Neuter Boschloo
Boschloo is a CLOWN
Boschloo TOO MUCH
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo NO
Boschloo PLAGUE
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: magic; was Re: OTP WAS BROKEN!!!
Date: Mon, 07 May 2001 04:42:16 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote :
...
> Obvious question: how would your scheme function if instead of getting a
> encrypted message C, I gave it a random sequence of bits that is of the
> right length? Would it then be able to produce the same plaintext or not?
>
I think we've agreed that magic key guessing is the Karnak attack ...
> If it does produce the same plaintext, then how it is able to produce
> correct plaintext in the absence of any information? After all, an attacker
> would be able to create a random string, and then proceed to use your
> procedure to break it, without the bother of actually intercepting a
> message, or for that matter, without the bother of the sender actually
> sending one.
>
So can I propose that magic plaintext guessing with no ciphertext
at all is the Madame Cleo attack, on the grounds that Madame Cleo
is at least twice as obnoxious as Karnak ever was?
<?G?>
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: [EMAIL PROTECTED] (shoot a spammer week)
Subject: SafeDebit Protocols & Scrutiny ?
Date: Mon, 07 May 2001 05:04:19 GMT
Safer debit is a patent pending technology created by NYCE . It consists
of a credit card sized CD-ROM that is placed into a computer. To obtain
the CD-ROM the consumer must apply to their bank for the CD-ROM and sign
up. The card can only access checking (as opposed to savings accounts).
It involves four parties to the transaction, The issuing bank (also known
as the Demand Deposit Account - DDA), the merchant, the consumer, and a
trusted third party intermediary ("Trent").
Sometime after signing up with his/her bank, the consumer is sent a
CD-ROM and shortly after that an "e-PIN". In the meantime, and behind the
scenes, the issuing bank supplies Trent with the consumers real PIN over a
highly secure network. Trent stores the real PIN in a highly secure
database, which uses a tamper proof hardware security module (HSM)
supplied by Zaxos, a division of Thomson-CSF Racal. Trent then creates a
CD-ROM that contains the real PIN and account data, plus a "e-Pin". All
of the data on the CD-ROM is encrypted by a secret key known only to
Trent.
The consumer, when making a purchase, enters a "shadow" password that
allows the software on the CD-ROM to interact with the shadow PIN. The
interaction results in a what is called a one-way operation, or hash, that
mathematically combines the shadow password and a subset of the unique
data on the CD-ROM. This data is useless to anyone except the person who
knows the matching key and PIN that is encrypted on the CD-ROM. It can be
published in the newspaper. Additional security may be realized with a
time stamp and session key between Trent and the consumer/merchant.
Upon receiving this, Trent gathers the real PIN and the matching keyfrom
its highly secure database to see if the hash sent from the consumers PC
matches the hash Trent calculates. If it does, Trent sends the
transaction amount to the issuing bank/DDA for approval using standard
ANSI X.9 / ISO 8583 methods. The bank does not need to change any of its
back end infrastructure as a result - Trent is simultaneously acting as a
trusted intermediary and highly secure key repository. The response
from the issuer/DDA - approve or decline - is then sent back through Trent
to the merchant/consumer with the outcome. NYCE plans to charge merchants
1.65% plus 10 cents on top of any any existing debit switching charges for
SafeDebit transactions.
This all sounds feasible and secure *if* all the technical steps are
implemented properly and the protocols are correct.
The weakness of the system is if the the CD-ROM is copied or key data
secretly extracted from it simultaneously with the shadow password. Such
viruses are definitely feasible, and the PC is known to have very weak
security. The SafeDebit CD-ROM has not been released to the cryptographic
community for public scrutiny or hostile attacks by hackers.
Comments ? Anyone know the inventor(s) and if issued, application No. ?
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: research on polymorphic crypto/Best Possible Privacy?
Date: Mon, 7 May 2001 00:25:01 -0500
> Your the one jumping to conclutions. I am proud being part german
> and am enjoying a german beer this very minute. What pissed me off
Oh! See how a simple misunderstanding can lead to such different
interpretations. That's ok, it was a good exercise.
> was the crappy cipher. Trying to bluff its way into being something
> good by claiming it was german. It sucks and no real german would want
> to associate his name with it. But of course like any race they have
Really? I think there are some good fundamental ideas there. To be honest
I haven't looked closely at their particular implementation, but the idea is
sound.
> there portion of retards. I personelly think its best to be mixed the
> hybrid races have a built in genetic superiority and fewer retards.
I have noticed that the more pure or inbred races, depending on how you look
at it, seem to suffer many more exotic and numerous diseases. Being a
mongrel myself I'm generally very healthy. I can and have withstood a great
deal of punishment. Personally don't matter to me, whatever people want to
do is fine, it's an individual choice. I do get a bit perturbed by those
claming overall superiority though. For instance jews want to mix everybody
up genetically, yet they themselves inbreed. Then there were the nazis who
wanted a blonde blue-eyed race. Look at the big picture, if breeding
occurred randomly across all populations we'd eventually end up with the
exact same mix, which can't be good. Likewise you'd get the same amongst
large individual groups without an occasional injection of outside DNA. So
you kind of slosh back and forth between the two extremes for maximum
diversity. But this is OT and Mr. Nosey Thought Patrol might complain and
start calling me a hater.
------------------------------
From: Jim Deluca <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.privacy.anon-server
Subject: Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone
expected all along...
Date: Mon, 07 May 2001 05:31:18 GMT
I don't know what this shit is all about, but why not take it elsewhere,
OR since you seem to be the injured party, just killfile the asshole(s) if
there is a common characteristic of his/their posts?
God I remember the good old days when we had a flame newsgroup and you
were sometimes forced to got there or get booted from the newsgroup.
------------------------------
From: "gilles" <[EMAIL PROTECTED]>
Subject: IV question !!
Date: Mon, 7 May 2001 08:44:06 +0200
hello,
i have a stream cipher
when i encrypt a file
i put the IV in this file
if a person modify some
bit of this IV my file
is unrecoverable !!!
i seek some possibility for
avoid that
i have some idea
duplicate the IV or store it
in another file
create a counter IV (not alea)
what is the best way
thanks !!
------------------------------
From: [EMAIL PROTECTED] (Carlo Geuna)
Subject: help for decrypt
Date: Mon, 7 May 2001 07:05:10 +0000 (UTC)
--=====================_3451412==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
hello. i've (involontary) crypt a file with w2k server, then i deleting the
system, i re-install the system but the file is blocked. i dont't read or
write thise file because the error is "file occupate.." i've install suse
Linux 7.1 but i don't know the procedure for read a ntfs5 partitions.
I've many problems if i don't open this file.
Bye
--=====================_3451412==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=5>hello. i've (involontary) crypt a file with w2k server, then
i deleting the system, i re-install the system but the file is blocked. i
dont't read or write thise file because the error is "file
occupate.." i've install suse Linux 7.1 but i don't know the
procedure for read a ntfs5 partitions.<br><br>
I've many problems if i don't open this file.<br>
Bye <br>
</font></html>
--=====================_3451412==_.ALT--
--
Posted from giotto.it.ip-plus.net [212.110.0.19]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: IV question !!
Date: Sun, 6 May 2001 23:59:12 -0700
gilles <[EMAIL PROTECTED]> wrote in message
news:9d5g7n$11d$[EMAIL PROTECTED]...
> hello,
>
> i have a stream cipher
> when i encrypt a file
> i put the IV in this file
> if a person modify some
> bit of this IV my file
> is unrecoverable !!!
>
> i seek some possibility for
> avoid that
>
> i have some idea
> duplicate the IV or store it
> in another file
> create a counter IV (not alea)
> what is the best way
I don't really see the point. After all, if you assume that attacker can
modify the IV, why can't he just replace the entire file with random
gibberish. If he does that, the file will be unrecoverable, no matter what
you do.
If you do have a plausible attack model where the attacker can modify a
limited number of bits, perhaps some error correction logic done after the
encryption has taken place should fix this.
--
poncho
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: LUCIFER
Date: Mon, 7 May 2001 09:58:23 +0200
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:9d50vd$m5b$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >[...] Why wasn't it a single cycle transposition?
>
> Is there any reason why the cycle structure of the permutation
> should matter cryptographically in this setting? I can't think
> of any at the moment, but maybe I'm missing something.
No, the cycle structure does not matter per se. In fact, I am beginning to
doubt that a single cycle transposition would be optimal. The properties of
the transposition that does matter are more complex:
One of the purposes of a transposition in this setting is to make it
possible that, for each n and m, the probability will be 0.5 that a one bit
input differential in bit n will result in a one bit output differential in
bit m. If the s-boxes were random, the transposition should be composed of
cycles such that the path of each cycle passed through each nibble on its
way. More precisely, since there are 16 nibbles and 16 rounds, you would
prefer that each 16 position segment of each such path passed through each
nibble on its way. A transposition composed of 8 equi-sized cycles with this
property would probably do. A single cycle would not do for another reason,
because you also want that for each nibble, the 4 bits of that nibble were
mapped to mutually disjoint target nibbles. You cannot combine this property
with the first if there is only a single cycle, but you could obtain both
properties with 8 disjoint cycles.
Now, I see that the s-boxes were not keyed, so you could choose the
transposition so that the combined effect of the transposition and the
s-boxes would be the same, without the transposition having the mentioned
property. In order to prove that this would be the case, you might use a
different technique. Firstly, prove (possibly extensively) that the s-boxes
are such that for each n and m in [0..3] a one bit input differential in
position n would induce a one bit output differential in bit m half of the
time. Secondly, for each i in [0..7], let M_i be the set of the four
nibble-positions the transposition maps the bits of nibble i into. Then
prove that for each n and m in [0..63] there is a sequence of i_0,
i_1,...,i_k, where k is less than 15, such that M_{i_0} intersects M_{i_1},
M_{i_1} intersects M_{i_2}, etc. You would however get this property for
free if the transposition had 8 disjoint cycles with the properties
described in the preceding paragraph.
One should probably also account for the keyed nibble-swap. This operation
does not change the picture radically. You would rather have to add the
criterion that for each i, the set M_{i*2} is not equal to M_{i*2+1}. This
would indeed be the case if the transposition had 8 disjoint cycles with
paths that visited each nibble once.
I have focused on the property that one bit input differentials should not
result in biased one bit output differentials. There are of course other
properties a decent cipher should have, but I understand that Lucifer does
not have those properties anyway. One might just as well optimize the
properties it might have, and e.g. combine it with a stream cipher pre and
post (cf. John Savards home page).
Here I should probably add a disclaimer that I haven't thought that much
about the use of transpositions in ciphers. I have only written what I
believe to be generally true, and if I am wrong I surely would not mind
being told so.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: IV question !!
Date: Mon, 7 May 2001 10:17:19 +0200
Are you using an error propagating cipher or cipher mode (e.g. PCFB-mode)?
Error propagating ciphers are mainly useful whenever message integrity is of
critical importance, so that the message would anyway be discarded in full
if any part of it was manipulated. If message integrity is not a priority,
you should use something else.
Otherwise, you should probably treat the IV as secret key data. You would
obviously have a similar problem if someone somehow managed to modify the
key. For example, you could let the cipher key be H(user key) and the IV be
H((user key) + ctr), where ctr > 0 is incremented each message.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"gilles" <[EMAIL PROTECTED]> skrev i meddelandet
news:9d5g7n$11d$[EMAIL PROTECTED]...
> hello,
>
> i have a stream cipher
> when i encrypt a file
> i put the IV in this file
> if a person modify some
> bit of this IV my file
> is unrecoverable !!!
>
> i seek some possibility for
> avoid that
>
> i have some idea
> duplicate the IV or store it
> in another file
> create a counter IV (not alea)
> what is the best way
> thanks !!
>
>
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Mon, 07 May 2001 01:34:10 -0700
Tom St Denis wrote:
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > With your many previous vague and less than precise posts you must
> > explain exactly what YOU mean by "leakage."
> >
> > Not what "leakage" has been defined by others but in your own words
> > what you understand this word / concept to mean.
> >
> > There can be no discussion on what YOU mean by "leakage" unless
> > you define it in your own terms because you frequently are ambiguous
> > and we cannot assume that you even know what you mean.
>
> Leakage means what it implies. Every output byte must leak some (perhaps
> little) info about the input state, this is always going to happen.
>
> The real question is how much info is leaked, i.e how many bytes (bits,
> etc...) are required to learn enough about the internal state.
>
> Tom
I think the place to start in answering this question is to read the
Help Files: Theory, Processes, Operation, etc. and the recommended
use.
Good luck. You'll need it if you think you have a prayer in
breaking the OTP files.
------------------------------
From: Ben Smith <[EMAIL PROTECTED]>
Subject: Re: IV question !!
Date: Mon, 7 May 2001 18:38:05 +1000
On Mon, 7 May 2001, gilles wrote:
> hello,
>
> i have a stream cipher
> when i encrypt a file
> i put the IV in this file
> if a person modify some
> bit of this IV my file
> is unrecoverable !!!
I must be tired; I read "TV" for "IV". Made the post much more emjoyable,
though.
ben
--
Always - what does that mean?
Forever - what does that mean?
It means we'll manage
-- Tricky, Christiansands
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Mon, 07 May 2001 11:03:51 +0200
David Hopwood wrote:
>
> Bryan Olson wrote:
> > The modification destroys an important property of
> > the basic combination method: as long as the streams
> > are independent, if any of the streams are uniform
> > then the sum is uniform.
>
> Mok-Kong Shen wrote:
> > David Hopwood wrote:
> > > We assume that there is *at least one* uniform independent stream.
> > > Bryan Olson's point is absolutely correct: it is obvious that the
> > > modified Wichmann-Hill scheme, with weights that are not all
> > > non-zero integers, does not have the property stated above.
> > >
> > > (Counter-example: if the only uniform stream has a weight that is not
> > > a non-zero integer, then after weighting it is not uniform. If the
> > > other streams are also non-uniform, then in general the sum is not
> > > uniform either.)
>
> (Note that it was clear from context that "uniform" here, and in
> Bryan Olson's post, meant uniform on [0, 1.0).)
>
> > In a rather early follow-up I already mentioned that from
> > theory the result is uniform if one of the streams is
> > uniform.
>
> That is obviously false. If you want a more concrete counterexample,
> consider 1.0*r1 + 0.9*r2, where r1 is always zero and r2 is uniform on
> [0, 1.0); clearly the result is the uniform distribution on [0, 0.9)
> (and hence not on [0, 1.0) as would be the case if Bryan Olson's
> property held).
I am sorry that I don't understand you intention here. Do
you have any doubt that, when BOTH r1 and r2 are non-zero,
the above proposition is always true? If yes, please kindly
say so and we could discuss on that. (Note that in my OP I mentioned
that the r's are chosen in the vicinity of 1.0,
so I was certainly not considering cases like yours.) Bryan
Olson was refering to that known fact (a theorem) and saying
that any deviations of the underlying assumption, namely not
requiring that one stream is uniform, would lead to result
that is not only (theoretically) non-reform but in fact
can be very remote from uniform, for which Brain Gladman
has produced a very nice experimental demonstration and I
subsequently reproduced with another pair of PRNGs.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
