Re: [cryptography] Cryptome’s searing critique of Snowden Inc.

On 2/14/16, Malcolm Matalka wrote: >... > Can you go into some detail on this? I was always under the impression > that the Tor code was open source and heavily audited. Is the critique > that this is not true or something else? clarification in order. 1) government

[cryptography] PSA: fas.org is now https://www.fas.org/

we thought it would never happen, perhaps outlasting cryptome.org for TLS resistance, and yet, behold! https://www.fas.org/ best regards, [ don't tell them about COMODO HACKAR ;P ... ] ___ cryptography mailing list cryptography@randombit.net

Re: [cryptography] Cryptome.biz (RU) not affiliated with Cryptome.org.

On Wed, Dec 2, 2015 at 8:58 AM, John Young wrote: > Cryptome.biz, a Russian virtual currency site registered 25 November 2015, > is not affiliated with Cryptome.org. where can i source Conflict-Free JYA Bobble-Headz? ___

Re: [cryptography] [cryptome] WikiLeaks Hosts Cryptome with Search

On 10/19/15, John Young wrote: > WikiLeaks Hosts Cryptome with Search > > https://cryptome.wikileaks.org full circle! :P with archive.org and wikileaks mirrors available, time to monitor selective availability / removal... past the crux? or fights ahead? best regards,

[cryptography] CYBER INTEGRITY ASSURANCE DIRECTORATE [was Re: [cryptome] Re: Cryptome for sale with access log files from 1996 for $50, 000, 000]

On 10/15/15, Andrew Hornback wrote: > Okay, I'll take the troll bait here... > > How would you go about verifying that his account has NOT been hacked? proving NOT hacked is actually technically challenging in a rigorous sense! first, you use a langsec runtime to ensure

Re: [cryptography] Supersingular Isogeny DH

