- cypherpunks - lists.cpunks.org

Re: [Cryptography] RSA Crypto is officially insecure due to NIST
by grarpamp 03 Apr '17

03 Apr '17

On Sun, Apr 2, 2017 at 5:49 PM, Tom A. <thomasasta(a)googlemail.com> wrote: > > > On Sun, Apr 2, 2017 at 11:21 PM, grarpamp <grarpamp(a)gmail.com> wrote: > > WARNING > > #RSA Crypto is insecure: > http://csrc.nist.gov/publications/drafts/nistir-8105/nistir_8105_draft.pdf > > >> > GoldBug.sf.net seems to be the only Messenger & Email Client using NTRU >> > or >> > McEliece in an open source implementation, both are considered as >> > quantum >> > resistant. > > >> >> >> With all due respect, it could be great software, however historical >> evidence shows that you absolutely *must* prove that out > > > All can do that, its open source. > >>You need to seriously search, research, evaulate, and audit > even here: > https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf Of course we should not discount new so called "auditors" whose names have "never been heard of before", everyone deserves free entry into the business. But we should thoroughly examine their statements as to their correctness, and herald or return for reexamination their assertions upon review. Suggestion has arisen in the community that these assertions by said authors does infact need more review before being accepted. Do *not* expect to escape that requirement. > In the case of RSA, Shor's algorithm transforms integer factorization into a > polynomial-time exercise. > And quantum-resistance is an important term. Other algorithms, including > AES, may require longer keys. Research. > And, snake oil. > https://www.amazon.com/Nature-Computation-Cristopher-Moore/dp/0199233217/re… > Chapter 15. > > See also quantum circuits. > http://www-bcf.usc.edu/~tbrun/Course/lecture11.pdf > > And you tested the apps over Tor? As higlighted many times before, you routinely just go off into random tangents in attempts to divert relavant critiques of your work. That's fatal. And everytime people have to call you out on it is doubly fatal. Don't get me wrong, I want all good applications to succeed, but authors have to step up to the plate in some fashion before that, to prove that they are good. There is substantial question as to if that's the case here. Step up. > On Sun, Apr 2, 2017 at 11:42 PM, Jan Dušátko <jan(a)dusatko.org> wrote: > >> but I afraid that we are years from successful implementation. From other >> point, > the quantum computing contest has been started > > NTRU is open source and implemented, also McEliece > even with Fujisaki-Okamoto for IND-CCA2! Open Source. > > Regards Tom Being another Satoshi or Complication is fine, no problem, that's an entirely valid aproach. But expect the ramifications therein, and have means, even more means, to support that ideal.

2 2

Re: [Cryptography] RSA Crypto is officially insecure due to NIST
by grarpamp 03 Apr '17

03 Apr '17

When you go around deleting and not responding directly to open critiques of your work and methods, and closing your very own supposed open forums in which such occurs, you deserve all what results from that.

1 0

Fwd: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger
by grarpamp 02 Apr '17

02 Apr '17

