Cryptography-Digest Digest #517, Volume #10 Sat, 6 Nov 99 11:13:02 EST
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Phunda Mental)
Re: How protect HDisk against Customs when entering Great Britain ("Mr. Tines")
Re: questions on smart cards ("ME")
U-Boat Enigma Machines (Anthony Stephen Szopa)
Re: How protect HDisk against Customs when entering Great Britain (That guy...from
that show!)
Re: cryptohoping (fungus)
Re: How protect HDisk against Customs when entering Great Britain (Dave Hazelwood)
addition chains ? (David A Molnar)
Re: Incompatible algorithms (Tom St Denis)
Re: How protect HDisk against Customs when entering Great Britain ("Richard")
Re: How protect HDisk against Customs when entering Great Britain (Anonymous)
Re: How protect HDisk against Customs when entering Great Britain (John Kennedy)
Re: cryptohoping ("ill-omen")
Re: Lenstra on key sizes (Tom St Denis)
----------------------------------------------------------------------------
From: Phunda Mental <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 06 Nov 1999 09:00:34 +0000
Louis wrote:
> > (3) what would be a good "mixing, distilling"
> > algorithm to be applied to the entropy in the snow-files ?
> I don't know, I'm a physicist...
See RFC1750.
In short, if you have 1 bit of entropy/byte in your data you
can XOR all the bits in a byte together to yield one output
bit. If you have more than 1 bit of entropy/byte you can
XOR less bits together to give an output bit. If the data is simply
skewed (as opposed to coorelated) this method works fine.
For coorelated data, use a cryptographic transform (MD5, SHA,
or a symmetric cipher running in CBC mode).
Of course, to find out how many bits of entropy/byte you have
simply take a large sample and apply Shannon's algorithm for
an approximation.
>
> > (4) what would the throughput rate be in bits per second?
> The bandwith of the luminance is safely one MHz.
>
> A problem with using the signal from a video camera is that it would be
> the sum of a "random" part and a periodic
> part. Suppose for example that one pixel in your camera does not
> respond as well to light. Every time the image
> scan would pass through that pixel, the random intensity would be
> decreased and your random bit would have more
> chance of being zero! This would be repeated on every image, always at
> the same location.
The XOR algorithm above will clean up this sort of problem nicely.
> -the random distribution changes as the circuit ages, the change being
> partly random, partly predictable (near the end of its life, the circuit
> may give a "1" for one million "0"; its entropy throughput is likely to
> go down).
Yet another reason to round down when extracting bits from the signal.
> The types of noise distributions encountered in devices have been given
> different names: white noise, flicker noise, drift, pink noise, shot
> noise, phase noise, etc. and can all be present in a given device.
> Therefore, the "mixing, distilling" algorithm should be able to adapt to
> the non-random part of the circuit's output, which is present on every
> time scale. Something the mathematicians should be able to figure out.
A cryptographic transform like MD5 can give a white distribution from
completely predictable input. The following algorithm gives white
output:
H=00000000 // in binary
Z=00000000 // in binary
loop
H = MD5(Z+H) // where + denotes concatenation of the bit
strings, or summation - it doesn't really matter
Write_Out(H)
do_forever
the output from the above algorithm will always be the same, of course
since the initial conditions are constant, but the point is, given
indeterminant
conditions on the inputs, the output will be white.
It is then simply a matter of taking the justified number of output bits
(to assure theoretical randomness), that is if we have 2 bits of entropy
per byte going in to MD5, then we only take 2 from the output.
------------------------------
From: "Mr. Tines" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Sat, 6 Nov 1999 09:23:33 +0000
In article <[EMAIL PROTECTED]>, DigitAl56K
<[EMAIL PROTECTED]> writes
>>I'm considering to be crossing border of Great Britain [ GB ] very soon on
>>business & pleasure trip.
>
>No-one comes here for pleasure at this time of year ;)
>
>>My friend did tell me that GB is scanning in / out coming computers for some
>>specific data / images / information. I'm privacy advocate & can not allow this
>>invasion of privacy to occur to me & my possessions.
>
>Never heard of that, I don't think they can scan your disks unless
>they have reason to suspect illegal material contained on it, however
>I am not a lawyer.
Customs and Excise have all sorts of quaint and curious powers acquired
in the distant past and, like all such venerable institutions, never
actually rescinded. The recipe for a quiet life is not to screw with
C&E.
On the other hand, just yesterday, I returned to the UK from a trip
abroad (within the EU), and walked thorough the blue channel with my
portable, without any let or hindrance (or even any visible C&E staff).
My advice for such travel is - have a bag that is as big as you can get
away with for carry-on. Put the portable in its case in that bag along
with the change of clothing and toothbrush needed in case your hold
baggage goes the scenic route. If you have nothing to declare, go
through the green channel, and only reveal the computer if asked to open
your bags for a spot check.
This also makes it less obvious to opportunists who might fancy
acquiring themselves a free portable.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< http://www.ravnaandtines.com/
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: questions on smart cards
Date: Sat, 6 Nov 1999 20:49:47 +1100
Right now, all authentication occurs using PINs or passwords.
Once the password is verified in some manner, a secondary layer comes into
effect, such as using a digital certificate, or a PKCS #5/12 style password
exchange, or some other forms of access control.
Eventually, biometrics may assist in this area, if the policy and privacy
issues can be acceptably resolved.
In the meantime, most good password verifying mechanisms prevent
unrestricted attempts ie 3 or 5 attempts before the access privelge is
locked - access privilege means a LAN logon, workstation logon, or a
financial transaction etc.
Smartcards used without secure PIN/password entry devices are no better than
no Smartcard at all.
Some links:
http://www.cardtech.faulknergray.com/
http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
http://www.smartcardcentral.com/
http://www.smartcard.co.uk/
http://www.scia.org/
http://www.smartcard.org/
These sites, and the linked sites will add to your background knowledge.
Lyal
David Bernier wrote in message <7vvnmv$dut$[EMAIL PROTECTED]>...
>I'd like to have some introductory Web references
>on smart cards. I don't know how much smart cards
>compare with credit cards, though I do know that
>credit card issuing companies lose millions (billions?)
>a year in credit card fraud. I know that one
>technique relies on swiping the magnetic strip of
>the credit card through a detector and essentially
>cloning it. Also, PIN's typically have 4 or 5
>digits, or no more than 20 bits... PIN's
>can be forgotten, often creating awkward situations.
>They can be read while they are being typed into
>keyboard-type devices. Some people write down their
>PIN's which compromises the security of the credit
>card. Suppose smart cards had to be used with a
>128 bit "PIN" or password; how many people could
>remember reliably such a password? It's like
>remembering a sequence of 21 random characters from
>the standard 64 UUENCODE set... Would 128-bit
>passwords be assigned or chosen? If they were chosen
>by the user, would there be a check for sufficient
>randomness in the PIN or password?
>
>My main question is what protocols, procedures, etc
>are recommended with smart cards, and what is the
>current maximum-value information designed to
>be protected using a smart card? I couldn't
>imagine using a smart card to buy $100,000 of stock,
>say, in a public (or private...) place where there could
>be pin-hole cameras, electro-magnetic radiation
>detectors, and whatever else may have been invented or
>later will be. So if AES is used with smart cards,
>aren't the biggest risks in the physical security, not
>the (eventual) AES algorithm?
>
>David Bernier
>--
>http://homestead.deja.com/mathworld/fish_school.html
>http://homestead.deja.com/mathworld/primes_slow.html
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: U-Boat Enigma Machines
Date: Fri, 05 Nov 1999 13:09:24 -0800
Reply-To: [EMAIL PROTECTED]
U-boat Enigma Machines
I recorded an interesting program last week from a series (I guess)
called the Code Breakers. This recounts the program from memory.
Apparently, the German Army and German Air Force Enigma machines had
been compromised by Britain. But the U-boat fleet had their own
variation of the Enigma and it was proving impossible to crack.
So the British decided to capture a German U-boat. The British had
just developed direction finding equipment. They would monitor U-boat
radio transmissions. They triangulated using very precise direction
finding devices and determined a U-boat location. They sent out
destroyers and laid down a depth charge pattern. They forced the
U-boat to the surface. But before they could board the U-boat, the
German crew had dumped the Enigma machine overboard. But the mission
was not a total loss. The British recovered many documents.
By pouring over these documents it was determined that the Admiral of
Germany's Navy used one central headquarters from which all orders
were transmitted to every ship in the German fleet. It was deduced
that if this was the case, then every ship in the German fleet must
have an Enigma machine. It was decided to locate and attack a German
weather ship.
The British did attack and take one such weather ship. But again the
mission failed but not completely. The British actually recovered a
few rotors from the Enigma machine and more documentation. They
learned that the U-boat Enigma had eight rotors and was impossible
to crack at that time. Using some of these documents the British were
able to partially decrypt some messages.
They then located and attacked another German U-boat. This
mission was successful. The British now had a German U-boat Enigma
machine. The German Admiral apparently did not make the connection
with the loss of their weather ship and submarine with the Enigma.
Soon, sonar became available.
The British were able to destroy (I think) 24 supply submarines that
were used to resupply up to 24 U-boats at sea on each trip.
Of about 840 U-boats in all, the Allies sunk about 760.
At the end of the war, the German Naval Admiral received a brief phone
call from the British and was told that his Enigma machine had been
captured.
------------------------------
Date: 6 Nov 1999 10:31:33 -0000
From: That guy...from that show! <[EMAIL PROTECTED]>
Subject: Re: How protect HDisk against Customs when entering Great Britain
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Reply-To: [EMAIL PROTECTED]
On Sat, 06 Nov 1999 02:36:40 GMT , [EMAIL PROTECTED] (Menial Roky)
wrote
>pgp651 <[EMAIL PROTECTED]> wrote:
>
>>To all offended by my cross posting, I'm very sorry for what you are
>>feeling.
>>My intention was & is to receive help from 2 groups of people [ Privacy
>>& PGP
>>]. I do not consider cross posting to be bad when someone need help.
>
>You could at least tell us which newsgroup you are actually reading, so
>that we can go directly to that group and be sure of reaching you without
>having to cross-post to six different newsgroups.
That would be rather stupid.
a) Others wouldn't know if the question was answered. Duplicate answers
would result in unneccessary usenet traffic.
b) If an incorrect answer is given, most people are locked out of
correcting it
c) The post was appropriate to all of the groups it was crossposted to.
d) If you wanted to be sure of reaching him, and didn't want to crosspost,
there's this new thing we call 'e-mail'. It's the latest rage. Check it
out ya bonehead.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: cryptohoping
Date: Fri, 05 Nov 1999 21:23:12 +0100
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> >
> > In the end though, it doesn't make any difference to security.
>
> There may be important security advantages if you can build a "cipher
> generator" that produces independent ciphers. See:
> http://www.deja.com/threadmsg_ct.xp?AN=539793780
>
No.
It doesn't make any difference how complicated your "algorithm"
is, if the enemy knows it (and you should assume he does) then
it's all down to key sizes.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Sat, 06 Nov 1999 09:46:49 GMT
Where will it end? With customs putting electrodes on your head to
make sure you are thinking only correct thoughts before letting you
in?
Seriously, the day is coming when that will become viable technology.
Did you see the report last week where scientists actually saw through
a cat's eyes by interpreting its brainwaves?
Now is the time to set the limits on invasion of privacy no matter
what the reason for it may be and no matter how great a crime might
be prevented. Later, it will be too late.
I am afraid the future of society depends on it.
Otherwise the future may be a lot worse than even Orwell might have
imagined.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: addition chains ?
Date: 6 Nov 1999 12:16:59 GMT
Does anyone have a pointer to code which finds addition chains for
computing modular powers (or any other reason)? I've come across
references which discuss how to use them to cut down on the number of
multiplications necessary to compute g^a mod n, and am now considering
implementation. So I'm wondering what's already out there...
Thanks much,
-David
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Incompatible algorithms
Date: Sat, 06 Nov 1999 12:43:19 GMT
In article <80031p$8h2$[EMAIL PROTECTED]>,
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> In article <7vvdkm$6dg$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> >You got my point I suppose. MARS implemented three 'levels' of
> >crypto. An initial key mixing, some linear mixing, some crypto
rounds,
> >more linear mixing and key mixing. These three layers are no where
> >near 'compatible' in any sense such as K1 = K2.
>
> And where exactly is the proof that there exists no E2 that is a
> composite of E1 and E:
>
> E2(M) = E1(E(M))
Ciphers like MARS and SAFER would most likely never have keys like that
because a) the decryption algorithm is different, b) the key is shorter
then the round keys. This means not all permutation are possible and
thus the completete decryption permutation is probably prohibited.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "Richard" <[EMAIL PROTECTED]>
From: "Richard" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Sat, 06 Nov 1999 13:23:39 GMT
There was no mention of the quantity of data in the original post to which I
was replying. I'm afraid my helpfulness does not extend to being
clairvoyant.
The point, however, is that if there ARE eight gigabytes of data (the
original post mentioned CD's and Zip disks, all of which would be clumsy for
this amount of data). Perhaps the way around this is to physically ship a
hard disk through the post beforehand, or timed to arrive during the stay. A
hard drive without any surrounding computer would probably not attract
interest from customs at all anyway.
<snip>
> Eight gigabytes?
>
<snip>
------------------------------
Date: Sat, 6 Nov 1999 14:30:09 +0100 (CET)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: How protect HDisk against Customs when entering Great Britain
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dave Hazelwood) wrote:
: Did you see the report last week where scientists actually saw through
: a cat's eyes by interpreting its brainwaves?
Cool. Did everything look like prey? Did they get sound too? Did
everything sound like a can-opener?
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Sat, 06 Nov 1999 08:58:27 -0500
On Thu, 04 Nov 1999 22:33:48 -0600, Piccolo <[EMAIL PROTECTED]> wrote:
>On Fri, 5 Nov 1999 11:23:47 -0000, "Scotty"
><[EMAIL PROTECTED]> wrote:
>
>>How about the following process:
>>1)defragment the drive.
>>2)Use scramdisk calling the file by some random name eg A22487B2.B11
>>3)Wipe all free space,blank directory entries (hence choice of name) and
>>file tails with BCWipe
>>4)Use touch to set your access, creation and modify date/time on the
>>scramdisk file to be the same as BCWipe uses when it wipes bank directories.
>>5)Exit windows and delete it using DOS.
>>6)Don't do anything else to the system.
>>7)Undelete it using DOS when you get to your destination.
>>
>>OK, the only clue that anything is out of place is a deleted directory entry
>>with a starting cluster and size and last access date. Anyone know a utility
>>to delete a file without setting the last access date on the deleted
>>directory entry or delete/set cluster details? If so that would make this a
>>perfect solution, you would just have to make a manual note of the cluster
>>number and size.
>>
>
> I like your idea but the risk is if someone powers up Windows "to
>check out the hard drive" before you restore the file, Windows may
>overwrite the data with its swap file.
>
>The way I'd do it is to set up a second partition on my HD. Create a
>scramdisk partition that's the exact same size. Fill it up. Dismount
>it. Then uninstall scramdisk from the HD and obliterate all traces of
>it.
>
>Next write a DOS utility that uses direct BIOS calls to copy the SVL
>file sector-by-sector to the new partition. This will overwrite any
>FAT on the new partition. As far as DOS/Windows is concerned, it's an
>unformatted partition so I suspect you wouldn't even see it under
>either operating system. The only way it can be accessed is with BIOS
>calls. When you arrive at your destination, a similar DOS utility
>would use BIOS calls to read the partition and DOS calls to write it
>back to the HD. Download scramdisk off the web, reinstall, and you're
>all set.
>
>If someone finds the partition before you decode it - well, it's just
>an unformatted HD partition containing random data.
>
>Another possibility is to write a virus or trojan that eats up HD
>space by creating large files containing random data with about the
>same distribution as a scramdisk .SVL file, release it on the world so
>it becomes well-documented, then infest your system with it... since
>scramdisk's source code is published it wouldn't be difficult for the
>trojan-writer to "borrow" parts of it to create actual encrypted (but
>dismounted and "hidden") volumes.
>
>This is a fun exercise but just remember, "They" are probably reading
>this newsgroup so "They" know of everything that's suggested here.
>
> :-)
Very nice job. This was by far the best answer I've seen that involves
carrying the files in by hand.
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: "ill-omen" <[EMAIL PROTECTED]>
Subject: Re: cryptohoping
Date: Sat, 6 Nov 1999 08:25:49 -0800
yes but if the enemy can't tell the algorithim at first you have a bit of
time before he can i dentify it an use his creack when you cuombinge thins
over a large sipher text with a whole bunch of algorithms that are only used
for very small sets of data you make the enemys job that much harder this
i dea was never for longterm encryption its more for here and now
communication were you need a gaurnted security for a fiarly short time
fungus <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > fungus <[EMAIL PROTECTED]> wrote:
> > >
> > > In the end though, it doesn't make any difference to security.
> >
> > There may be important security advantages if you can build a "cipher
> > generator" that produces independent ciphers. See:
> > http://www.deja.com/threadmsg_ct.xp?AN=539793780
> >
>
> No.
>
> It doesn't make any difference how complicated your "algorithm"
> is, if the enemy knows it (and you should assume he does) then
> it's all down to key sizes.
>
>
> --
> <\___/>
> / O O \
> \_____/ FTB.
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Lenstra on key sizes
Date: Sat, 06 Nov 1999 14:24:34 GMT
> It was, with the technology at that time. Then it was estimated to
> take a few billion years to factor a 512-bit RSA modulus. Today,
> 25 years later, it can be done in 7 months...
>
> This should be of great concern to anyone claiming some encryption
> will take billions of years to crack, and where it's relly important
> no-one will be able to crack it during at lest the next few decades...
That's why these estimates are rarely taken as truths. I like to see
them cuz they are pretty tables, you can quote them and they make you
sound informed. Anyone who was truly informed [I am only quasi-
informed] would know that these tables are examples only.
True using the current state of the art NFS or GFNS it's hard to tackle
a DL for example. This doesn't mean special hardware or new algorithms
won't be invented tommorow.
On the flipside, I hate when people think it's a linear scale. 768-bit
composites are not 1.5 times harder then 512-bit composites. This type
of malicious type casting is insane. The matrix step in both
algorithms grows [exponentially?] with the size of the number, not
linearly. I think 768+ RSA for example should be deemed strong at
least until something in the ~650 range gets tackled, then you could be
assured 768 is the next...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
