Cryptography-Digest Digest #968, Volume #11 Wed, 7 Jun 00 11:13:01 EDT
Contents:
Re: Is OTP unbreakable?/Station-Station (Tim Tyler)
Re: software protection schemes (Jim Steuert)
BeeCrypt 1.0.0 released (Bob Deblier)
Re: Question about recommended keysizes (768 bit RSA) ("Thomas J. Boschloo")
DH-Key Exchange Questions. ([EMAIL PROTECTED])
Enigma Variations (John Spicer)
Re: DH-Key Exchange Questions. (Anton Stiglic)
Re: Thoughts on an encryption protocol? (Dido Sevilla)
Re: DH-Key Exchange Questions. (Mark Wooding)
Re: Observer 4/6/2000: "Your privacy ends here" (me)
Re: testing non linearity of arithmetic-logic combinations ("Dark Nebular")
Re: Request for review of "secure" storage scheme (Baruch Even)
Re: Question about recommended keysizes (768 bit RSA) (Paul Koning)
Re: Some citations (Paul Koning)
vb crypto library ("norman")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?/Station-Station
Reply-To: [EMAIL PROTECTED]
Date: Wed, 7 Jun 2000 13:25:59 GMT
Nicol So <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson <[EMAIL PROTECTED]> wrote:
:> : The method presented by ciphermax is flawed, but a one-time
:> : random key does offer provable authentication, and no other
:> : technique does.
:>
:> The scheme you describe - like other sorts of "provable" security does
:> not actually /prevent/ the possibility of faking identity. Instead it
:> tries to reduce it to 1/S.
: I don't think Bryan Olson characterized the protection offered by the
: scheme as "prevention". He only referred to it as "provable", which is
: true. [...]
It's true only in an abstract, mathematical world.
In the real world, there's no guarantee of being able to produce a
"random key" in the first place - and this is the world where authenticity
is actually important.
:> The "proof" also depends on an unprovable assumption - the existence of an
:> unguessable random stream.
: I think there is some confusion here. [...]
: Apparently, your objection is that there might not be anything in the
: physical world of which a sequence of independent, uniformly distributed
: 0-1 variables is a good model. That's a fair question, but that has
: nothing to do with proofs. [...]
: You seem to be very skeptical about the existence of "unguessable random
: streams". What kind of evidence would it take to convince you that
: physical phenomena exist that correspond (closely) to idealized unbiased
: coin flips? [...]
I beleive a "close" correspondence may well exist in some cases, but...
IMO, the question of whether such a stream can be generated for
cryptographic purposes (in the face of an active attacker) is far
from resolved.
: Your "standard of proof" seems to be very high. If you look
: at other things in everyday life, you'll find that we accept
: mathematical models as _adequate_ based on much lower standards than
: yours. We know that Newtonian mechanics is only approximate, yet we
: build cars, bridges, buildings etc on it.
Nobody claims to have **proved** that these bridges won't fall down.
An academic with such a "proof" would undoubtedly be ridiculed.
:> These sorts of concern always make me uneasy about the use of the term
:> "provable" in relation to secrecy, or authentication.
:>
:> It seems to me that "provable" security is almost a sort of academically-
:> respectable snake-oil marketing technique :-|
: The term "provable" does mean something--rigor of reasoning in the
: mathematical model. Unfortunately, many researchers use the term to
: refer to results that don't guarantee what a reader might expect when
: he sees the word "provable".
It seems to me that more qualifications are needed.
I see textbooks referring to the OTP as "provably" secure, and
an "unbreakable" crypto system.
Only rarely does it get mentioned that without a secure source of
randomness - something which has never been demonstrated to exist - these
systems are not secure, let alone "provably" secure.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ I'm pink :. I'm spam
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: software protection schemes
Date: Wed, 07 Jun 2000 09:58:15 -0400
I actually coded one of those schemes for Solaris. Here's how it worked:
1. It used /proc file system ioctl() calls to hook the read,write,open,
access, lseek, etc calls. This is similar to the way truss, strace (public
domain), and debugger packages work for various unixes.
2. It used the solaris processor id (there is an faq on spoofing this) and
other "tricky" means of identifying the specfic client machine. A
client must issue a command which generates a machine-specific
code, and then is given a corresponding key which would only
work on that machine.
3. For example, my "runner" program in turn ran a specific executable
with a complete set of encrypted files. The files are never left
un-encrypted on any media. This prevents "casual" copying
of plaintext files by unauthorized users. For a large network
(NFS or internet) with unsure environment, this is a real threat.
Nothing prevents a paying customer from letting another person
watch (or take a picture of) his data displayed on his own computer's
screen. I can think of a lot of ways to defeat this, but with some effort.
Is this secure? No. Is it of some value? Yes.
RecilS wrote:
> They don't all currently suck. All mass-market schemes suck simply because
> they do not have the time to tailor computer-specific protection. An actual
> recompilation of source (not a key-code algorithm) which relies upon the
> processor's ID to decrypt necissary code seems to work for me.
> Remember though, nothing is completely secure and if someone wants it bad
> enough there will always be a way to take it.
>
> - RecilS
>
> tomstd <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In article <aef%4.112$_l.9008@bgtnsc06-
> > news.ops.worldnet.att.net>, "maxim" <[EMAIL PROTECTED]> wrote:
> > >Does anyone know where I can find some ratings on software
> > protection
> > >schemes (particularly the ones that do not rely on a dongle)
> > >thanx,
> > >max
> >
> > Simple. They all currently suck. They are all based on
> > security-via-obscurity which rarely works for a prolonged
> > ammount of time.
> >
> > Tom
> >
> >
> > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
> *
> > The fastest and easiest way to search and participate in Usenet - Free!
> >
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto
Subject: BeeCrypt 1.0.0 released
Date: Wed, 07 Jun 2000 16:10:26 +0200
Hi all,
I am pleased to announce the first non-beta release of BeeCrypt, Virtual
Unlimited's open source cryptography library. Changed from last release
are:
- Added Win32 support; the library compiles as a DLL.
- Added Pentium/Pentium Pro assembler version of SHA-1 (>60% faster)
- Fixed minor bugs in entropy providers.
For more information, see http://beecrypt.virtualunlimited.com/
Enjoy
Bob Deblier
Virtual Unlimited
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Wed, 07 Jun 2000 16:11:50 +0200
Jerry Coffin wrote:
>
<s>
> I won't bother with another follow-up like this: far be it from me to
> spend more time and effort simply to force you to admit that you were
> and are wrong -- I think intelligent people reading the thread have
> enough information to realize that your comparison and conclusions
> were inaccurate. Unless you're willing to change your ways and add
> something substantive to the thread, there's no real point in
> continuing it.
Please don't let it end like this, the least you could do is agree to
disagree. I think that back in 1980 computers were very expensive, but
not because they were or weren't high end, but because we didn't have
the industry, competition and market share to keep prices low like they
are now!
When I left the vrije university in Amsterdam, they just got a computer
matrix consisting of a hundered or so pentium pro's. They are just mass
produced now, what makes them relatively cheap.
High regards,
Thomas
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED]
Subject: DH-Key Exchange Questions.
Date: Wed, 07 Jun 2000 14:11:16 GMT
I've been playing with DH-Key exchange and come across few problems
with large numbers before doing the mod part.
So my question is :
how big does the prime have to be before it starts becoming difficult
to break?
Thanks,
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 07 Jun 2000 09:01:59 +0100
From: John Spicer <[EMAIL PROTECTED]>
Subject: Enigma Variations
There is a vast wealth of literature and folklore on how the British
broke the Enigma at Bletchley Park in the Second World War and the
successes against the Japanese codebooks, but other aspects of cipher
use are less well covered.
In particular, I was reading an account of the Battle of the Atlantic
and was surprised to see a statement that the Germans were able to
decipher signals sent from lone merchantmen to the Admiralty and thus
discover their intended route.
This led me to wonder what was the state of the cryptography used by the
Allies and what in-roads had the Germans and Japanese made? Did the
Allies learn from their successes against the Axis cryptos and
strengthen their own, or did they fall into the same traps?
If anyone has any ideas on this or can point me to any books or
published accounts, I would be grateful.
John Spicer
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: DH-Key Exchange Questions.
Date: Wed, 07 Jun 2000 10:31:59 -0400
[EMAIL PROTECTED] wrote:
>
> I've been playing with DH-Key exchange and come across few problems
> with large numbers before doing the mod part.
>
> So my question is :
>
> how big does the prime have to be before it starts becoming difficult
> to break?
>
> Thanks,
The best known algorithm used for factoring can also be used for
computing
discreet logs (and thus can be used to break DH). There is no
theoretical
connection between factoring and computing desecrate logs in a group mod
a prime
that has been proven yet, but the best algo that we know now just
happens
to do both jobs.
512 bit integers have been factored (see for example
http://www.rsalabs.com/challenges/factoring/rsa155.html )
so you should not use a 512 bit modulus for RSA for example, nor should
you
use a 512 bit prime for DH.
You could use a 768 bit prime, but people find more safety in 1024 bits.
For long future needs, use 2024 bits.
See for example RSA Labs Bulletin #13, "New Key Size Analysis", which
you can get from http://www.rsalabs.com/
Anton
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Wed, 07 Jun 2000 22:32:15 +0800
Volker Hetzer wrote:
> So it's a secret key protocol. Are there any constraints that forbid
> the use of public key stuff?
One of the problems with public key crypto that I'd like to avoid are
patents (not that they apply where I live...). Also, symmetric block
ciphers tend to be much simpler to code than asymmetric public-key
systems. I only have one year and 32 KB code size on my 80186-based
embedded system to fit everything, so all the firmware may probably have
to be in pure assembly language...
> How do you change keys over the lifetime of your devices?
>
Basically, some high-ranking person will go to each terminal, swipe a
special card across its barcode swipe reader, punch in a password, and
then punch in the new start key. This would be done every three months.
> > system, no key information is ever transmitted across the network.
> Well, the problem is thatas soon as an attacker gets hold of *any*
> of the thus generated keys he can create all keys after that.
> Why not use a stream cipher or cryptographically secure PRNG to
> generate the session keys?
>
Where can I find information on any of these entities?
> Should work as long as the number of messages desn't get too large.
>
Each terminal will probably generate about 8-10 transactions every day
at the most. So in the three months between key changes, up to 1200
messages may elapse. each message being up to 100K in size or so.
>
> > Are there any suggestions for improving the
> > security of this protocol?
> See above.
>
Thank you very much!
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
Mobile Robotics Laboratory +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DH-Key Exchange Questions.
Date: 7 Jun 2000 14:43:01 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've been playing with DH-Key exchange and come across few problems
> with large numbers before doing the mod part.
This sounds like you're doing it wrong. Do the modular reduction after
each multiplication. You need a multiprecision maths library of some
kind to deal with (at least) 700-odd bit numbers.
-- [mdw]
------------------------------
From: me <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Wed, 7 Jun 2000 09:43:57 +0100
Reply-To: me <[EMAIL PROTECTED]>
>When you wake on Thursday 5 October next, you will find yourself living in a
>different country. An ancient bulwark of English law - the principle that
>someone is presumed innocent until proven guilty - will have been
>overturned. And that is just for starters. From that date also the police
>and security services will enjoy sweeping powers to snoop on your email
>traffic and web use without let or hindrance from the Commissioner for Data
>Protection.
http://www.udhr50.org/UDHR/default.htm
Universal Declaration of Human Rights
...
Article 11
(1) Everyone charged with a penal offence has the right to be presumed
innocent until proved guilty according to law in a public trial at which
he has had all the guarantees necessary for his defence.
(2) No one shall be held guilty of any penal offence on account of any
act or omission which did not constitute a penal offence, under national
or international law, at the time when it was committed. Nor shall a
heavier penalty be imposed than the one that was applicable at the time
the penal offence was committed.
Article 12
No one shall be subjected to arbitrary interference with his privacy,
family, home or correspondence, nor to attacks upon his honour and
reputation. Everyone has the right to the protection of the law against
such interference or attacks.
...
Adopted on December 10, 1948
by the General Assembly of the United Nations (without dissent)
--
------------------------------
From: "Dark Nebular" <[EMAIL PROTECTED]>
Subject: Re: testing non linearity of arithmetic-logic combinations
Date: Wed, 07 Jun 2000 14:50:10 GMT
I was wondering.... is the Linear Correlation function good enough to test
linearness?
JULIEN DERIVIERE - SPIRITED J. DERIVIERE ([EMAIL PROTECTED]) ICQ# :
27913909 -------------------------------------------------------------- The
SPIRITED Homepage http://www.spirited.fr.fm You can subscribe to the
SPIRITED Newsletter by sending a blank e-mail to
[EMAIL PROTECTED] ----------------------------------------
======================
tomstd <[EMAIL PROTECTED]> a �crit dans le message :
[EMAIL PROTECTED]
> In article <[EMAIL PROTECTED]>, "cranky cransky"
> <[EMAIL PROTECTED]> wrote:
> >could somebody point me towards some research, if there is any,
> on non
> >linearity or linearity of certain chip level operations
> (addition,
> >subtraction, xor, shift, etc..) i was thinking of coding
> something to try
> >different combinations of these operands on integers and
> examine the
> >results for the combinations that produce the most non
> linearity. is such an
> >extensive test necessary? is this a well worn path? is it
> possible to
> >examine the nature of the function itself ( like boolean logic,
> or addition
> >axioms or whatever ) and work it out, instead of
> testing????!?!?!
> >aaargh...anywho, help appreciated.
> >
>
> Simple. Build a table using your arithmetic operations then
> perform the WalshTransform (or FWT) on it. it will give you the
> linearness of it.
>
> Tom
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: Baruch Even <[EMAIL PROTECTED]>
Subject: Re: Request for review of "secure" storage scheme
Date: Wed, 07 Jun 2000 15:31:19 +0200
A simpler method could be used in my opinion.
Most probably the user has a userid and password, and I assume so
for this scheme.
It should be noted that when you deal with credit card numbers
and any other sensitive infomation you should be carrying this
steps in SSL/TLS (i.e. encrypted by the browser), you should further
note that you can mark cookies to be sent ONLY over encrypted
channels and for a cookie that carries sensitive informations this
should be used.
Assuming that you have SSL for this whole session you can simply
hash the password that the user gives you (possibly together
with his userid and a fixed salt), cut the sensitive data in two
encrypt one part with half of the hash result as key and encrypt
the other part with the other half hash result.
SHA-1a hash give a 168 bit result to the best of my knowledge
and thus is not enough to give large enough number of bits for the
keys. What you can do is use two different fixed salts, or hash the
first result to get the second (possibly with another fixed salt).
The encryption can be any AES finalist and thus will be much
faster than any PK crypto-system around.
A problem with the method you suggest is that PK (specifically RSA)
normally are considered secure for RANDOM data, your data is
not random so you would be required to pad it with random data
before RSA encryption.
Another option is to use a single key and encrypt the two blocks
with the same key, possibly in one of modes of operation (CBC
or OFB comes to mind).
See also some comments below.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Rodd Snook) wrote:
> Hi,
>
> I'm looking for advice on a scheme that I have cooked up for storing
> sensitive customer data (i.e. credit-card numbers) in a fairly secure
> format in a web-based environment. I'd like to know if there are any
> obvious holes in the procedure, what encryption algorithm (asymmetric) I
> should use, and whether I will weaken this algorithm by my
> manipluations.
>
> I know that storage of card numbers is, in general, a bad idea. However,
> the storage is provided for the users' convenience and is at their own
> discretion.
>
> So, without further ado, here is my plan:
>
> Aim:
> To provide for the storage of customer credit-card numbers in the
> most secure manner possible.
>
> Premises:
> 1. No single machine should have sufficient information in permanent
> store to recover a customer credit card number
> 2. No single machine should have unrestricted access to a permanent
> store of information that is sufficient, in combination with data
> stored on the machine in question, to recover a customer credit card
> number.
>
> Storage:
> 1. The credit card number is supplied by an authenticated customer.
>
> 2. The card number is tested for checksum validity.
>
> 3. Provided that the number passes the checksum test, the check digit
> is removed from the number (since redundancy is a hint to plaintext)
>
> 4. The remainder of the card number is converted to a packed format
> (e.g. hex encoding of integer or BCD number) and combined with some
> padding and length information, in a parseable format(1). For
> increased defence against differential cryptanalysys the position
> of the card number within the string should be varied randomly.
>
> 5. The combined string is encrypted by the web server using a
> public-key encryption algorithm, encoded in a printable format
> (string) and the result split into two parts.
>
> 6. One of the two parts is appended to a customer-supplied
> cookie containing other such fragments and returned to the customer.
>
> 7. The remaining part is passed to the database for storage with the
> customer's other details.
>
> Retrieval:
> 1. The fragment of encrypted data corresponding to the card number
> requested by the customer is retrieved from the cookie.
>
> 2. The fragment, together with sufficient information to identify
> both the user and the particular card requested is passed to the
> database server.
>
> 3. The database server concatenates the supplied fragment with the
> stored fragment and decrypts the result with the key complementary to
> that used for the encryption at point 5 of the previous section.
>
> 4. The plain-text card details are returned to the web server.
>
> 5. The web server uses the length information to strip the padding,
> then calculates the check digit for the card number.
>
> Weaknesses:
> 1. All data are encrypted with a single public/private key pair.
> 2. Card details are passed in clear text from the database server to
> the web server.
Using SSL and cookies over SSL solves this.
> 3. Revealing part of the ciphertext in the cookie would allow a
> brute-force attack -- provided that the format of the plaintext
> string is known to the attacker.
Brute force attack here are useless since there are many possibly
combinations quite a few of them correct and the attacker will never know
which one corresponds to this users cc.
>
> Strengths:
> 1. The possibility of an attacker making use of some form of
> differential crypanalysis is greatly reduced by the random salting
> of the plantext (preventing complete knowledge of the plaintext).
Differential cryptanalysis is normally used in symmetric ciphers and not
PK crypto-systems. Though it might be possible to conceive a similar
attack for PK's. Normally if you use a PK you must use random padding
anyway otherwise the system cannot be considered a secure one. At least
not for non-random data. (if you randomly choose a number and encrypt
it its not necessary to pad it).
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Wed, 07 Jun 2000 10:50:05 -0400
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > High end machine in 1977? Perhaps a Cyber 175 or 205.
>
> Cyber 175? Maybe that was a typo and intended to be 176? There was
> a Cyber 170 series and a Cyber 176 series, but at least if memory
> serves, there was no 175 series. ...
The 175 is a member of the 170 series. I used it at the
U of Ill in 1977 or thereabouts. Basically the same old
familiar 6000 series architecture but with a 25 ns clock
rather than the 100 ns (6000 series) or 50 ns (rest of the
170 series) clock.
It did run the worst designed timesharing system I've ever
used. (Then again, I never did get to use RAX...)
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Some citations
Date: Wed, 07 Jun 2000 10:54:56 -0400
Mok-Kong Shen wrote:
>
> Paul Koning wrote:
>
> > Mok-Kong Shen wrote:
> > >
> > > I think that the following citations may be of some interest,
>
> > > The Kerckhoffs principle is neither a correct description
> > > of, nor a self-evident prescription for, all secrecy
> > > design projects.
> >
> > So what principle would be substitute? Or would he just
> > drop Kerckhoff's principle? If so I would ask "what possible
> > good would that serve?"
>
> The author of the article wrote some more about that. IF I understand
> correctly, he meant that those organizations that have at their
> disposal sufficient crypto expertise and resources could develop
> their own security systems and kept these secret, while those who
> can't afford to design their own stuffs have to rely on public
> algorithms.
That may be what he meant, but he'd still be wrong.
Kerckhoff worked for one of those organizations that designs its
own crypto. (The notion of "public crypto" didn't really exist
back then!) The rule comes from the -- in retrospect rather
obvious -- realization that (a) every secret sooner or later
becomes known by the enemy, (b) while keys can be changed fairly
easily, system designs cannot -- especially those that are constructed
out of gears and wires. So ignoring Kerckhoff is simply
reckless engineering practice.
That's not to say you should make your designs public if
there is no reason to. It only says that you can't
*rely* on the secrecy of the design as a source of security.
paul
------------------------------
From: "norman" <[EMAIL PROTECTED]>
Subject: vb crypto library
Date: Wed, 7 Jun 2000 17:01:23 +0200
We have been using "locknuts", a RAD tool and vb library,from
www.kewlstuff.co.za as the engine to develop an application to securely mark
products using 2d codes. It is available for trial download for those who
want to try it.
best of luck
------------------------------
** 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
******************************