Hella links... ---------- Forwarded message ---------- From: Felipe Dau <dau(a)riseup.net> Date: Sun, Apr 2, 2017 at 1:42 PM Subject: Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger To: tor-dev(a)lists.torproject.org On Sun, Apr 02, 2017 at 04:51:40PM +0000, dawuud wrote: > > Hi. I registered with Google to be a GSoC mentor for Tor Project. > Hopefully Meejah will agree to be the backup mentor for this > and register today or tomorrow before the deadline on Monday. > > Let me know if there's anything else timely that I must do for this. Thanks David! Here is the proposal I have so far. Please let me know what you think. (It is also hosted at https://gist.github.com/felipedau/8b48c6fde875e673f62d7569a27f254a) I intend to upload to the GSoC website tonight and add updates until the deadline. Thanks, -Felipe # unMessage: an anonymity enhanced instant messenger In an age where spying, surveillance and censorship evidently became regular practices by various kinds of attackers, it is sensible to be concerned about instant messaging applications, which are very popular communication tools that handle private and identifying information. Such a scenario demands solutions to prevent users from harm these attacks might cause. There are currently good solutions such as [Signal], [Wire] and [OMEMO] apps that make end-to-end encrypted conversations possible. Although such apps successfully provide privacy, they have a great dependency on servers and metadata in order to work and they are not able to provide anonymity. An app that solves this problem is [Ricochet], by not having such dependencies. However, it heavily relies on the transport it uses and does not offer its own encryption layer. [unMessage] is also one of those solutions: a peer-to-peer anonymity enhanced instant messenger written in Python that I have been working on for a while with [David Andersen] - my advisor. unMessage uses on its own end-to-end encrypted [protocol] to maintain conversations, focusing in not depending on servers, metadata and transport. We have recently released an alpha version which should be easy for developers to install and test its current features such as message exchanges, authentication, and voice chat, but there is still a lot of work to do in order to achieve a mature state where users can trust it due to its properties and usability. As we believe unMessage has potential to become a great anonymity enhancing app with a code that is simple, readable and therefore easy to maintain, I propose to work on it during this year's Google Summer of Code with the support of the Tor Community to to make it closer to maturity. We expect to implement fixes, improvements and features from our discussions (on its [tracker] and [tor-dev]) in order to turn it into a maintainable, feature-rich and useful app which everyone can benefit from. ## Technologies unMessage's features were possible with the use of the following technologies: - Transport makes use of [Twisted], [Tor Onion Services] and [txtorcon] - Encryption is performed using the [Double Ratchet Algorithm] implemented in [pyaxo] - which uses [PyNaCl] - Authentication makes use of the [Socialist Millionaire Protocol] implemented in [Cryptully] - Transport metadata is minimized by Tor and application metadata by the unMessage [protocol] - User interfaces are created with [Tkinter] for the [GUI] and [curses] for the [CLI] - Voice chat uses the [Opus codec] for constant bitrate encoding ## Contributions Since its current (alpha) release, we have been discussing it with [Patrick Schleizer] and [HulaHoop] from [Whonix], who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will allow it to be run on Tails as well) with help from [meejah] by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly". Since the introduction of this project for GSoC, [dawuud] became interested in contributing and mentoring it and assisted me on making this proposal. ## Tasks The project is split into tasks, each assigned an ID (in parenthesis) that is used to compose the timeline. I have been generous with how much time each task will demand and I am also leaving the whole week of each evaluation to review and make sure the deliverables meet expectations. Therefore, it is possible that I am able to work on additional tasks in case they consume less time than planned. ### Improve setup script (T1) This task will improve unMessage's `setup.py` by removing redundant package metadata, use files for the requirements and offer development requirements. This task will be tracked in [issue 35]. ### Use attrs (T2) [attrs] is used to simplify the code by removing boilerplate, make it more concise, and consequently improve its quality. Classes definitions will be modified to use attrs' declarations so that attributes have default types and values, as well as validation. This task will be tracked in [issue 34]. ### Support file transfer (T3) unMessage is able to support various elements of a conversation such as requests, messages and authentication. New elements to transmit file requests and the actual files will be added and handle by the elements parser. This task will be tracked in [issue 12]. ### Add a logger (T4) There is currently no logging being done and in order to debug, the only possible approach is using the UIs. A module will be added to send logs to the terminal and a file. This task will be tracked in [issue 30]. ### Use automat (T5) There are certain objects in unMessage that are state machines. Their implementation are very simple and limited as initially they were not designed as state machines. In order to turn them into real state machines, [automat] will be used. This task will be tracked in [issue 26]. #### Design the concept (T5A) Before implementing, I will map the state machines to be created, draw the graphs and have a clear understanding of their transitions and behavior. #### Use automat state machines (T5B) With a design to follow once T5A is done, I will convert the objects into automat state machines. ### Make functions/methods asynchronous (T6) unMessage's initial implementation did not use Twisted and it had pre-defined callbacks in order to continue the path of the action it was performing. It later migrated to Twisted but the pre-defined callbacks are still used. Such callbacks will be removed and the functions that are part of these asynchronous actions will return `Deferred`s to make an actual callback chain. This task will be tracked in [issue 21]. ### Add a test suite (T7) There is not a single test written for unMessage and that is crucial to continue its development. The test suite will be made with [pytest] and will also use [hypothesis] for fuzzing/property tests. I do not expect to achieve 100% converage, test the most important parts of unMessage (mainly the `Peer` module). Also, as I am not familiar with User Interface tests, these will not be part of the task (we are also planning to use a different framework for the GUI, so its tests will only be created after there is a decision). This task will be tracked in [issue 33]. ### Offline messages (T8) As part of unMessage's design, no servers are used to establish and maintain conversations. As a consequence, peer-to-peer communication requires users to only be able to chat while both are online. Although unMessage's protocol supports asynchronous communication, this limitation forces conversations to be synchronous. In order to solve this problem, a [Tahoe-LAFS] server will be used to temporarily store unMessage's packets for peers that were not available when they were sent and can be retrieved later once the peers are online. This task will be tracked in [issue 32]. ### Timeline Tasks/Weeks | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ------------+---+---+---+---+---+---+---+---+---+----+----+---- T1 | X | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T2 | X | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T3 | X | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T4 | | X | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T5A | | X | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- Mid-term 1 | | | X | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T5B | | | | X | X | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T6 | | | | | X | X | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- Mid-term 2 | | | | | | | X | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T7 | | | | | | | | X | X | X | | ------------+---+---+---+---+---+---+---+---+---+----+----+---- T8 | | | | | | | | | | | X | ------------+---+---+---+---+---+---+---+---+---+----+----+---- Final | | | | | | | | | | | | X # Background I am a Senior studying Computer Engineering at the Federal Technological University of Parana in Brazil. In January of 2014 I went to the U.S. for an exchange program, which lasted until December. During the Summer of that same year, I joined a research project lead by David Andersen where I learned about Anonymous Communication and became so attracted to the field that I continued to be part of the project since then. We have mostly worked on [nymphemeral], [pyaxo], [nymserv] and recently, unMessage. # Code sample I have a few repositories on my [GitHub profile] and I recommend taking a look at the ones referenced above, but specially [unMessage] and [nymphemeral], which are the ones I have mostly worked on. # Why The Tor Project? As I mentioned, I have been studying Anonymous Communication for almost three years now and I intend to keep doing it not only because I enjoy it, but because it is an important field capable of helping millions of people around the world. In my opinion, The Tor Project is the biggest organization of its kind and working with people responsible for software I run everyday is a dream of every developer. The Tor community continues to grow every day and I believe that participating in the Google Summer of Code will also contribute to that. # Experiences with free software development environments Since I joined the research project, I have been mostly working with David Andersen on the projects I mentioned previously and git/GitHub make our work a lot easier to work in parallel on the same code, manage tickets to help us keep track of the development and interact with contributors interested in what we do. Whenever I see a project which I can contribute to, even if a it is a small change, I open a ticket or make a pull request if I am able to. My [GitHub profile] lists all my contributions. PyNaCl is one of the recent projects I contributed to. While working on pyaxo I noticed some of the encryption calls could be improved to simplify their usage by making an argument optional. The developer who reviewed the pull request was very positive about it and assisted me while updating the docs to cover this new change. While working on unMessage I asked Patrick Schleizer and HulaHoop for help as it would be great to have it running on Whonix. We have had great discussions and contributed to both projects in order to provide this feature. Along with the development, some changes to txtorcon were appreciated and we have also been working with meejah on that. # Commitment I have concluded all classes for my degree and I am currently an industrial IT intern at an Engineering and Software company, which is the only commitment I will have besides GSoC throught the duration of the program. I intend to work on unMessage 5~6 hours on weekdays and the remainder of the workload on weekends. # Post GSoC The tasks we picked to work on GSoC are a subset of all the ones we have been discussing during unMessage's development, which means that there will be more work to be done after GSoC. Also, unMessage is quite a big project. There are lots of possibilities to explore in the instant messaging field as well as many challenges to overcome when offering an application with usability and features as good as the popular ones, while protecting users' privacy and anonymity. I intend to keep working on unMessage until we have an application that accomplishes our goals. Also, as I have been working with anonymous communication for a while, I do not see myself going somewhere else soon, so the chances of keeping contributing the Tor community are high. # Communication I intend to use IRC to discuss with my mentor and other tor devs (who wish to contribute to the project) about ideas and actions to be taken. To formalize what is discussed on IRC, I will use unMessage's tracker on GitHub to manage features/enhancements/issues to keep records and maintain an organized environment for the development of the project, as well as interact with contributors. I am suggesting this tracker as we have already been using it for a while, but I can migrate to Tor's Trac if needed. To summarize everything, I will do what seems to have worked well for previous students: regular reports on the mailing list to keep people updated with what is happening on the project from a higher level. ## Contact info OFTC: dau Email: dau(a)riseup.net PGP: 0xC5A49047572A0D47 # Other GSoC projects in mind? I am only applying to this one. # Anything else? I encourage you to take a look at the git logs and issue trackers from [unMessage], [nymphemeral] and [pyaxo]. I think I am a very organized developer and I have been trying my best to follow the gitflow model and take advantage of the features offered by GitHub. [attrs]: https://attrs.readthedocs.io [automat]: https://github.com/glyph/automat [cli]: https://unmessage.readthedocs.io/en/latest/cli/cli.html [cryptully]: https://github.com/shanet/Cryptully [curses]: https://docs.python.org/2/library/curses.html [david andersen]: https://github.com/rxcomm [dawuud]: https://github.com/david415 [documentation]: https://unmessage.readthedocs.io [double ratchet algorithm]: https://whispersystems.org/docs/specifications/doubleratchet [github profile]: https://github.com/felipedau [gui]: https://unmessage.readthedocs.io/en/latest/gui/gui.html [hulahoop]: https://github.com/HulaHoopWhonix [hypothesis]: https://hypothesis.readthedocs.io [issue 12]: https://github.com/AnemoneLabs/unmessage/issues/12 [issue 21]: https://github.com/AnemoneLabs/unmessage/issues/21 [issue 26]: https://github.com/AnemoneLabs/unmessage/issues/26 [issue 30]: https://github.com/AnemoneLabs/unmessage/issues/30 [issue 32]: https://github.com/AnemoneLabs/unmessage/issues/32 [issue 33]: https://github.com/AnemoneLabs/unmessage/issues/33 [issue 34]: https://github.com/AnemoneLabs/unmessage/issues/34 [issue 35]: https://github.com/AnemoneLabs/unmessage/issues/35 [meejah]: https://github.com/meejah [nymphemeral]: https://github.com/felipedau/nymphemeral [nymserv]: https://github.com/rxcomm/nymserv [omemo]: https://conversations.im/omemo [opus codec]: https://opus-codec.org [patrick schleizer]: https://github.com/adrelanos [protocol]: https://unmessage.readthedocs.io/en/latest/protocol.html [pyaxo]: https://github.com/rxcomm/pyaxo [pynacl]: https://github.com/pyca/pynacl [pytest]: http://docs.pytest.org [ricochet]: https://ricochet.im [signal]: https://whispersystems.org [socialist millionaire protocol]: https://en.wikipedia.org/wiki/Socialist_millionaire [tahoe-lafs]: https://github.com/tahoe-lafs/tahoe-lafs [tkinter]: https://docs.python.org/2/library/tkinter.html [tor onion services]: https://www.torproject.org/docs/hidden-services.html [tor-dev]: https://lists.torproject.org/pipermail/tor-dev [tracker]: https://github.com/AnemoneLabs/unmessage/issues [twisted]: https://twistedmatrix.com [txtorcon]: https://github.com/meejah/txtorcon [unmessage]: https://github.com/AnemoneLabs/unmessage [whonix]: https://whonix.org [wire]: https://wire.com _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

