Cryptography-Digest Digest #880, Volume #13 Tue, 13 Mar 01 06:13:01 EST
Contents:
Re: Really simple stream cipher (Benjamin Goldberg)
Re: OverWrite: best wipe software? (Mok-Kong Shen)
Is this book interesting ("dexMilano")
Re: Meaninog of Kasumi (Arturo)
Re: OverWrite: best wipe software? (Benjamin Goldberg)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Encrypt then HMAC or HMAC then Encrypt? (Bob Deblier)
Re: theory edge mailing list (Benjamin Goldberg)
Re: Popularity of AES ("Brian Gladman")
Instruction based encryption ("Michael Brown")
Re: Zero Knowledge Proof (Benjamin Goldberg)
(OT) Re: Text of Applied Cryptography .. do not feed the trolls ("Henrick Hellstr�m")
Re: Super strong crypto (Joe H. Acker)
Re: Super strong crypto (Joe H. Acker)
Cheap hardware to break RSA? (Sven Gohlke)
Packet Data Security Overlay (Steve Amor)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 08:42:14 GMT
David Wagner wrote:
>
> Scott Fluhrer wrote:
> >Indeed. Howver, to be fair to Mr. Hellstr�m, he did appear to
> >suggest having the error propogating encryption transform encrypt a
> >fixed padding at the end of the message, and have the decrypting
> >system verify that fixed padding before accept the message.
>
> Yes. I consider this roughly equivalent (for the discussion
> at hand) to using a MAC and having the decrypting system verify
> it before accepting the message. The question is not whether
> you use a MAC field or whether you use an all-zeros field; the
> real question is: Who checks this field?
>
> If it is the crypto layer who checks the field ("explicit"
> authentication), fantastic. Whether it's an all-or-nothing mode
> with zero padding or a MAC, if it's "explicit", my objections
> don't apply.
>
> The problem comes when you use "implicit" authentication, where
> the crypto layer doesn't check it explicitly and instead leaves
> it up to the application to notice somehow (hopefully). This is
> the case that worries me.
>
> If you can deploy all-or-nothing modes without falling for the
> temptation of "implicit" authentication, then I don't have any
> objections. My objections are with the "implicit" authentication.
It seems to me that it does not matter much whether authentification is
"implicit" or "explicit," so long as it's well documented at to which
one occurs.
As an analogy, consider two io libraries, one of which throws exceptions
(a la java's io stuff), and another which sets a global error flag.
Does it significantly matter which you use, so long as you know which it
is you are using?
If your app is not crypto-aware, then you need to have "explicit" error
checking -- throw an exception / abort the process / EXOI error /
whatever, if the crypto key is incorrect. If the app is crypto-aware,
or even if it does strict checking on it's inputs, then the crypto layer
can do "implicit" checking, ie, none at all, and feed garbage to the
app, and rely on the app to detect this. Both are perfectly acceptable,
so long as you know which one you are using -- ie, don't use "implicit"
checking in combination with an oblivious app.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 09:52:48 +0100
Dan Hargrove wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >I conjecture that with a really effective program (i.e.
> >one that the maintenance and repair people use and that
> >can address all sectors of the disk) to overwrite a dozen
> >or more times with differing bit patterns would render
> >recovery beyond the capability of current technology. But,
> >of course, physically destroying the hard drives certainly
> >provides more confidence for the user and, as you pointed
> >out, could well be afordable at current hardware prices.
>
> I would refer you to the following page.
>
> http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
>
> I hope this clarifies things for you.
Thanks for giving this authoritative reference literature.
It shows how difficult the problem of (surely) preventing
recovery through rewriting (even with special techniques)
is. Evidently, this kind of performance is not achievable
with a simple-minded C program running as a normal user job.
M. K. Shen
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Is this book interesting
Date: Tue, 13 Mar 2001 09:58:17 +0100
I'm looking for a light book on Histroy of cryptography.
What about " The code book" from Simon Singh?
Any other suggestion?
thx
dex
------------------------------
From: Arturo <aquiranNO$[EMAIL PROTECTED]>
Subject: Re: Meaninog of Kasumi
Date: Tue, 13 Mar 2001 09:37:29 +0100
On Sat, 10 Mar 2001 06:32:26 GMT, Paul Crowley
<[EMAIL PROTECTED]> wrote:
>Arturo <aquiranNO$[EMAIL PROTECTED]> writes:
>> KASUMI is the name of the encryption algorithm to be used in
>> third-generation mobile phones. My question is, what does that workd stand for?
>> Does it have any meaning? TIA
>
>More to the point, if they're so early in their standardisation
>process that they've only recently published this block cipher and
>invited analysis, is it too late for them just to switch to Rijndael?
>
>If KASUMI is by the designers of MISTY then it will be a well-designed
>algorithm, but what makes it more suitable than Rijndael for this
>purpose?
I�ve recently been reading the 3G doc specs. Seems like their set of
algorithms for authentication/key generation is called MILENAGE; at the core
there�s Rijndael. OTOH, the on-the-air encryption is made via KASUMI. Why the
didn�t settle for Rijndael, I don�t know.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 09:06:04 GMT
You claim to have demonstrated a "procedure whereby the OverWrite
program is certainly forced to overwrite the file." You have not at any
time shown PROOF (specifically, source code from the internals of the
operating system and the internals of the various different filesystems)
that your software does what it does.
In addition, I stated that the cost of the risk of downloading a binary
from your site was higher than the cost of replacing the media. Not
only haven't you addressed that, there is no way at all which you can --
no matter what you claim, the level of risk I assign to dl'ing binaries
from the net will always always always be very high. Nothing you can do
or say will lower the risk I percieve from that. It will always be
higher than the cost of replacing the media. Always always always.
Get it?
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 10:14:50 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98jta5$3hf$[EMAIL PROTECTED]...
> I must've missed it this failure mode present in "explicit authentication"
> that's not present in "implicit authentication". Would you mind
repeating?
If a MAC is present it must be recognized as such by the crypto software.
You cannot trust that the last block in a packet and only that one always is
a MAC, because it is possible that on some platforms the OS might put
packets in a queue and send the entire queue either when it is full or when
a timeout has been reached. It is possible that whatever means the crypto
engines of the server and of the client respectively use, they coher in
99,9% of the cases, but in the last 0,1% the MAC is passed to the
application as plain text because the crypto engine failed to recognize the
packet as being authenticated at all. In particular, such events are
possible if the crypto engines are different versions of the same software,
or if either one contains a modification made to make it fit a particular
compiler or programming language (e.g. a translation from C to Pascal).
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Encrypt then HMAC or HMAC then Encrypt?
Date: Tue, 13 Mar 2001 10:14:26 +0100
Bjorn Forsberg wrote:
> I am storing an encrypted data packet. Typically small (less than 1K
> FWIW). I am encrypting the data, then taking an HMAC of the encrypted
> data plus other plain text data. The HMAC is appended to the plain text
> data and cipher text data over which it operates on.
>
> I know SSL takes an HMAC of data then encrypts everything including the
> HMAC. I can't see anything really definitive that would say that one
> method is better over the other?
>
> Can someone please give me some good reasons to pick one way vs the
> other?
>
> Thank you.
>
> Bjorn Forsberg
>
In the DHAES encryption scheme (from a paper by Abdalla, Bellare and
Rogaway) the MAC is computed after encryption, and the decryption is only
done after the MAC has been verified.
This differs from what the previous replies said, so apparently there is no
concencus. I guess cases can be made for each choice.
Sincerely,
Bob Deblier
Virtual Unlimited
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: theory edge mailing list
Date: Tue, 13 Mar 2001 09:15:34 GMT
Quisquater wrote:
[snip]
> Last question: classical signature (by hand) is more watermarking or
> more digital signature?
Yes. :)
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Popularity of AES
Date: Tue, 13 Mar 2001 09:22:02 -0000
"Dan Hargrove" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (John Savard) wrote in
> <[EMAIL PROTECTED]>:
>
> >On 12 Mar 2001 18:06:28 GMT, [EMAIL PROTECTED] (Dan Hargrove)
> >wrote, in part:
> >
> >>AES is included with the new version of PGP. There must be some
> >>specifications for it.
> >
> >The Rijndael algorithm, which is publicly known, has been selected.
> >But the final official standard is not yet ready, so it isn't really
> >legitimate to term a Rijndael implementation an AES implementation,
> >that's all.
>
> So is the PGPFree AES Rijndael? I assumed that it was.
It is almost certainly AES compliant but we will not know for absolute
certain until the AES FIPS is approved.
Rijndael itself is fully specified and the intent is that the FIPS should be
a subset of the Rijndael specification with the block size constrained to
128 bits.
Hence the FIPS is being written to comply with the Rijndael specification
and should hence be fully consistent with it for a fixed 128 bit block
length.
It is also worth noting that where the Rijndael specification and reference
implementations have been inconsistent, it is the latter that have taken
precedence so it can be argued that the reference implementations are a more
definitive description of the algorithm than the specification. I am not
arguing that this is a good thing but just pointing it out as a fact of
life.
Brian Gladman
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Instruction based encryption
Date: Tue, 13 Mar 2001 22:20:48 +1300
Hi there,
I brought up this topic a while ago, and never followed up on it much.
Here's a description of the algorithm. I have implemented it in Delphi (just
tell me if you want the source), but I'm converting it to FreePas so that
most people can use it (I know you guys don't like binaries!). A C port
might come sometime this century (I hate C, but I'll do it if I'm forced :)
<=== BEGIN ALGORITHM ===>
Each 128 bit key is made up of 16 "instructions", each of length 8 bits. The
instructions go from the most significant bit down to the least significant
bit. The first 3 bits of each instruction are the instruction, x, and the
next 5 bits are the parameter n.
Instruction table
x
0 Xor with previous <n> plaintext bits
1 Xor with previous <n> ciphertext bits
2 Add previous <n> plaintext bits (under mod 256)
3 Add previous <n> ciphertext bits (under mod 256)
4 Subtract previous <n> plaintext bits (under mod 256)
5 Subtract previous <n> ciphertext bits (under mod 256)
6 Rotate left <n> bits
7 Rotate right <n> bits
The initial "previous plaintext" and "previous ciphertext" are both just
repetitions of the key.
"Mash" key according to the following method:
Xor key with previous 128 bits of plaintext
Repeat 11 times: Key = Key XOR (Key ROR 11)
(ROR = rotate right)
This key mashing is done every 128 bytes.
<=== BEGIN NOTES ===>
The 128 byte key mashing is just a number I pulled out of the air, so quite
possibly is not enough or too often.
The instruction table is quite possibly insecure, having both rotate left
and rotate right.
No key checking is done in the program. So you can get instructions like
"xor with 0 previous plaintext bits"
Using the key as the initial data might be insecure. A known plaintext
attack would be most effective on the first 16 bytes of the file, as you
could easily geerate the previous plaintext and ciphertext data. This would
still happen if you used a hash of the key though.
If the key was extended to 256 bits, then the instruction table should be
expanded to 16 instructions to avoid excessive repeats of instructions.
This should implement very nicey in hardware I should think.
<=== BEGIN SIGNATURE ===>
---
Michael Brown
Physics is no fun if you disregard friction.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Zero Knowledge Proof
Date: Tue, 13 Mar 2001 10:00:37 GMT
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) writes:
>
> > As far as crypto goes. I do know that the key exchanges that
> >occur involve zero knowledge methods. Which may be different
> >from what your calling zero knowledge proofs.
>
> In general this is probably not true. Many exchanges actually convey
> information from one side to the other, and are not zero knowledge. In
> a zero knowledge proof, the only bit of information which is conveyed
> is that the other side knows the relevant bit of information. It
> conveys nothing whatsoever about what that information is. Thus the
> ideal logon procedure would be to have a zero knowledge proof that the
> far side knows the password but conveys no information about that
> password whatsoever from either side to the other.
I think that the reason David is so confused is because certain types of
Zero Knowledge Proofs can be modified to also create a shared secret.
Some are even *designed* expressly for the purpose of simultaneously
performing a zero knowledge proof and creating a shared secret -- an
example of this is SRP.
Here's an example of a ZKP which doesn't make a shared secret.
P is the prover, V is the verifyer.
n = pq, the produce of two large primes.
s is the secret.
v is the quadratic residue of s, mod n
Note that after the creation of n, the large primes pq can be destroyed.
If they are kept around, they should be known *only* to P.
P publishes (n,v)
V now has (n,v)
[P's communication with V has ended, time passes, and now P wants to
connect to V and authenticate himself]
P wishes to prove to V that he knows s, but without revealing s
(That last bit is where the "zero knowledge" phrase comes from)
Repeat the following z times:
P chooses a random number, r, and sends r^2 mod n to V
V chooses a random bit, b, and sends it to P
P computes y = r*(s^b), and sends it to V
V computes y^2, and compares it to x*(v^b). If they are unequal, then V
knows that P does not know s. An attacker who is pretending to know s
can, with 50% probability, calculate an r and y for which y^2==x*(v^b).
After z rounds of successful interaction, the odds of P not knowing S
are 2^-z.
Note that no shared secret has been created. At no point in this scheme
does V know what s actually is.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: (OT) Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 11:23:04 +0100
"Douglas A. Gwyn" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> ... My point was that
> it is not so simple as just thinking "book => dead tree".
... and if you don't buy enough books, a lot of people will be without jobs
in the Amazons, on Borneo etc and possibly starve to death unless they burn
down even more trees for agriculture.
Seriously, scarce resource tend to be expensive. What's best for your wallet
is usually best for the environment. If it's not, it's usually because some
resources are treated as "free" because government regulations (and other
kinds of illegitimate conduct) prevents ownership and hence
commercialization of those resources. ;-)
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 11:23:31 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Joe H. Acker wrote:
> [snip]
> > Suppose there are only 3 candidates {Peter, Steve, James} in question
> > for Bob. Then the question can be reduced to a finite set of yes-no
> > questions:
> >
> > Bob: Was Peter at the British embassy yesterday at 15 PM?
> > Bob: Was Steve at the British embassy yesterday at 15 PM?
> > Bob: Was James at the British embassy yesterday at 15 PM?
> >
> > The informational content provided by Alice answering "Peter" should
> > be 3 bits *given the assumption of Bob that there are 3 candidates*.
> > Defining quantified informational content that way makes it dependant
> > on Bob's state of belief.
>
> Actually, that should be two bits, not three, since at most two
> questions actually need to be asked, if there are only three candidates,
> and if one and only one of them at a time can be at the embassy.
Yes, two bits in this case, but I was later mentioning that this sample
is for the non-exclusive case (Peter and Steve may both have been at the
embassy)
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Super strong crypto
Date: Tue, 13 Mar 2001 11:23:42 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> "Douglas A. Gwyn" wrote:
> >
> > Mok-Kong Shen wrote:
> > > My point is essentially the following: If one can define and
> > > quantify 'propagation of information' (rigorously), then
> > > one must be able to measure the information content in
> > > an arbitrarily given bit sequence in exact terms.
> >
> > But that's wrong. Information is inherently contextual (relative);
> > it does not inhere in individual, out-of-context bit values.
> > A given bit sequence might or might not convey information,
> > depending on one's expectations. E.g. if you expect to receive
> > a 0 bit and someone sends you a 0 bit, you do not receive "1 bit"
> > of information (more nearly 0 bits, depending on how strong your
> > a priori expectation is).
>
> But the original issue is to study 'propagation of
> information', isn't it? If there is no information at the
> start, then there can also be no propagation, right? So, if
> there is a case where you can claim to be able to study the
> propagation of information, there must be some information
> at the start, at the end and in all intermediate stages
> (the information may be of different quantity at different
> points, being lost or augmented or whatever) and that
> information must be exactly quantified, if your study is
> to be formal and rigorous as you wanted. And that brings
> back to my argument precisely.
You seem to talk about informational content (as opposed to
"information" in information theory) without taking the sign system and
the belief states of the sign users into account. Perhaps indeed the
latter can be abstracted from, but I don't think you can neglect the
former.
If I can *record* a random sequence, I can use it as an arbitrary sign.
Any event that can be identified two times can be taken as a sign type.
How many signals I can maximally encode in a given event, on the other
hand, depends on the number of distinct states that can be identified in
the event (number of bits of the sequence).
But you point to an important distinction that has been neglected a lot
in philosophy and semiotics. There are two different sorts of signs. One
hand, there are representational signs: the meaning of the sign is
mapped to the sign type (or, in case of indexicals, the sign token) by
convention and the relation sign-significatum in some way is arbitrary.
On the other hand, there are presentational signs: the sign token itself
*exemplifies* or *encodes* the significatum. For example, if you draw 5
points onto a blackboard, this sign does not only designate the number 5
but also is an example of the number 5.
It seems that in your argument, you're talking about presentational
signs while others talk about representational signs. Indeed a random
sequence *per se* does not convey much informational content in
comparison to, say, a forest I'm looking at. But you can still establish
a notion of quantified informational content for representational
signs---relative to the sign system and a given belief state of the sign
user. The crucial question in making this a "hard" science is wether and
how much you can abstract from the belief states of the sign users.
You'd want to have a methodology for determining the set of possible
answers to questions or, in other words, the set of possible solutions
to a given problem. I don't think this is possible in general, but in a
given domain (certain types of problems or questions) it might be.
I think Douglas A. Gwyn had something like this in mind: What is the
minimum amount of work time to break cipher X? If you could find a
cipher X for which you can prove that the minimum amount of time to
break it is Y, and you could prove that any other possible answer to the
question would be Y or >Y as well, then perhaps you could find a general
way to compose a cipher out of X that is provably stronger than X. Then,
of course, you can make it as strong as you like. This would work
vaguely comparable to coding theory, when you make an unreliable channel
reliable by chosing a good protocol and implementing error correction
mechanisms.
Regards,
Erich
------------------------------
From: Sven Gohlke <[EMAIL PROTECTED]>
Subject: Cheap hardware to break RSA?
Date: Tue, 13 Mar 2001 12:06:38 +0100
Hi There
I=B4m neither a specialist for hardware nor for cryptography, but I didn=B4=
t=20
found an entry like this in the FAQs.
As I know You have to solve a set of integral equations to break RSA (or =
to=20
find the prime factors, to be precise). But You don=B4t have to solve it=20
exact, because You have a sufficient fast iteration algorithm to fine tun=
e=20
Your results. And here is the question:
Why don=B4t You use analog computer to do this job? They are both, cheap =
and=20
fast so it seems to me, that they are a perfect choice.
Did such integral equations exists for ElGamal?
Best Regards
Sven
--
[EMAIL PROTECTED]
------------------------------
From: Steve Amor <[EMAIL PROTECTED]>
Subject: Packet Data Security Overlay
Date: Tue, 13 Mar 2001 11:03:37 +0000
Can anyone tell me where I can find detailed information on the Packet
Data Security Overlay, or preferably its predecessor which encrypted
telephone lines.
Thanks.
------------------------------
** 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
******************************
