Cryptography-Digest Digest #200, Volume #12 Tue, 11 Jul 00 07:13:00 EDT
Contents:
Re: SCRAMdisk or PGPdisk? (Troed)
Re: Proposal of some processor instructions for cryptographical applications
("Stefan Monnier " <[EMAIL PROTECTED]>)
Re: DES Analytic Crack (Volker Hetzer)
Re: SCRAMdisk or PGPdisk? (S�bastien SAUVAGE)
Re: Another AONT (less expensive, this time) (Mark Wooding)
Re: Another AONT (less expensive, this time) (Mark Wooding)
Re: acquire a secret authentication cipher bloc ("NP")
Re: Proposal of some processor instructions for cryptographical (Helger Lipmaa)
Re: Proposal of some processor instructions for cryptographical (Runu Knips)
Re: Proposal of some processor instructions for cryptographical (Runu Knips)
Public/Private Key crypting ([EMAIL PROTECTED])
Re: SecurID crypto (was "one time passwords and RADIUS") ("Trevor L. Jackson, III")
Re: Proposal of some processor instructions for cryptographical applications (Sander
Vesik)
Re: Quantum Computing (Was: Newbie question about factoring) (ca314159)
Re: Steganographic encryption system (phil hunt)
Re: TEA question ([EMAIL PROTECTED])
Re: MP3 encryption and patent 6,081,597 ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: SCRAMdisk or PGPdisk?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 11 Jul 2000 08:13:48 GMT
[EMAIL PROTECTED] (Simon Hogg) wrote:
>Forgive me, but I can't find any information comparing these two (SCRAMdisk or
>PGPdisk), so what's the consensus?
I like E4M .. :)
www.e4m.net
___/
_/
------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 11 Jul 2000 04:21:48 -0500
>>>>> "Iain" == Iain McClatchie <[EMAIL PROTECTED]> writes:
> crucial financial
These two words never go together in my book,
Stefan
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Tue, 11 Jul 2000 10:50:26 +0200
Mok-Kong Shen wrote:
> I misunderstood you. You did mention BDD, but I didn't identify that
> with your second approach. BDD, if I don't err, is a special form
> of boolean optimizations which the electrical engineers have used to
> simplify their circuits.
It can be used for that too. But the more exciting use is for solving those
equations.
> So, for example, the equations describing the
> S-boxes can be optimized with that. But the formal equations
> describing DES in terms of bits as variables after optimizations are,
> I guess, still beyond the reach of current resources to handle, in time,
> if not in storage.
How many bits are there? Bdd's have been used up to several hundred bits.
Are those equations available for download anywhere?
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
Subject: Re: SCRAMdisk or PGPdisk?
From: [EMAIL PROTECTED] (S�bastien SAUVAGE)
Date: Tue, 11 Jul 2000 08:54:30 GMT
[EMAIL PROTECTED] (Simon Hogg) wrote in <8kdkt2$fed$[EMAIL PROTECTED]>:
>Forgive me, but I can't find any information comparing these two
>(SCRAMdisk or PGPdisk), so what's the consensus?
>
>--
>Simon
Personal experience:
PGPDisk : unstable, refused to mount some disks.
ScramDisk : excellent. But not free under NT.
E4M : excellent. Free and works under 95/98/NT/2000. My choice.
(http://www.e4m.net)
There are other on-the-fly disk encryption software:
http://www.fortunecity.com/skyscraper/true/882/Comparison_OTFCrypto.htm
--
S�bastien SAUVAGE - [EMAIL PROTECTED]
http://www.bigfoot.com/~sebsauvage
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another AONT (less expensive, this time)
Date: 11 Jul 2000 09:07:09 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> This confuses me. I'll assume when you say x and y, you aren't refering
> to the variables described in the transform, but rather two distinct
> (and incedentally complete) messages. And you've got part of a
> transformed message (i think; you're not exactly clear). What is this
> supposed to get you?
The definition of an all-or-nothing transform is a function T such that
no computationally bounded adversary can distinguish a pair of messages
x, x' given partial information about their transformations T(x), T(x').
We split the adversary into two stages A = (A_0, A_1), where A_0 is
given a transformation and outputs two messages of its choosing and some
state information for A_1, and A_1 is given the state together with
partial information about the transformation of one of the messages
selected at random. The adversary succeeds if it works out which of the
messages it was given the transform of.
The partial information is usually that we zero (or otherwise mangle)
some constant k of the bits of each transformed message.
I could write this symbolically, but (a) it would help, and (b) I'd get
it wrong. Anyway, let T_d be any deterministic function of over the
message space. My A_0 simply generates two messages x, x' at random,
and passes the transforms of the messages s = (T_d(x), T_d(x')) as its
state.
A_1 simply needs to inspect the partial transformed message it's given
and see which of T_d(x) and T_d(x') it's closer to. If it's closer to
T_d(x) then it outputs 0, and if it's closer to T_d(x') then it outputs
1.
I've handwaved on the meaning of `closer' here: it depends on the nature
of the partial information we're given. If some of the bits are zeroed
or XORed then we can count bit matches.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another AONT (less expensive, this time)
Date: 11 Jul 2000 09:09:09 GMT
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> > In fact, it's nowhere near as strong as OAEP. The critical
> > difference between Goldberg's construction and both OAEP and
> > Rivest's package transform is that both of the latter are randomized
> > transformations, whereas Goldberg's is deterministic. And I don't
> > believe that a deterministic transformation can meet the
> > requirements for an all-or-nothing transform, as defined in the
> > paper on OAEP-as- AONT.
>
> Why not?
For the reason I gave below: an attack against any deterministic
function used as an AONT.
> > Indeed, we can see that no deterministic transform can be as strong
> > as a randomized one, even in a weaker scenario than the non-
> > adaptive case given: given two messages x and y and partial data of
> > their transforms, the adversary can compute the full transform of
> > each of x and y and compare against the partial transforms given.
> > Compare this against the definition in which the adversary is
> > permitted to /choose/ the two messages to be transformed.
>
> A deterministic AONT would still be useful. The user could always just
> add his own randomness, if he wanted, by appending some random bytes
> to the end of the message.
But (unless there's a problem with my understanding of the definition,
which is still a possibility), deterministic AONTs don't exist, as
demonstrated. Adding randomness makes the transform randomized, at
which point it's worth analysing.
-- [mdw]
------------------------------
From: "NP" <[EMAIL PROTECTED]>
Subject: Re: acquire a secret authentication cipher bloc
Date: Tue, 11 Jul 2000 10:43:28 +0200
Thanks for the answers,
This bloc will be use only as dynamical anti-clone system.
We don't need a huge security feature.
If security become the main point, it's always possible to
multiply authentication with different random.
With that, we will have more than 16 bits response.
With a tiny algorithm, more than 16 bits response increase
the comprehension of the core, no?
Thinking T2G from France Telecom with this 4 bits response...
Regards,
NP
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 11:33:45 +0300
Jayant Shukla wrote:
> Now consider the same problem in a 100Base-T or 1000Base-T Ethernet
> network. Most AES candidates can encrypt/decrypt at 100Mb/s, but
> they chew up 100% of the CPU of a 600MHz PIII. Would you employ a
> $500 CPU just for the encryption task? (assuming it can do it, for
> 100Base-T... yes, but for 1000base-T...no way!)
On a 800Mhz Pentium III, all AES finalists (but Serpent) do it at 300Mbit/s
or better (cf http://www.tcm.hut.fi/~helger/aes/). So 100Mbit/s would take
only 30% of the processor time. Of course, the key setup times increase this
percentage somewhat.
Anyways, I'd prefer myself a hardware solution. _OR_ a software solution if
the processor had some silicon dedicated for the AES only. The second
solution would be better unless crypto hardware will be preinstalled on
motherboards for laymen :-)
Although, looking at the refereed table, the current hardware implementations
of AES finalists are mainly slower(!) than the software implementations on
the 800MhZ pentium III, I'd reason and say that this is since no much effort
has been put in implementing them yet.
Helger
------------------------------
Date: Tue, 11 Jul 2000 11:29:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Mok-Kong Shen wrote:
>
> Runu Knips wrote:
>
> > And, well, Serpent contains a really complex initial (and final)
> > bit permutation, even if I don't understand whats the use for it,
> > except that the cipher is seriously slowed down in software.
>
> It seems to be the majority opinion that the IP and inverse IP of
> DES are entirely useless. Does anyone know any probable
> design rationale for that?
Well, I already said this statement was <censored> !! ;-)
------------------------------
Date: Tue, 11 Jul 2000 11:36:51 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Mok-Kong Shen wrote:
>
> Runu Knips wrote:
>
> > When I have worked on Paranoia, my little cipher in the
> > contest, I had to spend much time thinking about exactly
> > that theme. I have described a network in the cipher paper
> > which requires 109 bits to specify all (32!) possible
> > bit permutations of a 32 bit word. One could implement
> > that with using the following 4 instructions:
> >
> > BRT1 src, dest, mask
> >
> > - For each pair of bits at the position 2*n and 2*n+1,
> > n in 0..15, of bits in src, if the bit n is set in mask,
> > the values of the bit pair is swapped before getting
> > assigned to dest. Therefore the mask has 16 bits.
>
> [snip]
>
> I am interested to see a formal proof that your scheme works for any
> arbitrary permuation. Or could you illustrate on a reduced example
> of an 8 bit permutation? Thanks.
In fact, I thought it worked perfect, but trying to proove this
formally leaded into *big* problems :-( because of a detail I've
overlooked. It might or might not be true, I've to check this
at home :-(
8 bits are 8! possibilies, too much to get computed by hand. Hmm
here is my version for 4 bits:
Lets make a table. According to our scheme, we have to show that
BRT1 reg1, reg1, mask1
BRTL2 reg1, reg1, mask2
BRT1 reg1, reg1, mask3
can create all possible bit permutations on 4 bits. Mask1
and mask3 are pairs of single bits, mask2 is two bits, i.e.
in [0..3].
Permutation Mask1 Mask2 Mask3
1234 [identity] 0,0 0 0,0
(or: 0,1 0 0,1 [...])
1243 0,1 0 0,0
(or: 0,0 0 0,1)
1324 0,1 3 1,0
1342 0,1 3 1,1
1423 0,0 3 1,0
1432 0,0 3 1,1
2134 1,0 0 0,0
(or: 0,0 0 1,0 [...])
2143 1,1 0 0,0
(or: 1,0 0 0,1 [...])
2314 0,0 1 0,1
2341 0,0 1 0,0
2413 0,1 1 0,1
2431 0,1 1 0,0
3124 0,1 3 0,0
3142 0,1 3 0,1
3214 1,1 3 0,0
3241 1,1 3 0,1
3412 0,0 2 0,0
3421 0,0 2 0,1
4123 0,0 3 0,0
4132 0,0 3 0,1
4213 1,0 3 0,0
4231 1,0 3 0,1
4312 0,1 2 0,0
4321 1,1 2 0,0
------------------------------
From: [EMAIL PROTECTED]
Subject: Public/Private Key crypting
Date: 11 Jul 2000 09:33:10 GMT
Hello,
I dont have a lot of experience with cyphering, so i am asking here.
Is there any algorithm, which allows me this:
-public and private key
-data==decrypt(decrypt(encrypt(encrypt(data,public_key1),public_key2),
private_key1), private_key2); !!
i be very thankfull for any comments, mostly for some links to the algorithm.
Bohdan
------------------------------
Date: Tue, 11 Jul 2000 06:22:03 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: SecurID crypto (was "one time passwords and RADIUS")
Roger Schlafly wrote:
> "Trevor L. Jackson, III" wrote:
> > There's an apparent contradiction in the reliance upon customer's testimonials as
> > to strength and the same reliance upon the same customers as the source of the
> > preference for continuation of trade secret protection. Either the customers think
> > the system is strong, or they think it may not be. The construct "they think it is
> > strong as long as it is secret" is a weak reed upon which to rest the judgments
> > you've endorsed.
>
> Not at all. The customers apparently think it is adequately
> strong, or they would not pay for it. But once they've paid,
> why should they want it publicized?
Payment is not a one-time thing, so customer endorsement requires an on-going belief in
strength. Now bureaucratic inertia would explain an on-going commitment and desire to
believe in the security of their systems, but bureaucratic inertia is hardly a
convincing
testimonial to strength.
If you doubt that bureaucratic inertia and market forces lead to denial of insecurity
consider the reaction of the French banking system to claims that their security was
weak. They were furious about it, but denied it. They _had_ to, or they would have
taken massive damage by the admission of insecurity.
A similar dynamic exists in the case of SecurID testimonials. The customers aren't
really saying "SecurID is safe"; they are saying "our company's security is strong".
But they hedge their bet and request the cipher remain secret because they are more
interested in maintaining their belief and the belief of their customers in what may
be a
false premise than they are interested in the truth of the security of the system.
>
>
> You local bank probably thinks it has a secure vault, but
> it still doesn't go out of its way to advertise the specs on it.
Actually they do. The security of money entrusted to them is a significant marketing
issue. All those FDIC stickers serve the same purpose. And if you inquire about the
vault they'll tell you about the vault (e.g., for safety deposit boxes), their security
systems etc.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 11 Jul 2000 10:28:30 GMT
In comp.arch Jayant Shukla <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David A. Wagner) writes:
>>Iain McClatchie <[EMAIL PROTECTED]> wrote [excerpts only]:
>>> Why bother supporting cryptography in the CPU?
>>>
>>> - Hardware implementations of the speed-critical cyphers are _tiny_.
>>>
> The AES candidates are not too _tiny_. In fact, the fully pipelined
> version of the AES candidates could not be fitted on Xilinx XC4000
> FPGA. The NSA paper shows that even the most efficient implementation
> of these algorithms in hardware takes up > 23 mm^2 of silicon.
> Don't even ask about the fully pipelined versions ( ~1000 mm^2).
What kind of silicon? That is - what geometry? I really can't see RC6 and
several others taking even close to that much.
[snip]
> apart from 20 cycles/byte you also have to consider the key
> setup time (1,500-10,000 cycles for the AES candidates).
> If you have a network gateway, you might have several
> security associations (SA) and for each SA you have
> the key setup problem. Suddenly for a 10Base-T network,
> your effective encryption load is greater than 10Mb/s.
> The problem only gets worse when you transmit many small
> packets.
Do you have to set up a new key for *each* packet? Why?
>>I'm truly interested in your thoughts.
> I hope it was interesting.
> regards,
> Jayant
--
Sander
FLW: "I can banish that demon"
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: Tue, 11 Jul 2000 10:33:23 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Bill Unruh wrote:
> > ... NMR computations are the the only computers which have been
> > created with more than one or two qubits, but ...
>
> Check out the news about Josephson junctions.
>
Quantum mirage is probably easier to upscale ?
http://google.yahoo.com/bin/query?p=quantum+mirage&hc=0&hs=0
This combined with agent theory (SFI and LANL) as a
form of error checking might be interesting. In
agent theory the parts are allowed to be erroneous and
yet the whole is organized (ant colonies, outsourcing),
sort of like the differences between various states of
magnetism: ferro, para, dia.
"The person is smart, people are dumb..."
-K, MIB
decoherence.
Google was absorbed by yahoo ?
That's unfortunate, they were orthogonal before.
--
http://www.bestweb.net/~ca314159/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 00:52:11 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 22:51:37 +0100, Garry Knight <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>>I am thinking of developing a steganographic encryption system
>[...]
>>(1) does anything like this exist already?
>
>ScramDisk (for Windows) incorporates this kind of technology.
>http://home.clara.net/scramdisk/
Scramdisk is quite interesting. Unfortunately it doesn't work with Linux.
It's quite similar to what I'm trying to do, except that it only accepts
one valid decryption key.
It's released under a wierd almost-open-source license; the license says
you can't distribute modified versions, but then goes on to say that if
you do, you must give them a copy.
>>(2) What's a good private-key cypher algorithm to use?
>[...]
>>Would Blowfish be a good algorithm to use?
>
>ScramDisk uses several algorithms which the user gets to choose.
>Blowfish is the one that's recommended by the author.
>
>I'm sure you also realise a potential drawback to using .jpg files: that
>they incorporate lossy compression?
I'm not "using" .jpg files. Stes won't attempt to hide information in
the low-order bits of a jpg. In my example, I used a .jpg as just another
file type.
Stes sees .jpg files as the same as all other plaintext files: they are
just a stream of bytes.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TEA question
Date: Tue, 11 Jul 2000 11:06:01 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
dexMilano wrote:
> I don't have unsigned
it does not matter if it is signed or not.
at least for TEA/XTEA it does not matter.
> so I have an upper limit of f7777777 (absolute
> value).
you mean 7FFFFFFF.
but this is not limit.
limit for both signed and unsigned integers are FFFFFFFF.
> I want to make 32 cicle so the initial value of delta should be int
> (max/32)
why?
no it should not.. it can be up to max.
> and it is 3ffffff (11111111111111111111111111 that has 26
> bits); too small.
>
> The smallest integer of 32 bits is 10000000000000... that is 80000000
> i.e 2147483648. but this number exceed the limits.
what limits ? limit is FFFFFFFF
> Do yuo mean that I can't use this algorithm?
> dex
you can of course.
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOWrjdjBaTVEuJQxkEQLysACgqGIKWY3VS9892oEkr3kRXs8yVtEAniUp
wiRXp22twZjlxYdtTO5EgD0O
=uakK
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: MP3 encryption and patent 6,081,597
Date: Tue, 11 Jul 2000 11:08:45 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"Frank M. Siegert" wrote:
> .... And since MP3 encoding of an
> already MP3 encoded stream (decoded to raw sound) does not degrade the
> quality further
are you sure of that ?
IMHO it degrades..
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOWrkGDBaTVEuJQxkEQJyIgCgrKXmqpDesN2/hkIh+4x9A7nRLasAoKNx
06QVhV1Ne4jWVZGHLR9n7c44
=jh7N
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