Re: [Cryptography] RSA Crypto is officially insecure due to NIST
by grarpamp 02 Apr '17

02 Apr '17

On Sun, Apr 2, 2017 at 5:49 PM, Tom A. <thomasasta(a)googlemail.com> wrote: > All can do that, its open source. > And you tested the apps over Tor? Neither of these are sufficient, on mere statement of such. Both must be proven, relavantly.

1 0

Re: [Cryptography] Regulations of Tempest protections of buildings
by grarpamp 02 Apr '17

02 Apr '17

On Sun, Apr 2, 2017 at 11:48 AM, mok-kong shen <mok-kong.shen(a)t-online.de> wrote: > > I wrote previously in a follow-up to a thread that I vaguely remember to > have read > that in US a permission is needed for Farady shielding of rooms, whereupon a > few > readers doubted its correctness. I have just succeeded to again find the > source: > > A. Stanoyevitch, Discrete Structures with Contemporary Applications. CRC > Press, > 2011. On p.301 there is: > > Buildings can be fitted using a special insulation procedure that > protects > against tempest devices, but any company or individual in the US who > has > this insulation must first obtain a license from the federal > Government. I'd think that, unless intended not to for whatever reasons both legit and unbenownst, which is prefectly fine, a poster should reference first, a link to such publication. and that such publication should include links to any applicable laws or promulgated regulations in forwardance of their claims. Otherwise they might seem shady bunk and intentional chilling effect upon freemarket development of tempest applications.

