Re: [cryptography] Micro-SD card encrypts voice on mobile phones
coderman writes: >521-bit key and other odd claims? think i'll stick with RedPhone ... It just means they're using P521, which is the largest curve that NIST will allow. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] current digital cash / anonymous payment projects?
Following up my own post: Solving the problem of secure cash is a superset of solving the problem of providing reasonably usable secure communications. The cash encryption is useless without a solution to communication problem. Security communications being defined not as reliably and privately communicating with a true name, but reliably and privately communicating with a nym - solving the "chat to possessor of private key" problem, not the "bind private key to true name" problem. Zooko's triangle describes a manageable user interface for the "chat to possessor of private key" problem. Obviously, for anonymous payment, you do *not* want the binding to true names that both TLS and the web of trust attempt to provide. This, however, leaves you with the UI problem of what to use in place of true names, hence Zooko's triangle. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] current digital cash / anonymous payment projects?
On 2010-12-02 3:53 AM, Adam Back wrote: For the technology, to play with it I have Brands and Chaum credentials implemented in this library: http://cypherspace.org/credlib/ It was an experiment in simplifying the APIs so I think its rather simple to use. Using credentials as an ecash coin is a simple use-case. For Chaum you need an Issuer public key per denomination. For Brands you use one attribute as the denomination and a single Issuer public key. Note Brands credentials even though patented have been released with an open specification by microsoft. Details on the page above. (I started converting the library serialization format to match the open spec as it was implemented before the spec was released). Adam Adam's library provides the encryption. An actual business project would of course require communications and user interface. It would also need to locate its assets and web site somewhere the government was less likely to shut it down or take it over and use it as a honey pot to catch users, the as happened to egold. A complete project would provide users with the means to securely transmit value between one nym and another without the the central server being party to the communication. Solving the problem of secure cash is a superset of solving the problem of providing reasonably usable secure communications. The cash encryption is useless without a solution to communication problem. Security communications being defined not as reliably and privately communicating with a true name, but reliably and privately communicating with a nym - solving the "chat to possessor of private key" problem, not the "bind private key to true name" problem. Zooko's triangle describes a manageable user interface for the "chat to possessor of private key" problem. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] current digital cash / anonymous payment projects?
On 2/12/10 6:32 PM, James A. Donald wrote: On 2010-12-01 11:18 PM, Ian G wrote: On 1/12/10 6:12 AM, travis+ml-rbcryptogra...@subspacefield.org wrote: Can anyone give me a good rundown of the current anonymous payment systems, technologies and/or algorithms? OK, there are some issues here. There is technology, algorithms, patents, techniques, protocols, applications, services, business models ... all lumped into one general term without care. Anonymous payment systems are a bit of a contradiction, internally. What you're probably talking about is untraceable payment systems, which typically use Chaum or Brands or Wagner algorithms (there are a handful of other variants). In this model, the "coin" is stripped of its identifying information as it transfers from Ivan to Alice to Bob. When Bob deposits the coin to Ivan (issuer) for credit to his account, or for rollover to new coins, the chain of traceability is broken. Then, there is another variation called nymous payment systems. This model is typically done with a client-server public-private key arrangement, where the client registers the public key, and signs requests (including payments) which are sent to the server. The privacy trick with this one is that the issuer doesn't need to know who holds the private key; so while everything is traceable, it's also nymous. For anonymous payments to actually be anonymous, we need both nymity and untraceability. Nymity means that anyone can have lots of different and seemingly unrelated communication end points, such as, for example, email addresses. With Pecunix, you can pay anyone who has an email address, with no requirement for the recipient to demonstrate a true name known to the state - but transfers between one email address and another are traceable. For anonymity, one has to be able to have cheap and disposable nyms, *and* be able to transfer funds between nyms without anyone being able to discover that one nym is getting the money from the other nym. Yep, this is where the definitions matter, at a first order analysis. Change those definitions around and it gets a bit confusing. However, beyond the "privacy" aspects, there are other requirements which interfere in strange ways, but you'll only find this at a second order analysis. Plenty of systems have failed because they've not understood the laws of money & business; we or they have fielded systems that were (e.g.) private but broken in other ways. iang PS: I know James knows all this; Note to travis: if you're just interested in the crypto, you can ignore all of this, and research all the various blinding methods. But if you are interested in running a business, the crypto is more or less easy, the business is devilishly complicated. To get a taste of the business aspects, have a look at the FC7 model: http://iang.org/papers/fc7.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On Thu, Dec 2, 2010 at 1:36 PM, Steven Bellovin wrote: > ... > That's 521 bits for the ECC part, as I read it. ... And of course, "521" > is a simple typographical error away from "512", indeed; reading comprehension fail on my part. my marketing angst is at maximum lately.. ;) looking at the list of platforms, i suppose this suffers from the same smartphone application caveats as RedPhone and the rest; how much faith in EAL 5+ when the host is a rooted or vulnerable android/iphone/mitm-blackberry handset running who knows what? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On 2010 Dec 2, at 13:30 , coderman wrote: > On Wed, Dec 1, 2010 at 7:26 PM, Steven Bellovin wrote: >> http://www.cellular-news.com/story/46690.php > > 521-bit key and other odd claims? think i'll stick with RedPhone ... 521 is one of the standard sizes for characteristic-2 ECC with optimal normal basis. It isn't snake oil. (Well, it might be, but that isn't evidence.) Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On Thu, Dec 02, 2010 at 04:36:51PM -0500, Steven Bellovin wrote:
> That's 521 bits for the ECC part, as I read it. An odd size, even
> there?
[...]
"...there is no 512-bit curve defined, but only one with a 521-bit
length..."--IETF RFC 5639
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On Dec 2, 2010, at 4:30 18PM, coderman wrote: > On Wed, Dec 1, 2010 at 7:26 PM, Steven Bellovin wrote: >> http://www.cellular-news.com/story/46690.php > > 521-bit key and other odd claims? think i'll stick with RedPhone ... That's 521 bits for the ECC part, as I read it. An odd size, even there? If nothing else, see John Gilmore's preference for non-standard sizes... (No, I don't know if this product is any good, but I don't think that this is a prima facie reason to disregard them. And of course, "521" is a simple typographical error away from "512", which we all realize is a magic number but a reporter might now.) > --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Micro-SD card encrypts voice on mobile phones
On Wed, Dec 1, 2010 at 7:26 PM, Steven Bellovin wrote: > http://www.cellular-news.com/story/46690.php 521-bit key and other odd claims? think i'll stick with RedPhone ... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Modern replacement for ANSI X9.31 as far as RSA key generation goes?
On 02/12/2010 18:46, Paul Rubin wrote: > Francois Grieu writes: >> I'm thus in search for a current public standard (not >> necessarily free) specifying algorithms for RSA key >> generation, as a replacement for ANSI X9.31:1998; > > Does IEEE 1363 have what you want? Upon checking, yes and that's a good idea. Thanks. I found a few issues though. One issue is that there is nothing prescribed in the body of the P1363 standard, but at least there is a SUGGESTION to use "A.16.11 An Algorithm for Generating RSA Keys" and that can be given as a reference. The worse is is that the factors generated per A.16.11 in P1363 do not seem guaranteed to be compatible with a gizmo working per ANSI X9.31:1998, for the former allows p and q to be of different bit size (and unless I err often does so), while the later prescribes primes of equal size. That could be a serious issue for CRT implementations of the private key function. Also ANSI X9.31:1998 has requirements for the bit size of e and n, that are not in P1363 as far as I see. Ahhh, standards, how to choose between them? Francois Grieu ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Modern replacement for ANSI X9.31 as far as RSA key generation goes?
ANSI X9.31:1988 is both shown as withdrawn and offered for sale at http://www.techstreet.com/standards/X9/X9_31_1998?product_id=1327214 Francois Grieu ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Modern replacement for ANSI X9.31 as far as RSA key generation goes?
Hi, apparently, ANSI X9.31:1998 is no longer for sale. That's a sign that it is withdrawn (although I find no statement to that effect, and some recent FIPS documents that refer to it). I'm thus in search for a current public standard (not necessarily free) specifying algorithms for RSA key generation, as a replacement for ANSI X9.31:1998; something with the range of the modulus and primes, and (mostly harmless and pointless) requirements on p-1, p+1, |p-q| and such, beside selecting random primes. PKCS#1 v2.1 does not cut it; it defines valid keys, but not how to select the primes. ANSI X9.80:2005 does not seem to cut it (it is about random primes, not RSA keys). I suspect the same holds for ISO/IEC 18032:2005 Any pointer? TIA Francois Grieu ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
