Re: [cryptography] AES Implementation
OpenSSL's AES implementation is in C and can be built standalone: https://github.com/openssl/openssl/tree/master/crypto/aes Once catch is the /asm directory uses Perl templates to generate assembly files. If you are on an x86 platform, those aesni assembly implementations, mostly by Andy Polyakov with contributions from Intel, are among the fastest I've found. They can also be built into a kernel module. The BoringSSL fork by Adam Langley has a single file implementation. I haven't looked at the diffs from OpenSSL or used it: https://boringssl.googlesource.com/boringssl/+/master/crypto/aes/aes.c Apple has another C implementation here, which I've never used: http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-55010/Source/AESedp/AES.c NaCL also has a C implementation of AES, but I don't know how easy it would be to use on its own: http://nacl.cr.yp.to/ This was also ported over to libsodium: https://github.com/jedisct1/libsodium/tree/master/src/libsodium/crypto_stream/aes128ctr/portable On Tue, May 12, 2015 at 2:47 AM, Givon Zirkind givo...@gmx.com wrote: Hi, Can anyone recommend an open source AES library in some flavor of C? Thanks. G. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Fri, Dec 13, 2013 at 2:32 AM, Jan-Frode Myklebust janfr...@tanso.net wrote: What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? A microcode update ? I think that compromising microcode update keys is a much more interesting and believable prospect than compromising RDRAND. I've seen surprisingly little research around microcode update security. This post by Ben Hawkes is pretty interesting: http://inertiawar.com/microcode/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which encryption chips are compromised?
On Dec 12, 2013 6:08 AM, coderman coder...@gmail.com wrote: i see your skepticism, and i raise you a retort! ;) i even have a list of candidates you can experiment with to confirm Intel Ivy Bridge as best fit. [0] I think this is a weak guess. The document is talking about FY2013. IVB already shipped in 2012. I'd guess it was fabricated for testing in 2009-2010 and designed for a few years prior. What enablement would be complete in 2013 for something that has been on the market a year and is already being phased out? By 2013, Intel had already started shipping Haswell. They did launch new IVB E5v2 Xeon server processors this fall, but future CPUs will be Haswell and Broadwell. Intel already has the next, next generation Skylake with SGX fabricated for testing. I still think the document is talking about a dedicated crypto chip for VPN and SSL acceleration devices, just like it says. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Practical Threshold Signatures
Hi. I wrote a Java implementation of Shoup's threshold signature scheme a long time ago: https://code.google.com/p/threshsig/ I haven't touched it for years and wrote it as an undergrad, so caveat emptor. Happy to give commit rights to the Google code project if you're interested. On Tue, Nov 12, 2013 at 9:33 AM, realcr rea...@gmail.com wrote: ... Victor Shoup's RSA Threshold Signatures: I read a bit about Victor Shoup's idea for Threshold signatures in the article Practical Threshold Signatures. ... If you happen to know about working code on this subject, or an idea about implementing a nice one, please make sure to drop a message. I would probably like to participate if you are coding something of this type. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tahoe-dev] SNARKs, constant-time proofs of computation
Hi Andrew. You may be interested in contacting an early-phase startup called Tegos: http://www.tegostech.com/ They're in stealth mode and haven't posted any info online, but they are legitimate and relevant to this work. On Thu, Nov 7, 2013 at 8:39 AM, Andrew Miller amil...@cs.ucf.edu wrote: Here's a possible Tesla Coils and Corpses discussion I'd like to have sometime a few weeks from now maybe: SNARKs (Succinct Non-interactive Arguments of Knowledge) are a recent hot topic in modern cryptography. A generic SNARK scheme lets you can take an arbitrary computation (e.g., the routine that checks a signature and a merkle tree branch) and compile it to a *constant size* compressed representation, called the verification key. An untrusted server can execute the computation on behalf of the client, and produce a *constant size* proof that it was carried out correctly. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] enabling blind signatures in GPG
The one caveat I'd offer is that there have been many similar voting or e-cash proposals based on blind signatures going back to David Chaum in 1982. I'm not aware of any that have gotten traction. The blinding part is easy. The hard part is getting any adoption. Regardless, there are some anonymous credential projects with large backers which may be of interest: - Intel is baking Enhanced Privacy ID support into upcoming processors. CPU packages will have unique key material that will be used to anonymously or pseudonymously authenticate a hardware device: http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/brickell.pdf - Microsoft's U-Prove, which is based on Stefan Brands' Credentica work, published a lot of material in April 2013: http://research.microsoft.com/en-us/projects/u-prove/ There is a related book by Brands available for download here: http://www.credentica.com/the_mit_pressbook.html - IBM's Idemix looked promising a few years ago, but seems to have stagnated: http://www.zurich.ibm.com/security/idemix/ Source code here: https://prime.inf.tu-dresden.de/idemix/ On Thu, Aug 22, 2013 at 3:37 PM, Jake j...@spaz.org wrote: Hi Jim and Alex, Thanks for your help. I am pretty overwhelmed by this stuff because I am not a cryptographer (although i am a coder) but I am very determined to do this. So I am in over my head, but I have to keep going. My main focus is to be able to implement blinding for signatures using an openPGP implementation (something open-source, which means GnuPG) But when I say signature I DON'T mean the type of signature you do when you sign someone's public key. I mean like when you sign a textfile or a binary blob. As for revokation, I plan to have the CR (central registrar) sign peoples pubkeys using a key set to expire 12 months hence. So there will be twelve pubkeys in use by the CR at any given time. If someone loses their private key and is concerned that someone is using it to vote in their name, they can simply post a revokation signed with their pubkey (and accompanied by their endorsement) saying revoked and anyone doing a tally of signed screeds will blacklist their pubkey. But they won't be able to participate in the system until 12 months after their last signing by the CR, because their realname is crossed off the list for that time. The CR only tracks realnames, not pubkeys. But to enforce anonymity from an evil CR, the voter will blind their pubkey into an unreadable blob before having the CR put a signature around it. The CR will do this with RSA with no padding, so that the voter can take the result and unblind it into what looks like a signature of their pubkey (even though the CR never saw their pubkey). Apologies if this is already obvious to you. My highest priority is making this system understandable by as many people as possible, which will be a huge challenge. Eventually there will be an iphone app and a javascript page (i know) and people will be able to use it no matter how simple they are. So i definitely need to start with something I personally can understand. Another very important feature of this system is that there is only one point of centralization: the central registrar (CR). Their job is to see the person's credentials (an ID or proof of residence or whatever proves they are a member of the set in question), sign (with unpadded RSA) whatever the person presents, and record the date and fact of this signing in a publicly accessible record. And publish their pubkeys (one for each month, each expiring 12 months hence). All other aspects of the system are decentralized. Each enrolled person can post their opinions signed with their (signed) pubkey anywhere on the net they want. Anyone can crawl and tally these opinions, and verify all signatures independantly, traceable to the CR's pubkeys. The point of this is to make it so that a population (whether defined by a geographical area, or a voting district, or a cultural enclave, neighborhood, bolo, or entire nation) can choose a central registrar (trusted with a simple and mostly verifiable task) to enable an unmediated discussion between members. If members stick to a machine-parseable format (copy tweet-length statements that they agree with, and are or will be trending), it will be possible for anyone to take a snapshot of opinion, guaranteeing accuracy of sentiment and one-person one-vote. I have everything figured out except the blinding. I am glad to give more detail to anyone interested but I can't do anything until I get blinding working because it's essential to the anonymity of participants. Thank you for any help you can give, -jake __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] enabling blind signatures in GPG
Hi Jake. This is not GPG-related, but I worked on an OpenID-based private federated login system called PseudoID that used blind signatures. Basically, an identity provider will check your real identity, then issue you a blindly-signed token which you can then later use to log in pseudo-anonymously to an OpenID consumer. The consumer and provider can't latter correlate your real identity with that login. This was a summer project from an intern at the time and should be considered a proof-of-concept. It does the unblinding crypto in server-delivered Javascript so is not secure as-is. Do not use for anything in practice. Here's the paper: http://saweis.net/pdfs/pseudoid-pets2010.pdf Here's the source: https://code.google.com/p/pseudoid/ Here's a demo video: https://www.youtube.com/watch?feature=player_embeddedv=fCBPuGsO_I4 Here's a site that was the private ID provider demo: http://private-idp.appspot.com/ Here was the blind-signer demo, which is broken since we accidentally let the pseudoid.net domain lapse: http://blind-signer.appspot.com/ On Sun, Aug 18, 2013 at 1:08 AM, Jake j...@spaz.org wrote: Hello everybody, I am trying to form an anonymous opining sytem based on a single Registrar, whose signatures deify users' public keys with the mark of a Participant. But to protect the users from an evil registrar, blinding must be used. I have been told that blinding is already implemented internally to deter timing-based attacks, so this would be a matter of implementing a command-line option to blind a blob and save the blinding salts. I am not a cryptographer so I can only repeat what i've heard on this. http://en.wikipedia.org/wiki/**Blind_signature#Blind_RSA_** signatures.5B2.5D:235http://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures.5B2.5D:235 Basically, a Participant generates a key pair (only for use in opining, not with their real identity) and wants to be able to prove, in public signed cleartext postings, that their public key has been signed by the Registar as an endorsement of Participation. But they don't want the Registrar to see their public key and correlate it with their real identity (their proof of eligibility for participation) because that would compromise their anonymity. So the Participant blinds their public key, presents that blob to the Registrar (along with their real identity) and receives the Registrar's signature of the blob. Then they take the blob home, and unblind it, revealing a perfect Registrar's signature of their public key. Please write if you can help me make this happen. I believe that the system i'm trying to create could have a very positive effect on democracy in the world, and hopefully make politicians into simple clerks whose job is simply to count the opinions and follow the will of the people. take care, -jake __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
Hypervisors like KVM can expose random number generator devices to guests: http://libvirt.org/formatdomain.html#elementsRng Funny, because I just noticed KVM's default is /dev/random. If that's the case, I think a guest could exhaust the entropy pool, cause /dev/random to block, and stall any other VMs using it. I'll need to try that out. Regarding VM adoption, I've seen analyst estimates that say 50% of workloads are currently virtualized. I can't provide a link because they're in a paywalled report. On Fri, Jul 19, 2013 at 3:26 PM, Nico Williams n...@cryptonector.com wrote: The rpi's HW RNG is almost certainly better than many /dev/*random implementations running as VM guests. How much real business is getting transacted on VMs nowadays? Probably a lot. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Heml.is - The Beautiful Secure Messenger
I think compromising microcode update signing keys would be the easiest path. Then you don't need backdoors baked in the hardware, don't need Intel's buy-in, and can target specific systems without impacting the public at large. This is a pretty interesting analysis showing that these updates are 2048-bit RSA signed blobs: http://inertiawar.com/microcode/ On Fri, Jul 12, 2013 at 1:38 PM, Nico Williams n...@cryptonector.comwrote: I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] 100 Gbps line rate encryption
Are you assuming a single core? I ran 'openssl speed' on an 8-core 2.9 GHz Intel Xeon E5-2690 with hyperthreading enabled, which gives it 16 logical cores. It's an artificial benchmark, but openssl is able to encrypt using AES-XTS with 128-bit keys at 28 gigabytes / second for 8KB blocks, which is 225.2 gigabits per second. This may not be relevant to the whichever platforms the original post was thinking of. On the x86 platform I tested this on, memory bandwidth would be the bottleneck before the crypto. Edited output: $ uname -a Linux [hostname] 3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ openssl speed -multi 16 -evp aes-128-xts OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr 15 15:27:18 UTC 2013 [some build output omitted] The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes evp3994884.76k 11902064.66k 21140865.02k 26338644.65k 28151824.38k On Sun, Jun 30, 2013 at 2:13 PM, aort...@alu.itba.edu.ar wrote: Oops, miscalculation. That should be a 6.5 Ghz clock for 100 Gbps. ((100 Gbps/8)/2) . Anyway I don't think anybody has hardware that fast except maybe for IBM with the Power8. The fastest hardware implementation of RC4 that I know is 2 bytes/clock. I personally programmed a 1 byte/clock RC4 in a FPGA, it's quite simple. At 2 bytes/clock you still need a clock of 10 gigahertz to encrypt 100 Gbps. That's unfeasible, the way it's done is using paralelism, then you can use any algorithm you want as long as you have silicon available. Consider there are 400 Gbps systems coming online. Using a PC for that kind of workload is a waste of money and power. FPGAs are not that expensive nowadays. Just as a data point, on x86 processors with AESNI you can encrypt AES in, say, XTS mode with about 0.75 cycles / byte on each core. On an Intel Xeon E5-2690 'openssl speed -multi 4 -evp aes-128-xts' tops out at 13.5 GB/s for 8k blocks, which is 108 Gbps. That's only using half the physical cores and no hyperthreading. However, that's unlikely a realistic benchmark for whatever context the original question was referring to. On Sat, Jun 22, 2013 at 5:25 PM, Peter Maxwell pe...@allicient.co.ukwrote: On 22 June 2013 23:31, James A. Donald jam...@echeque.com wrote: On 2013-06-23 6:47 AM, Peter Maxwell wrote: I think Bernstein's Salsa20 is faster and significantly more secure than RC4, whether you'll be able to design hardware to run at line-speed is somewhat more questionable though (would be interested to know if it's possible right enough). I would be surprised if it is faster. Given the 100Gbps spec, I can only presume it's hardware that's being talked about, which is well outwith my knowledge. We also don't know whether there is to be only one keystream allowed or not. However, just to give an idea of performance: from a cursory search on Google, once can seemingly find Salsa20/12 being implemented recently on GPU with performance around 43Gbps without memory transfer (2.7Gbps with) - http://link.springer.com/chapter/10.1007%2F978-3-642-38553-7_11 ) - unfortunately I don't have access to the paper. On a decent 64-bit processor, the full Salsa20/20 is coming in around 3-4cpb - http://bench.cr.yp.to/results-stream.html - and while cpb isn't a great measurement, it at least gives a feel for things. Going on a very naive approach, I would imagine the standard RC4 will suffer due to being byte-orientated and not particularly open to parallelism. Salsa20 operates on 32-bit words and from a cursory inspection of the spec seems to offer at least some options to do operations in parallel. If I were putting money on it, I suspect one could optimise at least Salsa20/12 to be faster than RC4 on modern platforms; whether this has been done is another story. Fairly sure Salsa20/8 was faster than RC4 out-of-the-box. As with anything though, I stand to be corrected. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