1 0

Re: [Cryptography] Regulations of Tempest protections of buildings
by grarpamp 02 Apr '17

02 Apr '17

On Sun, Apr 2, 2017 at 2:37 PM, Ray Dillinger <bear(a)sonic.net> wrote: >> Buildings can be fitted using a special insulation procedure that >> protects >> against tempest devices, but any company or individual in the US >> who has >> this insulation must first obtain a license from the federal >> Government. >> -- MKShen > Huh. I know [of places] in the bay area that have meeting > rooms with such shielding, and at least one public library. > I assume there are at least hundreds more. As there are many who might wish to utilize, and even create more of, such publicly accessible spaces will you please... a) List the full name, street address, and location within, such as room number, that houses such a space. b) The specifications to which such space was built, and subsequently that it currently maintains adherence to. Otherwise this is useless commentary. Thanks. > The idea that you'd need someone's permission to build something that > doesn't attack anybody else or violate anyone else's rights is just > plain weird. True. > Especially when you need it for just plain business purposes. "Oh, > look, our competitor is driving around with cars that scoop up traffic > from wireless networks, and we already know that WEP is just plain > broken. Not having done this already is pretty irresponsible and could > get us sued by our shareholders....." Indeed. > Or even, "Look, radio > interference from lightning etc makes the power supplies in our server > room wear out faster and in extreme cases could put other hardware at > risk. We can save money on our hardware budget by shielding them...." > > I mean, seriously. Just plain ordinary business purposes. Yep. There is an open market for all these various capabilities indeed.

