Cryptography-Digest Digest #483, Volume #12 Sat, 19 Aug 00 00:13:01 EDT
Contents:
Re: How strong is this algorithm? ("Scott Fluhrer")
Secure VoIP & IM ("Mike")
Re: blowfish problem (Dennis Ritchie)
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: How strong is this algorithm?
Date: Fri, 18 Aug 2000 18:54:25 -0700
Jeff Davies <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have an idea for a non-profit electronic cash system (a bank)
> for which I have devised I think a new algorithm.
Why? What's wrong with 3DES, Serpent or AES? Seriously: the banking
industry currently uses (I believe) 3DES, Serpent was designed by someone in
the banking industry (Ross Anderson), and AES (which might turn out to be
Serpent) is considered "good enough" for the US government uses. Why should
I trust my money to a bank that uses home-brew crypto?
> Can anyone tell me how to evaluate how strong this is??
>
> 4. The encryption technology is as follows:
>
> Note I have called this proposal "256 bit" however, I think it is
> stronger than traditional
> 256 bit methods. Instead of changing a pattern of bits larger than a
> character into an
> equivalent, random values scramble the message bits into a random
> packet 128 times larger.
>
> Electrocash will use Symmetric keys. Traditionally, asymmetric keys
> are used to prevent possibility of
> compromisation of the person's key from the server, where a third
> party could pretend to
> be the person. However, Clients are at the time of writing, far more
> vulnerable than
> the server. As a result, the private key is probably more likely to
> be lost than public key.
> So, as asymmetric are less strong per bit (2300 bit asymmetric is
> equivalent
> to about 256 bit symmetric in strength), multiple symmetric keys
> will be used with
> Electrocash.
To be pedantic, the relative strength of an asymmetric system "per bit"
varies greatly with the exact system. ECC keys that are believed to have 256
bit strength are considerably smaller than 2300 bits...
Not that the "per bit" strength is a particularly useful notion...
> The key works as follows: for each bit in the packet (encrypted
> packet length is 256 bits)
> there is a 16 bit word specifying it's position in a larger word
> where unmapped bits have
> random values. At the outset, the upper two bits of the 16 bit word
> will not be used,
> as a single udp packet of around (max) 1500 bytes is standard on
> networks sent.
> Naturally, therefore, the encrypted bit position can be one of 4096
> (from it's original
> position within 256 bits).
> Each key has 256 off 16 bit words (totalling 512 bytes) positioning
> the encrypted bits
> within the larger packet. The values in the key are originally
> generated by Electrocash
> Server using a psuedo-random binary sequence generator (cannot
> repeat within 256 values).
> The unencrypted part of the packet gives a 16 bit integer choosing
> the key from
> the 2048 supplied every month in a 1 megabyte smartcard (or
> similar).
> Each key is used for only one transaction (this might be modified if
> it proves unworkable).
If each key is used to transmit a single message, it looks safe, if rather
crude. If it is used to transmit multiple messages (and that includes
multiple messages from the same "transaction"), then it looks easy enough to
break (or at least, give the attacker enough idea about the messages to know
which bits to manipulate). And, not putting in any sort of MAC allows bored
attackers to have fun flipping random bits, and seeing what happens...
>
> Per user, 2048 keys are created per month, and distributed by
> snailmail on a smartcard or similar.
So, if someone manages to grab the smartcode out of the mailbox, he will be
able to impersonate you, and withdraw all your funds from the bank?
Oh, and what do you do if someone's a bit busy, and needs to exchange more
than 2048 messages with the bank in a month?
>
> There is no certification mechanism, as this can be bruteforced. you
> can't rely on client's being secure.
> The encryption algorithm is created outside the US, so that it is
> not subject to US export restrictions.
> As no data is stored in encrypted form, this should comply with UK
> "Rights of the People Bill".
> When Client talks to server, first unencrypted message specifies
> account number and encryption key to use
> from the 2048 sent. There is never a need for personal accounts for
> the same encryption key
> to be used twice. So when a key is used, it is discarded.
> This makes bruteforcing impossible. The client used might be
> compromised. In the case of a compromised client
> money lost is at the account holder's own risk.
>
> Ultimately, mobile phones are the target market, using JINI,
> Javasoft's embedded java product.
Mobile phones? You have got to be joking -- the huge packets this
encryption requires are totally impractical there (as well as the difficulty
of giving the phone the keys...)
--
poncho
------------------------------
From: "Mike" <[EMAIL PROTECTED]>
Subject: Secure VoIP & IM
Date: Sat, 19 Aug 2000 14:39:19 +1200
SecuriPhone addresses the issue of unsecured voice and instant messaging
over the Internet.
It employs Russian Federation National encryption standards, GOST 28147-89,
Digital signature 34.10-94, 34.11-94. using 256 bit secret and 512 bit
public keys, with optimum Sbox values. www.securiphone.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.176 / Virus Database: 85 - Release Date: 26/07/00
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 19 Aug 2000 03:09:07 +0000
Michael Will wrote:
...
> After all these years I see there's always something new to learn.
> I should go check my K&R to see if I should have known this from the
> very start. (Yes, the original. The one we had to carry to school
> uphill in the snow both ways, etc.)
When you do read p. 188 of K&R 1, and also the table on p. 182, which
gives the number of bits in a byte or char, and compare it to C99,
you will discover that things haven't changed much.
(Brian and I had to carry those stones and the chisel, not just the
paper book.)
Dennis
------------------------------
Date: Fri, 18 Aug 2000 23:16:40 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Mok-Kong Shen wrote:
> Tim Tyler wrote:
> >
> > Imagine a rare spy, who - after landing in enemy territory - opens up
> > his OTP and prepares to report that his espionage mission began
> > successfully. Scanning the pages, he finds all the symbols are zeros.
> > Imagine his dismay ;-)
>
> Why? If the spy knows that his agency has given him a
> true OTP and he also happens to be a crypto theoretician,
> he will not hesitate a micro-second before applying the
> pad!
Is the message as secure if he does not calculate the ciphertext produced by
the null pad and simply sends the plaintext?
> BTW, if the process is automatic, he (and his
> colleagues who oversee the OTP generation at the agency)
> shouldn't have visual contact with the pad at all.
Does looking at the pad influence the security of the system? I.e., is there
an observer effect?
In addition to the obviousness of the all-zeros pad, there are a slew of pads
that produce trivial transforms. What should the spy do if he notices that
the pad only changes the upper/lower case of letters (and space to a
punctuation mark). Can he decide that the tedium of encryption is unnecessary
(he's got a manual system) and it's safe to send the original text?
Does skipping the trivial encryption step count as "using" the keypad? If
not, the spy can not use the same key over and over.
This system may have interesting possibilities -- it just needs good
marketing. Where is Szopa when we need him?
------------------------------
** 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
******************************