On 7/9/15, Marcel tiep...@dev-nu11.de wrote: well thanks for reply :) stumble toward the light, we can... The key exchange does not rely on using two different points. Poorly worded; and a path needed two points not clear enough. I will try to explain i little more general: I generate

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On 5/26/15, Kevin kevinsisco61...@gmail.com wrote: Are we talking about entropy taken from hard drive turbulence, the keyboard or mouse, heat decay, or what? ... requiring nothing but a timer (ideally, the CPU timestamp counter) for comparison, i run XSTORE on 1Ghz Padlock enabled processor at

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On 5/25/15, Russell Leidich pke...@gmail.com wrote: ... Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On 5/26/15, coderman coder...@gmail.com wrote: ... others may provide constructive criticism, as you seem sincere in your desire for building useful entropy collection. but this solution is worse than nothing, as it provides absurd claims of false security. speaking of, ''' 'If you can

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On 5/26/15, Krisztián Pintér pinte...@gmail.com wrote: i call bullshit on this one, just as i called bullshit on havege... dakarand is the other to add to this set, as well as the high resolution timer based userspace rng daemon mods... best regards,

Re: [cryptography] Enranda: 4MB/s Userspace TRNG

On 5/26/15, Russell Leidich pke...@gmail.com wrote: ... I would welcome your longer reply, you are patient and friendly in response to me, a jerk flinging opinions! i will send a longer response about my specific concerns for these types of entropy gathering when time permits - thank you for

Re: [cryptography] Javascript scrypt performance comparison

On 5/9/15, Krisztián Pintér pinte...@gmail.com wrote: ... there is another option, using a random permutation on the memory addresses. a permutation destroys all information except equality (accessing the same address twice). however, you need to apply the same permutation to the initial

Re: [cryptography] Javascript scrypt performance comparison

On 5/9/15, Krisztián Pintér pinte...@gmail.com wrote: ... create a huge block of pseudorandom data derived from the password, and then use pseudorandom indexing to access the data, also based on the password... this second phase is what we are talking about here. it is essential to the

Re: [cryptography] Shamir Reveals Sisyphus Algorithm

On 4/22/15, John Young j...@pipeline.com wrote: Adi Shamir at RSA Conference: Fully secure systems don't exist now and won't exist in the future. Cryptography won't be broken, it will be bypassed. Futility of trying to eliminate every single vulnerability in a given piece of software.

Re: [cryptography] Crypto Vulns

On 3/7/15, Dave Horsfall d...@horsfall.org wrote: On Sat, 7 Mar 2015, Kevin wrote: No 1 vulnerability of crypto is the user 2nd passphrases 3rd overconfidence 4th trust in the producer 5th believing backdoors are No. 1 I don't agree that the user should be first on that list unless

Re: [cryptography] digest verification fun

On 2/18/15, Tom Ritter t...@ritter.vg wrote: ... I'm not aware of anything real spectacular, the topic was discussed quite a bit on the messaging mailing list though. https://moderncrypto.org/mail-archive/messaging/2014/thread.html now's time to mention visprint, a favorite toy if not so

[cryptography] JYA Hash this motherfucker, said math to germ.

On 12/29/14, John Young j...@pipeline.com wrote: From discussion on these lists and elsewhere tampering with data can, does, occur at every software and hardware hand-off, with each self-serving iteration having hidden and vulnerable hardware and software undisclosed malignity, no matter the

Re: [cryptography] caring harder requires solving once for the most demanding threat model, to the benefit of all lesser models

On 10/13/14, ianG i...@iang.org wrote: ... your welcome ;-) a considered and insightful response to my saber rattling diatribe. i owe you a beer, sir! Ah well, there is another rule we should always bring remember: Do not use known-crap crypto. Dual_EC_DRBG is an example of a crap

Re: [cryptography] RC4 Forevar! [was: RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4]

On 10/12/14, coderman coder...@gmail.com wrote: ... also, the definitive paper at http://www.isg.rhul.ac.uk/tls/ still insists, For WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2. which is either incompetently incorrect, or intentional indirection. there is a third

[cryptography] RC4 Forevar! [was: RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4]

On 9/22/14, coderman coder...@gmail.com wrote: ... Please elaborate. TKIP has not been identified as a ‘active attack’ vector. hi nymble, it appears no one cares about downgrade attacks, like no one cares about MitM (see mobile apps and software update mechanisms). [0] to be specific

Re: [cryptography] RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

On 9/21/14, Daniel kyhw...@gmail.com wrote: Hey coderman, has this been released anywhere? I asked because I discovered http://people.cs.kuleuven.be/~mathy.vanhoef/papers/wpatkip.pdf again. (Where with TKIP, if you can inject packets on the air, you can get back unencrypted traffic

Re: [cryptography] RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

On 9/16/14, staticsafe m...@staticsafe.ca wrote: ... My home Wi-Fi AP (a Mikrotik RouterOS) device is configured as WPA2 PSK with TKIP and AES unicast/group ciphers. I see that I can uncheck the TKIP check box, is this an acceptable workaround to the issue you mentioned? please test; you

[cryptography] RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

first and foremost: WPA2 does NOT prevent an adversary able to inject packets at you from downgrading crypto to flawed RC4. due to odd forgotten legacy protocol bits, every implementation of WPA2 that i have tested is vulnerable to an active downgrade to TKIP/RC4 while still being WPA2 and still

Re: [cryptography] RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

On 9/15/14, coderman coder...@gmail.com wrote: ... every implementation of WPA2 that i have tested is vulnerable to an active downgrade to TKIP/RC4 while still being WPA2 and still showing all signs of using strongest security settings. yes, this attack does require knowing the WPA passphrase

Re: [cryptography] RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4

On 9/15/14, coderman coder...@gmail.com wrote: ... yes, this is all for now. :) i lied and one last clarification before day is done: why do you care if this assumes knowledge of the pairwise master key? a) my poc sucks; make a better one able to manipulate EAPOL frames without PMK! b

Re: [cryptography] NSA Systems Abroad Query

On Mon, Jul 28, 2014 at 1:30 PM, John Young j...@pipeline.com wrote: What is NSA WB Quad System my money on: WideBand Quadrature Receiver System (no doubt they build very nice ones...) ___ cryptography mailing list cryptography@randombit.net

Re: [cryptography] Stealthy Dopant-Level Hardware Trojans

On Sun, Jun 22, 2014 at 2:49 AM, coderman coder...@gmail.com wrote: ... full URI to PDF for posterity: http://www.emsec.rub.de/media/crypto/veroeffentlichungen/2014/02/20/BeckerChes13.pdf one last note: it has been pointed out that this paper discusses one potential implementation

Re: [cryptography] List of digital currencies?

On Tue, Jun 24, 2014 at 1:02 PM, grarpamp grarp...@gmail.com wrote: Any links to a list of digital currencies organized by technology? ie: Bitcoin has countless forks characterized by nothing more than adjusting (or not) the operating parameters of the bitcoin.org code and starting their own

Re: [cryptography] Stealthy Dopant-Level Hardware Trojans

On Fri, Sep 13, 2013 at 2:49 AM, Eugen Leitl eu...@leitl.org wrote: ... http://people.umass.edu/gbecker/BeckerChes13.pdf Stealthy Dopant-Level Hardware Trojans ? Georg T. Becker1 this paper has disappeared from the net. any one have copies? (looking at you, JYA ;) [bonus points for

Re: [cryptography] Stealthy Dopant-Level Hardware Trojans

On Sun, Jun 22, 2014 at 2:43 AM, Michael Rogers mich...@briarproject.org wrote: ... http://www.emsec.rub.de/research/publications/Hardware-Trojans/ ... PhD students suck at maintaining their web pages. ah well, :) full URI to PDF for posterity:

Re: [cryptography] Help investigate cell phone snooping by police nationwide

On Sat, Jun 7, 2014 at 5:02 AM, John Young j...@pipeline.com wrote: ... Is there reliable evidence that putting mobiles in a fridge is any better illusory comsec than putting pillows around the door also comically exhibited to clueless journalists favored by Showman Snowden? Or at least as

Re: [cryptography] Help investigate cell phone snooping by police nationwide

On Sun, Jun 8, 2014 at 2:47 PM, coderman coder...@gmail.com wrote: ... if regional any phone at hotel feed audio (speex codec of room audible speaking individuals) was enabled, without a specific scrutiny, then yes, phone is better. removing batteries a session anomaly potentially alerted

Re: [cryptography] Extended Random is extended to whom, exactly?

On Sun, Apr 6, 2014 at 6:10 AM, ianG i...@iang.org wrote: ... They are published, typically... However they are buried... Firstly, they are not collected in any particular one place. Secondly, they use the internal language of audit... Thirdly they are full of audit-semantics...

Re: [cryptography] Extended Random is extended to whom, exactly?

On Mon, Mar 31, 2014 at 3:33 PM, ianG i...@iang.org wrote: ... In some ways, this reminds me of the audit reports for compromised CAs. Once you know the compromise, you can often see the weakness in the report. are these public reports? such a collection of compromise reports would be

Re: [cryptography] Extended Random is extended to whom, exactly?

On Sat, Apr 5, 2014 at 9:46 PM, coderman coder...@gmail.com wrote: ... such a collection of compromise reports would be informative. to be clear, pre-compromise CA audit reports. after the fact is fairly definitive! ___ cryptography mailing list

Re: [cryptography] To Tor or not to Tor?

On Wed, Mar 26, 2014 at 4:23 AM, John Young j...@pipeline.com wrote: Ubiquitous use of a comsec system is a vulnerability, whether PGP or Tor or another popular means. Ubiquitous trust in technology without assurances nor fail-safes is a vulnerability - fixed that for you JYA plenty of

Re: [cryptography] Compromised Sys Admin Hunters and Tor

On Fri, Mar 21, 2014 at 5:01 AM, John Young j...@pipeline.com wrote: Sys admins catch you hunting them and arrange compromises to fit your demands so you can crow about how skilled you are. Then you hire them after being duped as you duped to be hired. everything old is new again, betrayals

[cryptography] Privacy Enforced [was: Comsec as Public Utility Beyond Illusory Privacy]

On Thu, Mar 13, 2014 at 6:59 AM, John Young j...@pipeline.com wrote: Snowden may have raised the prospect of comsec as a public utility like power, water, gas, sewage, air quality, environmental protection and telecommunications... Comsec as a right for human discourse rather than a

Re: [cryptography] Privacy Enforced [was: Comsec as Public Utility Beyond Illusory Privacy]

On Thu, Mar 13, 2014 at 9:47 AM, Alexandre Anzala-Yamajako anzal...@gmail.com wrote: If OpenSSL has taught us one thing over the years it's that collaborative dev doesn't mean perfection and far from it. you'll notice that my focus is on testing and breaking, not developing. i agree in full

[cryptography] 2010 TAO QUANTUMINSERT trial against 300 (hard) targets

https://s3.amazonaws.com/s3.documentcloud.org/documents/1076891/there-is-more-than-one-way-to-quantum.pdf TAO implants were deployed via QUANTUMINSERT to targets that were un-exploitable by _any_ other means. if you were on this short list of 300 - you were doing something right! --- Snowden

Re: [cryptography] [Cryptography] BitCoin bug reported

On Sun, Mar 9, 2014 at 9:04 PM, coderman coder...@gmail.com wrote: ... c.f.: http://blog.magicaltux.net/wp-content/uploads/2014/03/MtGox2014Leak.zip http://89.248.171.30/MtGox2014Leak.zip https://mega.co.nz/#!0VliDQBA!4Ontdi2MsLD4J5dV1-sr7pAgEYTSMi8rNeEMBikEhAs http://burnbit.com/download

Re: [cryptography] Commercialized Attack Hardware on SmartPhones

On Sun, Mar 2, 2014 at 7:33 AM, Tom Ritter t...@ritter.vg wrote: Hey all, wondering if anyone knows of any commercialized hardware (e.g. developed into a product, not just a research paper) that conducts attacks on powered-on, Full Disk Encrypted Android/iPhone phones that _isn't_ PIN

Re: [cryptography] NIST asks for comment on its crypto standards processes

On Mon, Feb 24, 2014 at 2:09 AM, ianG i...@iang.org wrote: ... NIST is responsible for developing standards, guidelines, tools and metrics to protect non-national security federal information systems... In November 2013, NIST announced it would review its cryptographic standards development

Re: [cryptography] Snowden Drop to Poitras and Greenwald Described

On Sat, Feb 8, 2014 at 11:27 PM, ianG i...@iang.org wrote: ... So what British Intelligence did was to switch gears and harass his operations to make them as difficult as possible. Instead of trying to necessarily stop the bombs, they pushed gear across that made bomb making risky, and

Re: [cryptography] Alleged NSA-GCHQ Attack on Jean-Jacques Quisquater

On Sun, Feb 2, 2014 at 4:03 AM, John Young j...@pipeline.com wrote: Apparently Quisquater would not have known about the attack if not told by an insider. yup. not even a slight concern on their minds. hmmm, must be updating locate db... Any other cryptographer attacked (as if it

Re: [cryptography] [Cryptography] BitCoin bug reported

On Sun, Feb 16, 2014 at 6:40 PM, Lucky Green shamr...@cypherpunks.to wrote: ... Often, I think of some of the mid 1990's payment system innovators as incompetent. Which they were. Yet they were rocket scientists eligible for Nobel Price compared to some of the Bitcoin outfits that I have met

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

On Wed, Jan 15, 2014 at 5:38 PM, arne renkema-padmos arne.renkema-pad...@cased.de wrote: ... Also, I would like to have doctors fixing things like intestinal ruptures, not some kid with their parent's sewing kit :P i think you misunderstand some of my intent: to be a competent developer, you

Re: [cryptography] pie in sky suites - long lived public key pairs for persistent identity

On Fri, Jan 3, 2014 at 11:42 AM, coderman coder...@gmail.com wrote: use case is long term (decade+) identity ... key signs working keys tuned for speed with limited secret life span (month+). i should have better clarified intent: - long term keys are offline, otherwise better protected

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

On Wed, Jan 15, 2014 at 10:31 AM, John Young j...@pipeline.com wrote: With a $67B security market heading to $87B by 2016 why would any security firm settle for RSA piddling racketerring? ... Not saying the RSA bashers are diverting attention from their venality, that would be contrary to

Re: [cryptography] [Cryptography] Boing Boing pushing an RSA Conference boycott

On Tue, Jan 14, 2014 at 8:34 AM, Jared Hunter feralch...@gmail.com wrote: ... If it's wrong for RSA to take $10M to set a bad default in BSAFE, is it not MORE wrong to sell the federal government a 0day for a fraction of that price? collusion to weaken RNGs enables pervasive insecurity and

Re: [cryptography] Better Crypto

On Sat, Jan 4, 2014 at 11:59 PM, ianG i...@iang.org wrote: Not sure if it has been mentioned here. The Better Crypto group at bettercrypto.org have written a (draft) paper for many of those likely configurations for net tools. The PDF is here:

[cryptography] pie in sky suites - long lived public key pairs for persistent identity

use case is long term (decade+) identity rather than privacy or session authorization. eternity key signs working keys tuned for speed with limited secret life span (month+). working keys are used for secret exchange and any other temporal purpose. you may use any algorithms desired; what do

Re: [cryptography] To Protect and Infect Slides

On Wed, Jan 1, 2014 at 3:56 AM, Ralph Holz h...@net.in.tum.de wrote: Hi Jake, Ian Grigg just made a point on metzdowd that I think is true: if you want to change the NSA, you need to address the [...] [... money] Because the chain goes like this: corporate money - election campaigns -

[cryptography] ECDHE-RSA-CHACHA20-POLY1305-SHA256 server side support in OpenSSL / Nginx

poked around some patches for chacha20 and poly1305 suites in OpenSSL... there's more work to be done it seems. is there a working setup for Linux server side chacha20 poly1305 suites with OpenSSL? (i am probably not looking in the right place; e.g. aead_support.patch, aead_ssl_support.patch,

Re: [cryptography] Vegetation Comsec

On Fri, Dec 20, 2013 at 6:22 PM, John Young j...@pipeline.com wrote: ... Plant signaling with chemical emissions was intriguing, as were signals sent through proxies such as insects. ... Has anyone seen reports on this? Or on chemical transceiving for comsec? Public key as a plant with

Re: [cryptography] Which encryption chips are compromised?

one last amusing note, Google has gone whole hog on SDN: http://www.networkcomputing.com/data-networking-management/inside-googles-software-defined-network/240154879 how amusing would it be if they implemented inter-DC IPsec keyed with RDRAND directly on compromised cores in one of these

Re: [cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 7:08 AM, John Young j...@pipeline.com wrote: Please stop this suicidal, treacherous discussion. You're undermining the global industry of weak crypto and comsec. That counts as economic terrorism in all the countries who abide arms control, export control, copyright,

Re: [cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 8:04 AM, Steve Weis stevew...@gmail.com wrote: ... 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

Re: [cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 8:42 AM, coderman coder...@gmail.com wrote: IVB already shipped in 2012... only server Ivy Bridge: Xeon E3 in mid-2012. this does bring up an interesting point: while it may be more efficient to use the same key for the DRBG output across all processor lines, it would

Re: [cryptography] Which encryption chips are compromised?

On Thu, Dec 12, 2013 at 1:24 PM, Andy Isaacson a...@hexapodia.org wrote: ... In reply to Declan tweeting about this discussion (shame on you, Declan, if you're reading this and trying to take the discussion to the public), the worst kind of xpost of all? every day without RDRAW is another day

Re: [cryptography] Which encryption chips are compromised?

On Tue, Dec 10, 2013 at 4:11 PM, d...@geer.org wrote: * (TS//SI//REL TO USA, FVEY) Complete enabling for [XX] encryption chips used in Virtual Private Network and Web encryption devices. [CCP_9]. For this to be an explicit line item in that document, it has to be special.

Re: [cryptography] Which encryption chips are compromised?

On Wed, Dec 11, 2013 at 6:28 PM, Steve Weis stevew...@gmail.com wrote: ... Ivy Bridge processors are general purpose x86 CPUs. It doesn't make sense to me to refer to it as an encryption chip for web encryption devices. used in Virtual Private Network == PPTP,IPsec,OpenVPN,etc. Web encryption

Re: [cryptography] Which encryption chips are compromised?

On Wed, Dec 11, 2013 at 9:15 PM, Andy Isaacson a...@hexapodia.org wrote: ... Since the source document appears to be the same for both, an enterprising DTP jockey could use -clean-1.pdf to tune the document settings precisely, and then use -project.pdf to search for better unredaction

Re: [cryptography] Which encryption chips are compromised?

On Tue, Dec 10, 2013 at 4:11 PM, d...@geer.org wrote: ... For this to be an explicit line item in that document, it has to be special. The two classes of special that occur to me are (1) XX has a near monopoly (like Broadcom does in its sector) or (2) XX is uniquely vulnerable to

Re: [cryptography] State of the art in block ciphers?

On Fri, Dec 6, 2013 at 3:35 AM, Rob Stradling rob.stradl...@comodo.com wrote: ... https://www.ssllabs.com/ssltest/analyze.html?d=google.coms=173.194.115.46 currently shows... TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) thanks all for additional pointers; progess! i am

Re: [cryptography] State of the art in block ciphers?

On Thu, Dec 5, 2013 at 12:13 AM, Matthew Orgass darks...@city-net.com wrote: ... OTOH, for TLS ChaCha seems to me like the best choice at this point. let me know when you are able to speak TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 between browser and popular site! (or any browser and any

Re: [cryptography] State of the art in block ciphers?

On Thu, Dec 5, 2013 at 3:41 AM, coderman coder...@gmail.com wrote: ... let me know when you are able to speak TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 between... +require TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 for the EC haters *grin

Re: [cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

On Mon, Dec 2, 2013 at 11:02 PM, Stephan Mueller smuel...@chronox.de wrote: ... Interesting: I have the same type of discussion (SP800-90B) to prepare (and even went through it -- see [1]) and I do not see it that problematic, if you have the right hooks into your noise source implementation

Re: [cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

On Sun, Dec 1, 2013 at 12:27 PM, d...@deadhat.com wrote: ... I would not characterize the Linux RNG issue as fully resolved in any way. Until every CPU maker includes a source of entropy by design (instead of by accident). for my own uses, and what i feel reasonable requirements, i would

Re: [cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

On Fri, Nov 29, 2013 at 4:54 PM, coderman coder...@gmail.com wrote: ... disable direct kernel support and feed only /dev/random with RDSEED. then use a userspace rngd as discussed correction: this should be /dev/hw_random for use with an rngd. (or /dev/hwrandom, or /dev/hw-random

Re: [cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

On Fri, Nov 29, 2013 at 4:54 PM, coderman coder...@gmail.com wrote: ... 0. extract_buf() - 'If we have a architectural hardware random number generator [ED.: but only RDRAND], mix that in, too.' https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c

Re: [cryptography] Quality of HAVEGE algorithm for entropy?

On Wed, Nov 27, 2013 at 3:10 AM, Stephan Mueller smuel...@chronox.de wrote: ... The way haveged is implemented, not really. The reason is that it uses clock_gettime, which uses the Linux kernel clocksource framework. That framework has drivers for a number of different timers on various

[cryptography] ntru-crypto - Open Source NTRU Public Key Cryptography Algorithm and Reference Code

https://github.com/NTRUOpenSourceProject/ntru-crypto Security Innovation, Inc., the owner of the NTRU public key cryptography system, made the intellectual property and a sample implementation available under the Gnu Public License (GPL) in 2013 with the goal of enabling more widespread adoption

Re: [cryptography] Quality of HAVEGE algorithm for entropy?

On Tue, Nov 26, 2013 at 10:09 AM, Joachim Strömbergson joac...@strombergson.com wrote: ... I have concerns though on embedded SSL stacks that use Havege as entropy source on MCUs such as AVR32 and ARM. ... On an x86-based server you can use Havege, but use it to feed /dev/random, not as a

Re: [cryptography] Quality of HAVEGE algorithm for entropy?

On Sun, Nov 24, 2013 at 2:04 PM, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: ... i found such a very nice piece of software that's said to provide added entropy using HAVEGE algorithm: http://www.issihosts.com/haveged/ http://www.irisa.fr/caps/projects/hipsor/ Any opinion on the

Re: [cryptography] [Cryptography] Email is unsecurable

On Mon, Nov 25, 2013 at 1:51 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: ... Personally, I'm not at all confident that we can do something that provides end-to-end security, can be deployed at full Internet scale and is compatible with today's email protocols. But if others are more

Re: [cryptography] Design Strategies for Defending against Backdoors

On Sun, Nov 17, 2013 at 11:27 PM, ianG i...@iang.org wrote: In the cryptogram sent over the weekend, Bruce Schneier talks about how to design protocols to stop backdoors. Comments? ... All random number generators should conform to published and accepted standards. Breaking the random

[cryptography] coderman's keys

my contempt for email is well known and reinforced by choice of provider. there are myriad rebuttals to email as private channel, of which i agree fully. however, if you pass muster, i can be reached via secure email. yes your default client will balk. this is a feature not a bug... you must

Re: [cryptography] coderman's keys

On Thu, Oct 31, 2013 at 7:55 PM, coderman coder...@gmail.com wrote: my contempt for email is well known and reinforced by choice of provider. there are myriad rebuttals to email as private channel, of which i agree fully. however, if you pass muster, i can be reached via secure email. yes

Re: [cryptography] design and implementation of replay prevention windows

On Thu, Sep 26, 2013 at 4:05 PM, coderman coder...@gmail.com wrote: i'm looking for information on the design and implementation of replay windows in various protocols. oddly enough, this is a surprisingly obtuse subject. it is constrained by: - the encryption and authentication primitives

Re: [cryptography] FreeBSD crypto and security meta

On Mon, Oct 21, 2013 at 1:45 PM, grarpamp grarp...@gmail.com wrote: ... http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Reworking-random(4) the interesting bit: FreeBSD's CSPRNG also allowed for certain stochastic sources, deemed to be high-quality, to directly supply the

Re: [cryptography] Snowden Comsec Is Stupefying

On Sat, Oct 19, 2013 at 5:37 AM, John Young j...@pipeline.com wrote: It is not either dribble / or dump as favored outlets are pontificating,... Both: provide the documents in a publicly accessible depository as well as narrate their significance... the latter is always done it seems, when

Re: [cryptography] Snowden sets OPSEC record straight

On Fri, Oct 18, 2013 at 6:46 AM, John Young j...@pipeline.com wrote: Snowden filtered by Janes Risen filtered by New York Times, as with all other filterings by special-interested Snowden filters, ... i did appreciate the plentiful use of actual quotations. these snippets among the narrative

Re: [cryptography] NYT Planning NSA Ppaers

On Fri, Oct 18, 2013 at 10:54 AM, John Young j...@pipeline.com wrote: Musings on Snowden being devoured, threatened then totemized like Ellsberg: http://cryptome.org/2013/10/nyt-nsa-papers.htm The Times initiation of the International New York Times would provide a global in-your-face to

Re: [cryptography] /dev/random is not robust

On Mon, Oct 14, 2013 at 5:35 PM, d...@deadhat.com wrote: http://eprint.iacr.org/2013/338.pdf ...it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice. in my mtrngd for XSTORE i not only fed /dev/random when it became write-able (entropy less than full) but

Re: [cryptography] Curve25519 OID (was: Re: the spell is broken)

On Sun, Oct 6, 2013 at 1:52 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: ... { 1 3 6 1 4 1 3029 1 5 1 } ed209^H^H5519 You have been OIDed. Go forth and encrypt. well played sir! :) ___ cryptography mailing list cryptography@randombit.net

Re: [cryptography] the spell is broken

On Wed, Oct 2, 2013 at 5:49 PM, James A. Donald jam...@echeque.com wrote: ... So, people who actually know what they are doing are acting as if they know, or have good reason to suspect, that AES and SHA-2 are broken. James this is not true. i challenge you to find reputable positions

Re: [cryptography] the spell is broken

On Thu, Oct 3, 2013 at 4:28 AM, James A. Donald jam...@echeque.com wrote: ... He does not believe that AES and SHA-2 rest are necessarily broken - but neither does he believe that they are not broken. there is a significant difference between avoiding a cipher on principle, or association,

Re: [cryptography] the spell is broken

On Wed, Oct 2, 2013 at 10:38 AM, Jared Hunter feralch...@gmail.com wrote: Aside from the curve change (and even there), this strikes me as a marketing message rather than an important technical choice. The message is we react to a deeper class of threat than our users understand. it is

Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)

On Tue, Oct 1, 2013 at 2:12 AM, Adam Back a...@cypherspace.org wrote: ... And Lucky has some gruesome alternatively low tech version also which doesnt bear thinking about. i'm curious about defeating the liveness detection of fingerprint readers using a severed digit. or is non-trivial

Re: [cryptography] The Compromised Internet

On Wed, Sep 25, 2013 at 1:36 PM, Tony Arcieri basc...@gmail.com wrote: ... What threat are you trying to prevent that isn't already solved by the use of cryptography alone? this is some funny shit right here... LOL ___ cryptography mailing list

Re: [cryptography] The Compromised Internet

On Wed, Sep 25, 2013 at 11:19 PM, coderman coder...@gmail.com wrote: On Wed, Sep 25, 2013 at 1:36 PM, Tony Arcieri basc...@gmail.com wrote: ... What threat are you trying to prevent that isn't already solved by the use of cryptography alone? this is some funny shit right here... LOL

[cryptography] design and implementation of replay prevention windows

i'm looking for information on the design and implementation of replay windows in various protocols. what concerns drive an appropriate window size? what role do timestamps play, if any, in constraining replay outside the active window? are there persistence requirements for properly

Re: [cryptography] [Cryptography] What is Intel(R) Core™ vPro™ Technology Animation

On Sun, Sep 22, 2013 at 9:21 PM, Jeffrey Walton noloa...@gmail.com wrote: ... Painting with a broad brush, part of the solution is a remote administration board that can''t be removed. Cf, Fujitsu LOM (Lights Out Management), HP ILO (Integrated Lights Out) HP RILO (Remote Integrated Lights

Re: [cryptography] [Cryptography] What is Intel(R) Core™ vPro™ Technology Animation

On Mon, Sep 23, 2013 at 1:33 PM, Jeffrey Walton noloa...@gmail.com wrote: ... Do you just snatch the source code and intellectual property, or do you use it as a springboard into other things? (I've never really thought about it). for better or for worse (mostly better) these systems have

Re: [cryptography] Attack Driven Defense - infosec rant [was: What is Intel(R) Core™ vPro™ Technology Animation]

On Mon, Sep 23, 2013 at 4:17 PM, coderman coder...@gmail.com wrote: ... the source code provides hard coded keys/passwords or pointers to files where interesting bits lay, someone asks: how do you find the interesting sources? this is something i pride myself on, having dealt with scores

Re: [cryptography] Chaos theory

if you're looking for general research in complexity / chaos, shortcut to perusing: Santa Fe Instutute series[0] then AKNOS[1] from there you'll be able to traverse the myraid particulars of interest... best regards, 0. Santa Fe Institute Series

Re: [cryptography] motivation, research ethics organizational criminality (Re: Forward Secrecy Extensions for OpenPGP: Is this still a good proposal?)

On Sat, Sep 14, 2013 at 4:49 PM, David D da...@7tele.com wrote: Great points all around. Your suggestions for identification and punishment are delightful. someone mentioned a bitcoin assassination pool: names to addresses, addresses to kill bid, according to harm perpetuated. if your

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

On Sun, Sep 8, 2013 at 10:18 PM, Greg Rose g...@seer-grog.net wrote: ... I actually hate to point this out, but having access to something that looks like a raw entropy source proves nothing. Given a design for a hardware RNG, with a characterization of its biases, I could straightforwardly

Re: [cryptography] [liberationtech] Random number generation being influenced - rumors

On Mon, Sep 9, 2013 at 6:08 AM, Jon Callas j...@callas.org wrote: ... I have to disagree with you. Lots of us have told Intel that we really need to see the raw bits, and lots of us have gotten informal feedback that we'll see that in a future chip. i've never seen this stated; it would be

  1   2   >