1 0

Re: [Cryptography] RSA Crypto is officially insecure due to NIST
by grarpamp 02 Apr '17

02 Apr '17

On Sun, Apr 2, 2017 at 4:00 AM, Tom A. via cryptography <cryptography(a)metzdowd.com> wrote: > GoldBug.sf.net seems to be the only Messenger & Email Client using NTRU or > McEliece in an open source implementation, both are considered as quantum > resistant. > ( https://twitter.com/GoldBugIM/status/848443919792844805 ) WARNING "Thomas Asta" is a well known anonymous shill for the shitware known as "goldbug". You need to seriously search, research, evaulate, and audit "goldbug", both on a code and "ethics" level, before giving it any credence whatsoever. *Be warned*, at least as to ethics and code development and community practices not limited to binary reproduceability. Ref: the cypherpunks list on this over many years. With all due respect, it could be great software, however historical evidence shows that you absolutely *must* prove that out before even considering using it. Nor should anyone ever forget that that rationale applies to all and every of the most "trusted", "audited", "well known", "used market share", and "vouched for" apps out there.

1 0

bitcoin fun - self destruction?
by juan 02 Apr '17

02 Apr '17

https://bitcoinmagazine.com/articles/bitcoin-unlimited-miners-may-be-prepar… "...Andresen elaborated on what the most effective way to attack the original Bitcoin chain would be..." etc

2 1

Activists? Really? FSF TimBernersLee DRM W3C, Cryptocurrency "Community"
by grarpamp 02 Apr '17

02 Apr '17

Here's a two week deadline to make a difference on worthless invasive control closed and profiteering shit going into your browser... http://defectivebydesign.org/blog/fourteen_days_dialup_and_save_web_drm http://boingboing.net/2017/03/30/ring-ring-drmphone.html Now let's see what the entirety of "community" of hundred thousand+ so called Activist Crypto Coin Punks and users have risen up to do when given an amazingly generous nine(9) months worth of time... http://www.coindesk.com/sec-winklevoss-bitcoin-trust-public-comment/ http://www.coindesk.com/winklevoss-bitcoin-trust-departs-nasdaq/ http://www.coindesk.com/bitcoin-etf-anticipation-winklevoss-trust-deadline/ https://www.virtualcurrencyreport.com/2016/10/etf-corner-sec-requests-comme… https://www.sec.gov/rules/sro/batsbzx/2016/34-79084.pdf https://www.sec.gov/rules/sro/batsbzx/2016/34-78653.pdf https://www.sec.gov/comments/sr-batsbzx-2016-30/batsbzx201630.shtml ... a measly 68 comments, with many well written by anti's. Pathetic. To win a war you actually have to *wage a fucking war* !!!

1 0

Mirimir Hakced 8ch.net
by HotwheelsGTA 02 Apr '17

02 Apr '17

_______________ ,-^ ,-^| ,-^ ,-^ | ,-^------------.-^ | | | | | | 6 | | | | | vi | | | | ,-^ | | ,-^ `--------------+,-^ vichan - teh imageboard engine -- preliminary website, until someone comes up with something better * vichan github project page * new support board * irc support channel (#vichan-devel @ irc.6irc.net) * historical support board Announcement vichan engine is not dead yet. We still support the code, but the old cruft has accumulated beyond repair. If you are looking for a modern imageboard engine that works, this is your best choice at the current time. Recently, there has been a wake of new imageboard projects. That's a good thing, but in our opinion, we should unite and not divide. The imageboards are going to look differently a few years from now. It's the time to shape that future. If you own an imageboard, you know that your community may demand some changes, or maybe stability. If you write code, you listen to those demands. There are many approaches to that, as every community is a different one, yet they all share some common goals. I am proud, that our code launched some kind of evolution, after a long stagnation from Kusaba times. Our job is now mostly complete, now that we have somewhat hit the limits. But what did impose us those limits, what should we do to go beyond them? Is the job really complete? Everyone has different ideas about that. If we try to solve only our ideas, we may hit a similar problem a few years from now. How about, if we all collect together and talk about those possible problems? It's always easier to think about it, when the project is in a project shape, than when it's near its finalization. We've launched an IRC channel, that should be a think-tank to everyone having fresh ideas about imageboards. The channel is mostly open, yet we should all try to stay on-topic. We already have some people doing code, owning big imageboards. If you think you have a worthy addition, or just want to sit and watch how we shape the future, we invite you there: #metachan on Rizon The engines are tools. The tools are not communities. But the communities do depend on tools to exist. What is the tool your community needs? And what will your community need in a few years from now? ~czaks

1 0