Re: [cryptography] 100 Gbps line rate encryption
[2013-07-18, William Allen Simpson] On 7/17/13 4:29 AM, Tor Erling Bjørstad wrote: Regarding ESTREAM, disregard the hardware ciphers in the final portfolio. That limits the number of algorithms to four. Of these, I think Salsa20 is the only one that has obtained significant adoption. However, if I were to pick another, I'd be partial to HC-128 due to its simple (somewhat RC4-like) design and very impressive software performance. [1] http://nacl.cr.yp.to/stream.html And there's HC-256, according to wikipedia. But what about independent analysis? And is it really faster? Salsa20: 414 cycles per byte HC-256: 4 cycles per byte. HC-128: 3 cycles per byte. But HC-* has a huge per packet setup penalty!?!? There was a fair amount of attention on HC from the international research community during the ESTREAM competition (2005-2008). Most of it didn't lead very far, and probably remains unpublished or lost [1]. The findings that have been made public are all pretty minor. Certainly the two HC variants haven't received the kind of attention that the SHA-3 finalists (or Salsa20, for that matter) has, but it is also clear that researchers have been spending a not insignificant amount of brainpower trying to break it. Whether that's sufficient analysis for some particular use-case is hard to quantify. What makes HC-* interesting to me is that it's pretty much as fast as one gets it, for a strong pure software cipher encrypting long streams of data. If one has a limited number of data streams that are pushing a huge number of bits over the wire, HC-* seems pretty appealing. If the use-case instead involves a zillion independent short packets that all need to be encrypted with a unique key/IV combo, then HC's performance will indeed suck. Cheers, Tor [1] I spent some time on cryptanalysis of HC at one point, and I also remember working on it in a larger group at some of the meetings in Leuven. The only notable result coming our of those efforts, was that all our ideas were totally busted [2]. [2] This is, of course, the default outcome from cryptanalysis. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
On 7/18/13 4:36 AM, Tor Erling Bjørstad wrote: What makes HC-* interesting to me is that it's pretty much as fast as one gets it, for a strong pure software cipher encrypting long streams of data. If one has a limited number of data streams that are pushing a huge number of bits over the wire, HC-* seems pretty appealing. If the use-case instead involves a zillion independent short packets that all need to be encrypted with a unique key/IV combo, then HC's performance will indeed suck. It's the perennial problem that cryptographers design for theoretical scenarios. That's why it's better not to let them design net protocols. The average packet used to be 41 bytes. I think I read its now ~43 bytes, but even the average HTTP GET is ~600 bytes. Did they define operating for an actual traditional longer-term key with a per packet IV? If not, I'll just use my usual one. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] New small circuits for predicates on four bits and AES sbox
An interesting result, and the link also has circuit representations of the AES Sbox which they claim are smaller than any so far found - one of them 32 AND gates, 83 XOR/NXOR, and depth 28. - Forwarded message from Peralta, Rene rene.pera...@nist.gov - Date: Thu, 18 Jul 2013 08:22:21 -0400 From: Peralta, Rene rene.pera...@nist.gov To: Multiple recipients of list hash-fo...@nist.gov Subject: predicates on four bits, 4-bit S-boxes I am posting this to the hash forum because the algebraic properties of functions on few bits should be of interest to this community. There are more than 64,000 predicates on 4 bits, and no known algorithm for building optimal circuits for these predicates under the various metrics of interest for industrial applications or cryptanalysis. The multiplicative complexity of a function is the number of AND gates needed to implement it over the basis AND,XOR,1 (the 1 is for negation). One cannot build a hash function without incurring a linear multiplicative cost (sort of) uniformly across every circuit that implements it. The algebraic normal form of a function does not say much about this metric For example, it is not easy to build a circuit with minimum number of AND gates for a function such as g(a,b,c,d) = abcd + abc + abd + acb + acd + ab + ac + ad + bc + bd + cd. The following unexpected facts have been verified: 1) Every predicate on four bits can be implemented with at most 3 AND gates; 2) Every predicate on four bits, but of degree 3, can be implemented with 2 AND gates. The circuits can be downloaded from http://cs-www.cs.yale.edu/homes/peralta/CircuitStuff/CMT.html (see item 6: All predicates on 4 bits). The circuits were verified by Chris Wood. Thanks to Meltem Turan, Cagdas Calik, and the rest of the Circuit Minimization Team. Rene Peralta. - End forwarded message - ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] NIST Approves FIPS 184-6, Digital Signature Standard
http://cryptome.org/2013/07/nist-fips-186-4.htm The standard: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] A secret sharing consensus protocol (or leader election protocol)
Has there been any work with combining Shamir-style secret sharing with consensus protocols like Paxos and Raft (or leader election protocols like Omega Meets Paxos)? The idea would be to have a network of n peers, who share a secret where t=2 shares are required to reassemble the original secret. This secret is used to sign new values when a group consensus is reached via a Paxos-like protocol. In this scheme, a proposer would give its secret share, along with a proposed new value, to acceptor nodes, who can reassemble the entire secret. If they accept the new value, they can sign it with the secret, then immediately erase it. If we use a deterministic signature algorithm like Ed25519, every acceptor taking part in the consensus protocol can produce the same signed version of the proposed new value. They can then continue with the consensus protocol's accept phase. The result will be a quorum on a signed value (or a consensus failure if quorum can't be reached, of course) Let's assume a malicious entity gains control of one and only one of the nodes. They are now able to propose new values, so they can manipulate the peer network by proposing malicious values which will get accepted by the rest of the group. However, they do not *immediately* learn the private key. They would only learn the private key if any other node were to propose a value which contained their secret share. -- alternatively -- Secret sharing could be combined with a leader election protocol. In this scheme, the leader and only the leader would learn the shared secret. All proposed values would have to be approved and signed by the leader. I'm not sure I like this as much though. The leader is a single point of failure, and an attacker could maliciously force a leader election through e.g. DoS, having compromised only one other host directly. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
