Nano Hash - криптовалюты, майнинг, программирование

Реализация RSA в веб-приложении Google App Engine

Это задание. Мне нужно создать веб-приложение в движке приложения Google и применить алгоритм rsa для хранения данных в хранилище данных движка приложения. Мое приложение просто хранит небольшие заметки, созданные пользователем. Я закончил приложение, а также применил RSA для шифрования сообщений (получил код из Реализация алгоритма RSA). Для этого я разбиваю строку и преобразовываю каждый символ в ascii, а затем сохраняю их в повторяющемся ndb.IntegerProperty, но я не понимаю, как должны обрабатываться закрытые и открытые ключи. Я хочу знать, где хранить закрытый ключ, и после того, как заметки будут зашифрованы и пользователь снова получит к ним доступ, как мне получить открытый и закрытый ключи? Должен ли я также хранить их ключи в хранилище данных?

Шифрование выполняется на сервере для шифрования заметок, которые сохраняет пользователь. Заметки представляют собой строки, которые разбиты на символы, а их значения ascii затем зашифрованы. Все это делается на стороне сервера, когда пользователь нажимает «добавить заметку».

Расшифровка выполняется на стороне сервера, когда пользователь входит в систему, и его идентификатор пользователя используется для извлечения сохраненных им заметок, которые расшифровываются для получения исходных значений ascii, а затем формируют исходную строку.

В настоящее время существует только одна пара ключей, которая генерируется в коде. ссылка на приложение: http://cloudassignment-1102.appspot.com

Дайте мне знать, если мне также нужно добавить исходный код.

python encryption google-app-engine cryptography
20.10.2015

  • Я обновил свой ответ. Мне трудно дать вам 100% ответ, так как это действительно пример бесполезного упражнения, поэтому истинный ответ на вопрос, где вы должны хранить свои ключи, — «там, где вы хотите». Для простоты я рекомендую использовать хранилище данных, как описано в моем редактировании ответа. 21.10.2015

Ответы:


1

В идеале вы храните закрытый ключ в (очень) безопасном месте. Поскольку GAE — это платформа, которую вы выбираете, у вас есть несколько вариантов:

  • Поместите ключ где-нибудь в свой проект, где он читается исходным кодом, но не является общедоступным (в Java это обычно папка ресурсов или WEB-INF, не уверен, что такое эквивалент для python)
  • Воспользуйтесь облачным хранилищем и поместите туда свой файл. Это немного накладно, но если вы когда-нибудь захотите изменить ключевой стиль операции на открытом сердце...
  • Поскольку ключ - это просто массив байтов, вы можете определить их как постоянный массив байтов в своем источнике. Очевидно, это будет наименее гибкий выбор.

РЕДАКТИРОВАТЬ:

Скажу лишь, что это глупое задание. Нет никакого смысла использовать асимметричное шифрование, если вы прячете все шифрование на своем сервере. Поскольку ваши данные всегда расшифровываются перед отправкой пользователю, это в основном то же самое, что и симметричное шифрование или полное отсутствие шифрования.

Но в духе делать глупости и учиться при этом:

Я предполагаю, что ваш код генерирует пары ключей для каждого пользователя. Поэтому невозможно хранить ключи как константы в вашем коде (файловая система GAE доступна только для чтения). Вместо этого вы можете использовать любую базу данных (будь то облачное хранилище данных или облачный sql).

Поскольку у вас должен быть объект пользовательской базы данных, вы можете поместить туда открытый ключ с остальной информацией о пользователе. Вы можете предоставить открытый ключ из базы данных через облачную конечную точку, если вам это потребуется. Поскольку это не секрет, вам не нужно защищать эту конечную точку.

Секретный ключ может находиться в том же хранилище (хранилище данных/облачный sql?), но я бы отделил его, чтобы вы не могли запросить его и случайно передать. Должна быть достаточно дополнительной таблицы/сущности со ссылкой на пользователя.

20.10.2015
  • Хорошо, я храню закрытый ключ в своем коде, а как насчет открытого ключа? должен ли я иметь другую ndb.model для сопоставления закрытого ключа с конкретным пользователем? 21.10.2015
  • На самом деле не имеет значения, где находится открытый ключ. Он может быть публичным. Но подождите... Существует ли пара ключей для каждого пользователя? Если это так, то все шифрование/дешифрование должно выполняться на стороне клиента, и вам придется обрабатывать хранение ключей на стороне клиента. Это сделало бы данные пользователя безопасными, даже от вас самих :-) 21.10.2015
  • но где я могу хранить его публично? я должен держать их в коде, а? да, я понимаю, что хранение пары ключей для каждого пользователя было бы более безопасным, но тогда как мне обрабатывать хранение ключей на стороне клиента? для закрытого ключа, я думаю, я могу просто хранить их в облаке sql 21.10.2015
  • Если у вас есть только одна пара ключей, вы можете сохранить ключ публикации так же, как вы храните секретный ключ (в коде?). На стороне клиента: например, клиент может хранить данные в локальном хранилище в браузере. Но вам нужно будет перенести все ваши средства шифрования на сторону клиента, включая создание ключа. Я не очень понимаю концепцию вашего шифрования. Не могли бы вы расширить свой вопрос и объяснить, почему данные шифруются, почему вам нужен RSA, а не, скажем, AES, и как данные хранятся на какой стороне вашего приложения (клиент/сервер). 21.10.2015
  • это просто задание для моего курса, где нам нужно создать приложение и показать улучшенную форму применения RSA. На данный момент я применил только RSA и запутался в хранении ключей. Данные хранятся в хранилище данных google cloud sql (на стороне сервера). 21.10.2015
  • Я рассмотрю создание на стороне клиента и попытаюсь включить это, в противном случае, я думаю, я позволю пока хранить ключи в исходном коде. 21.10.2015
  • другое сомнение. Если я храню ключи локально, а человек получает доступ к приложению с другого компьютера, то как я получу открытые ключи? 21.10.2015
  • Именно поэтому я попросил вас описать приложение немного подробнее. Вопрос в том, кто что и где шифрует и кто что и где расшифровывает. Если все шифрование выполняется либо на сервере, либо на клиенте, асимметричное шифрование вообще не требуется. Так кто шифрует? Пожалуйста, расширьте свой вопрос и не используйте комментарии. 21.10.2015
  • я расширил вопрос. Я хочу иметь пару ключей для каждого уникального пользователя, поэтому я хотел знать, как обращаться с ключами. 21.10.2015
  • Спасибо. У меня было ощущение, что то, что я делаю, действительно глупо, и в первую очередь не было никакого смысла делать шифрование. что было бы лучшей альтернативой шифрованию данных, которые пользователь хочет сохранить? расшифровка шифрования на стороне клиента с сохранением закрытого ключа в моем облаке? 21.10.2015
  • Давайте продолжим обсуждение в чате. 21.10.2015
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..