zoukankan      html  css  js  c++  java
  • iota 币产生私钥的方法

    iota 币的官网是 iota.org,   iota 的官网推荐的钱包地址是: https://github.com/iotaledger/wallet   
    iota 币产生私钥是没有什么特殊的要求,唯一要求就是只能是大写字母与数字9且总共不多余81个字符即可,虽然可以少于81个字符,但不建议这么做,以下是产生iota币私钥的方法:

    Linux
    cat /dev/urandom | tr -dc A-Z9 | head -c${1:-81}
    Mac
    cat /dev/urandom | LC_ALL=C tr -dc 'A-Z9' | fold -w 81 | head -n 1

    安全使用IOTA钱包的最佳实践

    IOTA 是为物联网(IoT)设备而设计的协议。这些设备可以非常流畅地遵循任何规则来严格、择优和安全地使用这一协议。可悲的是,人们不善于遵守规则 – 即使他们了解所有的这些规则 – 他们也常常不知道某些行为造成的后果。所以我决定写一篇关于最佳实践的文章,并解释其原理。

    以下是这些规则:

    规则1不重复使用同一地址。不。没有例外。

    规则2始终附加一个新的接收地址到缠结中。

    规则3始终等待一个交易被确认之后再送其他交易

    以下是其原因:

    所有规则都与多次花费相关,即对同一个地址存在多次花费。这里关键的问题是IOTA使用了一次性的签名。对于每个地址,在花费发生之后,该地址不应该被继续使用。这是因为在对外发送IOTA后,这个地址对应的私钥将有一个随机的50%被暴露。这本身并不是问题,在任何单笔花费后收到的IOTA仍然是相当安全的,因为破解另外50%的密钥仍然是一项艰巨的任务。(译者添加:请注意,目前已经有IOTA被偷窃的案例发生,就是因为这个用户向已经花费过的地址继续存入IOTA,从而私钥被暴力破解

    但是当你使用上面相同的地址进行第二次花费后,该地址对应的私钥将又有一个随机的50%被暴露。理论上来说,统计数据将会告诉你,现在75%的密钥已经被暴露,但是理论和实际有所不同。实际中,你可能会非常不幸,因为它是一个“随机的”50%,如果这两个50%中只有10%的部分重叠,那么你私钥的90%已经被暴露了!这时,你的私钥就会非常容易被窃取并被破坏。

    所以,简单来说,2次及以上的对同一地址的花费是非常糟糕的!

    现在我们来看一看什么样的情况会终结一个多重花费,以及为什么这些规则是好的:

    规则1:绝不重复使用同一地址。绝不。没有例外。

    我将很快能听到有些人说:“但是你可以使用同一地址多次接收IOTA!”。从技术角度讲,这是正确的,因为loT设备将会自始至终这么做。但IoT设备的优点在于它们知道交互各方将要做什么以及什么时候该做什么。因此,它们可以安全地做这些事情。这里有一个例子可以展示为什么在同一地址上进行多次花费是一个坏主意:

    比方说,我有一个交易是从交易所取出X个IOTA到我的钱包地址A。整个交易过程需要一些时间,但是最终这X个IOTA被提取了地址A中。

    由于这次的成功操作,我决定提取Y个IOTA并放入相同地址A中。毕竟,我可以向同一地址发送多次,对吗?所以,我开始向交易所提交提取IOTA订单,交易所也开始处理我的订单。请注意,这次提币操作有时可能需要数小时或者数天时间。

    与此同时,我在和朋友讨论IOTA, 并且告诉他我想转给他一些(比如Z个)IOTA。于是,他安装了IOTA钱包,并给了我一个接收地址B。我从自己的钱包里转出Z个IOTA到地址B。钱包顺利地执行命令,从地址A中转出Z个IOTA到地址B。并且,为了使地址A免于多重花费,钱包把剩余的X-Z个IOTA转入一个新生成的地址C中。

    到目前为止,似乎一切看起来都顺利。但是有一个问题:交易所还没有处理我的提币请求。当交易所最终处理到我的这个请求的时候,就像我说的那样,Y个IOTA将会发送到地址A,但这个地址之前已经有一个花费了。哎呀!

    为避免以上情况,我们应该生成一个新地址D,并使用该地址代替地址A作为第二次提币的地址。所以,永远不要重复使用一个地址,甚至接收的时候也不要使用已经用过的地址

    规则2始终附加一个新的接收地址到缠结中。

    我将很快就会听到有些人说:“你没“必要”真的去这么做!“是的,从技术角度讲,这是正确的。将IOTA发送到一个没有附加到缠结的地址是完全正确的,而且这些IOTA也会被很好的传输到这个地址。同样,loT设备也一直是这么做的,但是它们也跟踪它们给出的地址。

    但是,IOTA钱包做法则有所不同。因为可以将钱包安装在不同的设备上,并且使用相同的种子登陆两个钱包,所以,开发人员直接从缠结中获取钱包的状态。这样一来,两个钱包都会收到同样的回复。否则,就会造成一个钱包可以追踪一些重要的地址,而另一个则不了解这些。很漂亮的解决方案。

    但是这种方法将会带来隐藏的花销。为了理解这一点,我们需要看一看钱包是如何决定哪些地址是已经被使用过了。事实上,钱包是通过向它连接到的节点查询来获得包含该地址的交易列表。如果没有交易产生,那么就可以认为该地址尚未被使用。

    通过把一个地址附加到缠结,你显示地创建了一个零值转移交易到这个地址。现在,钱包可以在缠结中找到这次交易记录,并得知该地址已经被使用。是的,一旦有人向该地址发送IOTA,钱包可以在缠结中找到该交易,并再次得知该地址已经被使用。所以,我们不需要明确地将这次交易附加到缠结中,对吗?不不不,大错特错!

    假设我的地址A中有X个IOTA。我决定从交易所取出Y个IOTA并存入地址B。这是按照规则1的要求做的:使用不同的地址。我不打算明确的将地址B附加到缠结上,因为我之前被告知这么做不是绝对必要的。因此,我将提币请求加入订单,之后交易所开始处理我的订单。请注意,这个订单处理也要花费一些时间。

    为了传播我的喜悦之情,我决定再向我的朋友发送Z个IOTA。我发起了转账操作,这次钱包可以从地址A中向我的朋友发送Z个IOTA。然后钱包想要把剩余的X-Z个IOTA发送到一个新的接收地址。所以,钱包向缠结查询哪个地址尚未被使用。哈哈,地址B还没有被使用。于是,钱包就愉快地把剩余的IOTA发送到地址B去。老天,现在我们处于与规定1相悖的情况中了。

    因此,如果我们现在决定向另一个朋友发送另一笔IOTA,最终的结果是,在交易所将IOTA提取到地址B完成之前,我们将花费地址B中的IOTA。这将使我们必然再次发生多次花费。

    我们把地址B附加到缠结就可以轻松避免这种情况。这时,钱包将会知道地址B已经被使用,并且将剩余IOTA发送到新地址C。

    这个例子告诉我们:总是附加一个新的接收地址到缠结中

    规则3始终等待一个交易被确认之后再送其他交易

    我可能很快听到有人说:“但是钱包会帮我避免多重花费!”从技术角度讲,这是正确的。钱包会在花费IOTA之前检查,对于某个地址,如果发现有一个确认的花费,钱包不会允许第二次花费。但是考虑以下情况:

    我在地址A中有X个IOTA。 现在我决定向交易所发送Y个IOTA,这将产生从地址A花费Y个IOTA的交易#1。现在我又决定在交易#1得到确认之前向我的朋友发送Z个IOTA。由于钱包仍然在地址A中看到X个IOTA,它将很顺利地生成从地址A中花费Z个IOTA的交易#2 。糟糕!同一地址产生了两次花费.

    这种情况的解决办法就是在交易#1被确认后再发送交易#2.

    这个例子表明:等待一个交易被确认之后再送其他的求。

    请注意,因为你不知道钱包从哪个地址提取IOTA,然后又把余额发送到何处,所以,许多类似的情况也许会更为混乱。

    另外注意,对于每一条规则,我只是提供了一个例子用来说明可能出错的地方。当快照发生的时候,情况将会更加混乱。但这需要其它文章来说明,非本文讨论之列。

     

     

    原文

    https://forum.helloiota.com/1973/Best-practices-for-using-the-IOTA-wallets-safely

    IOTA is a protocol designed for use by IoT devices. These devices will happily follow any rules to use the protocol strictly, optimally and safe. Sadly, humans are not so good at following rules -if they know them at all- and they often have no idea of the consequences of certain actions. So I decided to write a list of best practices and explain the why in this article.

    Here are the rules:

    RULE 1: NEVER generate your seed online.

    RULE 2: NEVER give your seed to anyone.

    RULE 3: ALWAYS store a copy of your seed some place safe

    RULE 4: NEVER re-use an address. NEVER. NO exceptions.

    RULE 5: ALWAYS attach a new receive address to the Tangle.

    RULE 6: ALWAYS wait for a transaction to be confirmed before sending anything else. 


    And here are the whys:

    -------

    Rule 1-3 all have to do with your seed. The seed is literally the master key to your wallet. Whoever has the key controls the wallet and the iotas therein. So it is very important to have a few best practices that help you keep  your seed safe.


    RULE 1: NEVER generate your seed online.

    Because iotas have monetary value there are a lot of nasty people out there ready to try and relieve you of your iota stash. One way they do this is by offering to generate a seed for you. Don't fall for it!!! Most, if not all online seed generators are designed to make your seed vulnerable. They either will copy the seed or generate a seed from a limited number of random seeds. And as we have seen in the beginning of January some of them have a lot of patience. All of a sudden over 4 million USD worth of iotas got stolen by the operator of a popular seed generator.
    Generating a seed isn't difficult. You just need to know the right method to use. Here are 3 methods to do it yourself:

    Method 1. Make up a string of random, unrelated words. Mix in weird words or foreign words. Really, that's the simplest and safest way to go. With 81 characters it is impossible for anyone to guess them as long as you keep them unrelated.
    Example (spaces are for readability only): FLOWER BEER JE MAINTIENDRAI CLOCKWORK SHELDON ELDERBERRIES BLITZKRIEG OVENMITT AUTOCORRUPT 

    Method 2. Use a single finger and slowly type 81 random letters. Just let your finger go around and around and sometimes let it go down. Purposely trying to make it random is okay. Just try to avoid patterns, which is why quickly mashing fingers on the keyboard is not a good idea. If you want, you can throw a 9 in here and there for good measure. Once you have 81 of them, replace some random letters with other random letters, just to make sure you break any patters you unwittingly used.
    Example: KUWVQZOVFENI9GTESKPLJKMVFTETTKGSWQBMOPHTJLOHRRGKOKNHKKECDSKNSFFHGKBPYU9NVDL9ECVMB

    Method 3: Warning: This method is only for people who actually know what they are doing and what I am talking about. There are a local/offline secure random generators available with most major operating systems. I won't go into detail here to prevent the noob users from using them. You really want to know what you are doing. Mac and Linux for example offer /dev/urandom. If this does not mean anything to you, just use method 1 or 2 instead. 



    RULE 2: NEVER give your seed to anyone.

    Again, there are many predators out there. Some of them will even pretend to be part of the IOTA foundation and offer to help you if you ask for help with a problem in any of the help channels.
    Be paranoid in those cases where such a person asks for your seed. Once you give it they will quickly empty your wallet. Most problems you will encounter can be solved without ever giving up your seed to anyone.


    RULE 3: ALWAYS store a copy of your seed some place safe

    Protect yourself from ever losing your iotas. Keep one or more copies of your seed in safe places. Make sure that it is not easy for anyone to get a quick peek at them. Remember, mobile devices are cameras and snapping a picture of your seed is very easily done. Best to separate your seed in two parts and keep them stored away from each other. I recommend 2 bank safes at 2 different banks. Especially when the amount of iotas becomes large this is no overkill. And while you're at it make sure that it includes a succession list in case anything happens to you and maybe include some trusted persons that can help your heirs get their hands on the funds. Nothing sadder than sitting on a million worth of iotas and no one being able to access them when you die.

    --------

    Rule 4-6 all have to do with multi-spending. Which is spending more than once from the same address. The problem here is that IOTA uses one-time signatures. After spending addresses are not supposed to be used any more because in the process of spending a random 50% of the private key to the address gets exposed. This in itself is not a problem, any funds arriving after a single spend are still pretty safe. Breaking the other 50% of the key is still a daunting task.

    But when a second spend happens on the same address a new random 50% of the private key for that address gets exposed. Theoretically, statistics will tell you that now 75% of the private key is exposed. But here is the difference between theory and practice. Since it is a *random* 50% of the key that gets exposed, you could be unlucky enough that both 50% exposures only have a 10% overlap. In which case a whopping 90% of your key is exposed already! In which case your private key is toast and broken relatively easy.

    So in short: 2 or more spends from the same address is VERY BAD!

    Now let's see what scenarios could occur that will end up in a multi-spend and why these rules are good:


    RULE 4: NEVER re-use an address. NEVER. NO exceptions.

    I can immediately hear some people say: "But you are allowed to receive multiple times at a address!" And they are technically correct. IoT devices will do this all the time. But they have the advantage of knowing exactly what the parties they are talking to are going to do and when. So they can safely do this. Here is a scenario that shows just one example of why it is a bad idea to send multiple times to the same address:

    Let's say I withdraw X iotas from an exchange to address A in my wallet. The whole process takes a little time, but I end up with X iota in address A.

    Encouraged by this success I decide to withdraw another Y iotas to that same address A. After all, I can send *to* an address multiple times, right? So I put in the order and the exchange starts processing the order. Note that this processing can sometimes take hours or even days. 

    In the mean time I tell my friend about IOTA, and to encourage him I want to send him a few (let's say Z) iotas. So he installs the wallet and gives me a receive address B. I tell the wallet to send Z iotas to address B. The wallet happily obliges and takes the iotas in address A, sends Z iotas to address B, and -to guard address A from multi-spending- it also sends the remaining X - Z iotas safely to a newly generated address C in my wallet.

    Everything seems okay so far. But with one problem: The exchange did not process my withdrawal yet. When it finally does process it, the Y iotas will be sent to address A just like I instructed. Except that address now already has an earlier spend on it! Oops!

    This situation could have been simply avoided by generating a new address D for the second withdrawal and using that instead of address A.
    So case in point: NEVER re-use an address. Not even for receiving.


    RULE 5: ALWAYS attach a new receive address to the Tangle.

    I can immediately hear some people say: "But you don't really *have* to do this!" And again, they are technically correct. It is perfectly fine to send iotas to an address that was not attached to the Tangle explicitly. They will arrive just fine. Again, IoT devices do this all the time, but they also keep track of what addresses they gave out as receive addresses.

    The IOTA wallet does it differently. Because it is possible to install the wallet on different devices, and log in both wallets with the same seed, the developers are determining the state of the wallet directly from the Tangle. That way both wallets will respond the same to events. Otherwise one could have kept track of some important addresses and the other would have no knowledge of that. Pretty elegant solution.

    But this solution comes with a hidden cost. To understand this we need to look at how the wallet decides which addresses have been used already. It does that by asking the node it is connected to for a list of transactions that incorporate that address. If there are no transactions yet it concludes that it has not used the address yet. 

    By attaching an address to the Tangle you explicitly create a zero-transfer transaction for that address. Now the wallet can find that transaction in the Tangle, so it knows it is in use already. And yes, in case someone sends iotas to that address, the wallet can find that transaction in the tangle and again sees that it is in use already. Therefore we don't need to explicitly attach it, right? Bzzzzt! *Wrong*!!

    Let's say I have X iotas in address A. I decide to withdraw another Y iotas from the exchange to address B. That's what I learned from rule 1. Use a different address. I don't bother explicitly attaching address B to the Tangle, because I was told before that that was not strictly necessary. So I put in the order and the exchange starts processing the order. Which again takes time. 

    To spread more joy I decide to send Z iotas to my friend again. I initiate the transfer, and this time the wallet can take from address A, send Z iotas to my friend's address, and then it wants to send the remaining X - z iotas to a new receive address. So it looks in the tangle which address is not in use already. Aha! Address B is not used yet. So it merrily sends the results to address B. Oh dear. Now we are in the same situation as we were in with rule 1. 

    So if we now decide to send another amount of iotas to another friend, we will be spending address B before the withdrawal *to* address B has executed. And we end up with a guaranteed multi-spend again.

    This situation could have been simply avoided by explicitly attaching address B to the Tangle. In which case the wallet would have seen it was in use already, and it would have sent the remainder to a new address C instead.
    So case in point: ALWAYS attach a new receive address to the Tangle.


    RULE 6: ALWAYS wait for a transaction to be confirmed before sending anything else. 

    I can immediately hear some people say: "But the wallet will keep me from multi-spending!" And again, they are technically correct. The wallet will check before spending if there already has been a confirmed spend on the address, and won't allow a second spend in that case. But consider the following scenario:

    I have X iotas in address A. I now decide to send Y iotas to an exchange. This will generate a transaction #1 spending Y iotas from address A.
    Now I also decide to send my friend his Z iotas before transaction #1 has been confirmed. Since the wallet still sees the X iotas in address A it will happily generate transaction #2 spending Z iotas from address A. Oops! Two spends from the same address.

    This situation could have been simply avoided by waiting for transaction #1 to be confirmed before sending transaction #2.
    So case in point: ALWAYS wait for a transaction to be confirmed before sending anything else.


    Note that a lot of these situations are even muddier because you have no idea what address(es) the wallet is going to pick as input(s) for sending iotas somewhere.

    Also note that I only provide one example of where things can go wrong for each rule. Things become even muddier when snapshots happen. But that is something for another article.

  • 相关阅读:
    HSV 武胜
    crystalReportViewer+ReceiveCrystalReport.rpt+DataSet.xsd做报表 转 武胜
    Apache Gzip设置
    Linux gsoap 访问Jira
    搜索引擎Senna
    c 条件编译 ifndef解决 gcc multiple define error.
    搜索引擎 apachesolr
    Lucene:基于Java的全文检索引擎简介
    搜索引擎Zend_lucene
    基于应用程序级的Apache认证配置(普通认证篇)
  • 原文地址:https://www.cnblogs.com/welhzh/p/8098499.html
Copyright © 2011-2022 走看看