Cryptography-Digest Digest #50, Volume #11 Fri, 4 Feb 00 09:13:01 EST
Contents:
Re: Strip Security (Gordon Walker)
Re: Challenge: Who can discover the encryption used here? (Volker Hetzer)
Re: Is RC6 a more advanced design than CAST/IDEA...? (Volker Hetzer)
Re: ascii to binary ("ink")
Re: Strip Security ([EMAIL PROTECTED])
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: Strip Security (Highdesertman)
Re: How to choose public-key e on RSA? (Tom St Denis)
Re: Is RC6 a more advanced design than CAST/IDEA...? (Tom St Denis)
Re: Challenge: Who can discover the encryption used here? (Tom St Denis)
Re: Court cases on DVD hacking is a problem for all of us (Geoff Lane)
Re: Court cases on DVD hacking is a problem for all of us (Ian Hay)
Re: How to password protect files on distribution CD (Roger Gammans)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Gordon Walker)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Fri, 04 Feb 2000 09:33:16 GMT
On Sun, 30 Jan 2000 23:38:38 GMT, [EMAIL PROTECTED]
(Highdesertman) wrote:
>IDEA is a block cypher. My understanding of block cyphers is that by
>their nature, the password is removed from the actual encrypting key,
>the key being generated by the algorythm itself.
The key is generated, but it can only be generated from what you give
it. See below.
>I don't believe your estimate of the resources required to crack IDEA
>is accurate. You are correct in pointing out that the security of the
>application is dependent on the proper implementation of the algorythm
>and the design of the program. But assuming the above has been done
>properly, I don't believe that cracking IDEA is quite so easily done.
I don't think cracking IDEA would be easy either, in fact I doubt even
the NSA could do it. What I'm saying is that one of the primary
reasons for IDEA's security is that there are 2^128 possible keys. If
the algorithm is robust then the only way to break it is a brute force
assault, trying every possible key. With so many keys that is
infeasible. This is the source of its strength.
However, the downside is the need to remember a fourty digit number
for your key. Clearly few people can do this so what is normally done
is that you enter an easily remembered pass phrase and the code
expands this to the needed 40 digit number using some kind of hash
function. Eg. by converting the letters to the hexidecimal form of
their ASCII values and combining them. Thus "AAA" becomes the hex
value 414141 or 4276545 in decimal. However, you can see that by using
just three characters in the pass phrase the range of numbers possible
is just one to about 16 million. If you use only the alphabetic
characters not all of these can be generated reducing the range yet
again. In other words, so long as you only use three characters in
your pass phrase an attacker need only try 16 million options to find
the key - a trivial operation on a PC.
To retain the full security of IDEA you need to use a passphrase that
encompasses the full range of 2^128 possible keys. As I mentioned
before, that entails a 24 character password including spaces and some
numbers. If you use less than this, you and not the Strip application
are limiting the power of the IDEA algorithm.
Remember also, that even if you use a 24 character password it is
likely that you will use normal english words. This means that the
content is less random than it could optimally be. An attacker may
make use of a dictionary attack by throwing combinations of english
words together to try to pull out the key. This is entremely hard but
much easier than finding a truly random 2^128 value. It's one of the
reasons to throw in a few numbers into the key.
In contrast, PGP's solution to this is what it calls a keyring file.
When you generate your key it is a truly random number generated by
your random activity on mouse and keyboard. This number, which you
have no chance of memorising, is stored in the keyring. The keyring is
then encrypted with a pass phrase you supply. The keyring's security
is necessarily much lower than that of the main encryption engine.
Thus when you encrypt or decrypt using PGP the pass phrase you enter
is not the key used to scramble the message. Rather it simply makes
available the real key that will be used. This is why, in PGP,
physically securing the keyring file is of paramount importance.
>Anyway, I am getting off topic. My point is this: Strip should be
>secure enough for any common application, IMHO. If you have
>information in your palm that you fear will fall into the hands of the
>NSA (and you have reason to believe they would want that information
>to begin with) then I'm not sure using a palm to store it would be
>such a good idea in the first place. But for keeping credit card
>numbers, accounts, and logons, it should be just dandy.
Even in light of what I say, I still agree 100% with this conclusion,
just so long as you arn't using a four letter, alphanumeric key. To
feel comfortable I'd still recommend a phrase of at least 10-12
characters containing some numbers.
After all if I loose my Palm it has to be found by someone who is (1)
dishonest, (2) knowledgable about Palm applications, (3) aware of Stip
and what it may contain, (4) able to utilise the possible weaknesses
in my key selection to mount a successful assault on the encryption.
This improbability of this, together with the power of the key I have
chosen leaves me quite confident.
--
Gordon Walker
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Challenge: Who can discover the encryption used here?
Date: Fri, 04 Feb 2000 09:59:17 +0000
TJ wrote:
> Still, you seem to have missed the point. Software piracy? Who mentioned
> that? I deal with trainers and patches and mods for games.
> To alter a specific section of a certain game, I need to be able to decrypt
> a text file, alter it, and then re-encrypt it.
What about contacting the guys who wrote it?
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Is RC6 a more advanced design than CAST/IDEA...?
Date: Fri, 04 Feb 2000 10:01:53 +0000
James wrote:
>
> RC6 is a very simple and compact on implementation. It uses no s-box and runs very
>fast.
> So I'm curious if RC6 is more advanced than CAST/IDEA from the cryptographical view.
Depends on what you mean by "advanced". It certainly is newer.
However, if I had to choose a symmetric cipher I'd wait a few more weeks until
the AES process has finished. Then I'd choose the winner. RC6 is in the finals,
but IMVHO unlikely to win.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Fri, 4 Feb 2000 11:04:12 +0100
Paul Schlyter schrieb in Nachricht <87e0qb$4sk$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
>NFN NMI L. <[EMAIL PROTECTED]> wrote:
>>Gaaaach. Look at all the cruddy C code.
>>
>>In any case, ASCII is stored as binary. Maybe you C (scoff) people think
of
>>ASCII as 0-255, but I've always though of it as 8-bit binary codes
>
>Even on systems where one bye isn't 8 bits, but instead 6, 7, 9 or 12 bits?
How many are there?
K In Albon
------------------------------
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Reply-To: [EMAIL PROTECTED]
Date: Fri, 04 Feb 2000 10:10:33 GMT
Gordon Walker? ([EMAIL PROTECTED]?) wrote (Fri, 04 Feb 2000 09:33:16 GMT):
>After all if I loose my Palm it has to be found by someone who is (1)
>dishonest, (2) knowledgable about Palm applications, (3) aware of Stip
>and what it may contain, (4) able to utilise the possible weaknesses
>in my key selection to mount a successful assault on the encryption.
>This improbability of this, together with the power of the key I have
>chosen leaves me quite confident.
I think he could just look you up, threaten your life, and you spill
the key. Ever had your fingernails pulled off? In other words, you're
likely the weakest link, IF you have anything worth looking you up.
Ad: Want transparent encryption in a database engine? Check out Bullet.
Available in several platform flavors, including even CE.
'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'
Corne1 Huth http://40th.com/ Bullet database engines/servers
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Fri, 04 Feb 2000 05:26:50 +0000
On 4 Feb 2000 08:59:21 +0100, [EMAIL PROTECTED] (Paul Schlyter) wrote:
>In article <[EMAIL PROTECTED]>,
>NFN NMI L. <[EMAIL PROTECTED]> wrote:
>><<They purport that the NSA has ALL POSSIBLE keys for PGP>>
>>
>>Yes. Now, the question is, where is the NSA hiding their hard drive? It'll
>>make exabyte storage capacities look like bits of fluff.
>
>It indeed would: even if the NSA had the entire universe at their
>disposal, and was able to store one bit in each and every atom,
>that wouldn't be enough.
If they could store one entire key in each atom, they would still fall
short.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Highdesertman)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Fri, 04 Feb 2000 11:09:28 GMT
Reply-To: [EMAIL PROTECTED]
Thanks Gordon for the clarification. I now understand better the
meaning of your original message.
One of the things that has always nagged at me in my quicken online
banking, is the fact that the RSA encryption used to secure the
internet connection with the quicken processing center limits the
password to a four digit numeric combination. In my way of thinking,
very easy to crack. Unless of course, there is some magic that quicken
is doing to exponenetially increase the security of that PIN number.
cheers,
Mathew
On Fri, 04 Feb 2000 09:33:16 GMT, [EMAIL PROTECTED] (Gordon Walker)
wrote:
>On Sun, 30 Jan 2000 23:38:38 GMT, [EMAIL PROTECTED]
>(Highdesertman) wrote:
>
>>IDEA is a block cypher. My understanding of block cyphers is that by
>>their nature, the password is removed from the actual encrypting key,
>>the key being generated by the algorythm itself.
>
>The key is generated, but it can only be generated from what you give
>it. See below.
>
>>I don't believe your estimate of the resources required to crack IDEA
>>is accurate. You are correct in pointing out that the security of the
>>application is dependent on the proper implementation of the algorythm
>>and the design of the program. But assuming the above has been done
>>properly, I don't believe that cracking IDEA is quite so easily done.
>
>I don't think cracking IDEA would be easy either, in fact I doubt even
>the NSA could do it. What I'm saying is that one of the primary
>reasons for IDEA's security is that there are 2^128 possible keys. If
>the algorithm is robust then the only way to break it is a brute force
>assault, trying every possible key. With so many keys that is
>infeasible. This is the source of its strength.
>
>However, the downside is the need to remember a fourty digit number
>for your key. Clearly few people can do this so what is normally done
>is that you enter an easily remembered pass phrase and the code
>expands this to the needed 40 digit number using some kind of hash
>function. Eg. by converting the letters to the hexidecimal form of
>their ASCII values and combining them. Thus "AAA" becomes the hex
>value 414141 or 4276545 in decimal. However, you can see that by using
>just three characters in the pass phrase the range of numbers possible
>is just one to about 16 million. If you use only the alphabetic
>characters not all of these can be generated reducing the range yet
>again. In other words, so long as you only use three characters in
>your pass phrase an attacker need only try 16 million options to find
>the key - a trivial operation on a PC.
>
>To retain the full security of IDEA you need to use a passphrase that
>encompasses the full range of 2^128 possible keys. As I mentioned
>before, that entails a 24 character password including spaces and some
>numbers. If you use less than this, you and not the Strip application
>are limiting the power of the IDEA algorithm.
>
>Remember also, that even if you use a 24 character password it is
>likely that you will use normal english words. This means that the
>content is less random than it could optimally be. An attacker may
>make use of a dictionary attack by throwing combinations of english
>words together to try to pull out the key. This is entremely hard but
>much easier than finding a truly random 2^128 value. It's one of the
>reasons to throw in a few numbers into the key.
>
>In contrast, PGP's solution to this is what it calls a keyring file.
>When you generate your key it is a truly random number generated by
>your random activity on mouse and keyboard. This number, which you
>have no chance of memorising, is stored in the keyring. The keyring is
>then encrypted with a pass phrase you supply. The keyring's security
>is necessarily much lower than that of the main encryption engine.
>Thus when you encrypt or decrypt using PGP the pass phrase you enter
>is not the key used to scramble the message. Rather it simply makes
>available the real key that will be used. This is why, in PGP,
>physically securing the keyring file is of paramount importance.
>
>>Anyway, I am getting off topic. My point is this: Strip should be
>>secure enough for any common application, IMHO. If you have
>>information in your palm that you fear will fall into the hands of the
>>NSA (and you have reason to believe they would want that information
>>to begin with) then I'm not sure using a palm to store it would be
>>such a good idea in the first place. But for keeping credit card
>>numbers, accounts, and logons, it should be just dandy.
>
>Even in light of what I say, I still agree 100% with this conclusion,
>just so long as you arn't using a four letter, alphanumeric key. To
>feel comfortable I'd still recommend a phrase of at least 10-12
>characters containing some numbers.
>
>After all if I loose my Palm it has to be found by someone who is (1)
>dishonest, (2) knowledgable about Palm applications, (3) aware of Stip
>and what it may contain, (4) able to utilise the possible weaknesses
>in my key selection to mount a successful assault on the encryption.
>This improbability of this, together with the power of the key I have
>chosen leaves me quite confident.
>--
>Gordon Walker
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How to choose public-key e on RSA?
Date: Fri, 04 Feb 2000 12:04:52 GMT
In article <vKBm4.4002$15.29537@news>,
"Miryadi" <[EMAIL PROTECTED]> wrote:
>
> Tom St Denis wrote in message <87cu7t$1e$[EMAIL PROTECTED]>...
> >
> >You are right, it will not always be relatively prime... shortest
> >example is if
> >
> >p = 2e + 1 or q = 2e + 1 [for example]...
> >In this case just make new primes...
> >
> So, you mean that I better search for new p and q, with that fixed e,
> rather than try to search for new e that is relatively prime to (p-1)*
(q-1).
>
There are reasons for having a fixed 'e' [of special construction].
Can you tell me why? [do a little research].
So yes, choosing new primes is a better idea.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is RC6 a more advanced design than CAST/IDEA...?
Date: Fri, 04 Feb 2000 12:02:26 GMT
In article <87dhpu$rup$[EMAIL PROTECTED]>,
"James" <[EMAIL PROTECTED]> wrote:
> RC6 is a very simple and compact on implementation. It uses no s-box
and runs very fast.
> So I'm curious if RC6 is more advanced than CAST/IDEA from the
cryptographical view.
>
What do you mean by more advanced? Do you mean efficiency? Security?
As far as anyone is concerned they are practically equal in the
security domain.
RC5/RC6 are very well designed [to use little memory] but CAST is a
simple cipher as well [not simple to make the sboxes]. IDEA is
probably the most confusing to try and code.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Challenge: Who can discover the encryption used here?
Date: Fri, 04 Feb 2000 12:08:26 GMT
In article <ciom4.1954$[EMAIL PROTECTED]>,
"TJ" <[EMAIL PROTECTED]> wrote:
> Read the FAQ before I posted, have you? All of it? Boring as hell
aint it?
> And, lets face it, largely irrelevant. Hell, its the 21st
century....:O)
>
> Still, you seem to have missed the point. Software piracy? Who
mentioned
> that? I deal with trainers and patches and mods for games.
> To alter a specific section of a certain game, I need to be able to
decrypt
> a text file, alter it, and then re-encrypt it.
> If you know of another group with as many subscribers of people who
may be
> up to the challenge, then perhaps you would be so kind as to point me
in the
> right direction. I only found this group after a search on the www.
>
> Thanks
>
> TJ
No, I think your goal is software piracy.
> > > I have a copy of both versions, and my question is this;
> > > Who can discover the encryption method used?
Which means one copy is a newer version right? If you were allowed to
run the other copy then you would not be posting here.
Also the file is probably not encrypted. It's just in a specific file
format you don't recognize.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Geoff Lane)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: 4 Feb 2000 13:02:41 GMT
In article <87d8js$d70$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Xcott Craver) writes:
> o DeCSS cracks the DVD encryption program, allowing someone
> to watch their DVDs without using a mandated set-top box.
> This lets people watch their DVDs in non-Windows operating
> systems, for instance. This is not clearly piracy or theft.
As all the information to unscramble the data is already in the hand of the
end user (it's just hidden away) calling CSS a form of encryption is going
too far.
Once you could view a DVD under windows all pretence to maintaining the CSS
method a secret was lost -- even if all the keys had been correctly encoded
the data would have been extracted quite quickly by somebody with the time,
a debugger and a bus snooper.
--
Geoff. Lane. | Today's target: 47.639963 N; 122.130295 W. Fire at Will!!
Today's Excuse:
US West
------------------------------
From: Ian Hay <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Fri, 04 Feb 2000 13:41:59 GMT
Xcott Craver wrote:
> o DVD encryption is not there to prevent illegal copying.
> It does not prevent illegal copying. A pirate will copy
> the whole DVD without breaking the encryption, and the copy
> will play in a DVD player. Encryption doesn't even slow him down.
Sorry to butt in, but this seems to be a point of contention. Isn't the
above statement (while widely believed) specifically untrue? My
understanding of the description of the technology involved is that the
encrypted key, read by the software or hardware DVD player, is on a
specific area of the distributed DVD that is otherwise pre-embossed on
writeable DVDs. So an attempt to do a bit-for-bit copy results in
unreadable copy missing that small section of the data.
Increasingly OT, but I'm curious. Is the above correct?
I.
--
____
| | Ian R. Hay <http://www3.sympatico.ca/ian.hay/>
|____| Toronto, Canada <mailto:[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: Fri, 04 Feb 2000 13:42:39 GMT
In article <87dhke$6ok$[EMAIL PROTECTED]>, Vernon Schryver wrote:
>In article <[EMAIL PROTECTED]>,
>Eric Lee Green <[EMAIL PROTECTED]> wrote:
>
>> ...
>>Regarding leaving old cards in machine, I don't know of a reliable way to get
>>the MAC address of a second card under Linux or SCO Unix. For that matter,
>>there's "magic" involved in getting the MAC address of the FIRST card.
>
>That sounds unlikely to me. I'm too lazy to check my copies of
>Linux and can't conveniently check SCO Unix, but as I recall from
>porting the relevant bits, no such magic is required for a system
>compatible with 4.4BSD-Lite.
Indeed, I've just done:-
knuth:~$ ifconfig -a | grep HWaddr
eth0 Link encap:Ethernet HWaddr 00:20:18:8B:14:E3
vmnet1 Link encap:Ethernet HWaddr 00:50:56:8A:00:00
vmnet0 Link encap:Ethernet HWaddr 00:50:56:80:00:00
Which doesn't exactly *prove* second NICs mac address is easy to find but
I'm pretty sure it appears in ifconfig's info.
--
Roger
------------------------------
** 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
******************************
